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 <[email protected]> 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 > [email protected] > https://www.redhat.com/mailman/listinfo/container-tools _______________________________________________ Container-tools mailing list [email protected] https://www.redhat.com/mailman/listinfo/container-tools
