[Container-tools] vagrant-service-manager as proxy to systemctl services

[Brian (bex) Exelbierd]

On 05/24/2016 12:51 PM, Hardy Ferentschik wrote:
> Hi there,
>
> I wanted quickly wanted to get some feedback on a design decision
> regarding vagrant-service-manager.
>
> According to my understanding, vagrant-service-manager "is designed
> to enable easier access to the features and services provided by the
> Atomic Developer Bundle (ADB)." At least that is also the objective
> from the README.
>
> The question is around the term "services". In the context of
> vagrant-service-manager services are docker, openshift, kubernete,
> (mesos). The higher level components we are managing for the user to
> use the ADB/CDK. These might be system services (systemd), but they
> also might be just a bunch of running Docker containers.
>
> There is an outstanding pull request [1] for vagrant-service-manager
> which adds a start/stop to the already existing 'vagrant
> service-manager restart <service>'. Adding start/stop makes sense,
> but as a side effect it also allows and documents that now any
> systemd service can be controlled via 'vagrant service-manager
> [start|stop|restart] <service>'. This is the part I am not so happy
> about. I think we go too far in this case on what the
> vagrant-service-manager can and should do. It is not its
> responsibility to control systemd services.

I believe part of the motivation for this methodology is to avoid having 
to write service modules for things that systemd already manages. 
However, I can understand where this has perhaps gotten to generalized. 
  There is an existing Issue around docs for developers on how to add 
new services to vagrant-service-manager.

One option would be to leave the full access to systemd undocumented.  I 
can see minor value in it, but understand that it may not be useful and 
therefore is just more potential for things to go sideways.  The value 
is that others can now use this code when they want to control simple 
aspects of a VM in an accessible way.

> I am also concerned that the term 'service' gets now overloaded in
> the context of the plugin. Once meaning systemd service once
> functional service as provided by ADB/CDK to fulfill container based
> tasks.
>
> I am interested to hear what others thing in this regard or whether I
> stand alone with my concerns.

How do you view supporting services?  If Orchestrator X has an optional 
component, how should that be managed?

regards,

bex