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

[Hardy Ferentschik]

Hi,

> >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.

I am not sure I follow. What are "service modules"? Vagrant plugins?
So what's wrong with using systemctl. As part of a Vagrant provisioning is it imo
even more concise than using the service-manager. And using systemctl from the commandline
either from the host or the guest is really not so hard either.

> However, I can understand where this has perhaps gotten to generalized

+1 Just because it happens to work technically under the hood like this, it does not mean
that it always will do. Effectively we are exposing an impl detail here. Initially 
OpenShift was in fact not a systemd service. 

> There is an existing Issue around docs for developers on how to add new services to
> vagrant-service-manager.

Which one is that? And again, define "service" in this context. 

> One option would be to leave the full access to systemd undocumented

That's the minimum we should do. Personally I'd restrict services to the services we know
and care about.

> >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?

There is an outstanding discussion around this which is another reason I think we should 
prematurely open Pandora's box. 

We really have two opposing goals. One is to keep the VM minimal (in size) and the other
is to easily allow the user to install and test useful add ons. Things which come to mind
are - Fabric8, Hawkular, Cockpit, ...

Depending on what you want to sue you are not necessarily dealing with systemd services and
even in the case where you do (Cockpit) you might need to install the rpm first.

One idea which I had around this was to have the concept of variants (similar to Mac Ports).
A service can define variantsm eg OpenShift with the Variant of Fabric8 and Cockpit.
In this case the user enables the variants somehow like this:

    vagrant service-manager enable openshift+fabric8+cockpit

There would also be a way to list the available variants for a given service:

    vagrant service-manager variants openshift

Under the hood we handle all the details to install and enable the variants which might
or might not be related to systemd.

In case the use of '+' to enable variants feels to alien for some, we could also introduce 
dedicated commands for this.

--Hardy


> 
> regards,
> 
> bex
> 
> _______________________________________________
> Container-tools mailing list
> Container-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/container-tools
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/container-tools/attachments/20160524/0e8a9e72/attachment.sig>