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

[Pete Muir]

One thing that might make this clearer is to add a word to the command
line. Following on from our naming discussion yesterday, perhaps
something like:

vagrant service-manager environment start|stop|restart <service> or
vagrant service-manager start|stop|restart environment <service>

Just thinking about how we make it clear this is operating on a
generic service in the environment...

On 24 May 2016 at 11:59, Brian (bex) Exelbierd <bex at pobox.com> wrote:
>
>
> 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
>
> _______________________________________________
> Container-tools mailing list
> Container-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/container-tools