<div dir="ltr"><div>>Excerpts from Kanagaraj Manickam's message of 2016-05-18 19:48:13 +0530:</div><div>>> > DIms,</div><div>>> >></div><div>>> >> Use case could be anything, which would needed by either</div><div>>> >> operator/community, who wants to perform an required task before and</div><div>>> after</div><div>>> >> service is started. This requirement is very generic by nature, and I</div><div>>> >> believe it will be very useful.</div><div>>> >></div><div>>> >> Would like to give the sample use cases from from Operator & OpenStack</div><div>>> >> community side as below.</div><div>>> >> Operator side, any pre/post actions could be hooked which is the</div><div>>> >> requirement for them. Simple example would be, one who wants to create an</div><div>>> >> journal of start/stop details like time, number of worker,</div><div>>> configurations,</div><div>>> >> etc in a common portal, this life-cycle hook would help.</div><div>>></div><div>>> > Is that information not available in the logs?</div><div>>></div><div>>> [Kanagaraj M] its available in log, but one who wants to collect these info</div><div>>> in centralized portal,</div><div>>> it would help.</div><div>>></div><div>>> ></div><div>>> > OpenStack community side, sample use cases would be:</div><div>>> > 1. Most of the OpenStack components starts TextGuruMeditation, logging</div><div>>> > while those components are get started. These tasks could be provided as</div><div>>> > life cycle hooks and all OpenStack components could start to leverage it.</div><div>>></div><div>>> >All of those are things that need to be built into the app in a way that</div><div>>> >they are started at the right time, rather than at an arbitrary point</div><div>>> >defined by the plugin order a deployer has specified.</div><div>>></div><div>>> [Kanagaraj M] while i investigated the OpenStack service cmd, mostly</div><div>>> it follows the similar pattern on use these utils, so i thought, it would be</div><div>>> good to provide an plugin, which take care of it instead every service</div><div>>> code does take care of it. helps to reduces maintenance effort.</div><div>></div><div>>Except that we don't want deployers to turn them off, and we need to</div><div>>control the initialization order, and so we don't want them to be</div><div>>specified through a configuration option.</div><div>></div><div><br></div><div>[KanagarajM] sure. I hope we could start with this option,</div><div>as a better choice now.</div><div><br></div><div>>></div><div>>> >> 2. For automatically discovering the OpenStack deployment, this hooks</div><div>>> will</div><div>>> >> be very useful. Auto-discover-hook would report to pre-defined</div><div>>> destinations</div><div>>> >> while starting/stopping the service.</div><div>>></div><div>>> >Doing that usefully is going to require passing information to the hook</div><div>>> >so it knows where it is running (what service, what port, etc.). None of</div><div>>> >the APIs for doing this have been described yet. Do you have any plans</div><div>>> >put together?</div><div>>></div><div>>> [Kanagaraj M] I am trying to get all of these information from oslo.confg</div><div>>> global config variable. As we discussed about namos during austin summit,</div><div>>> namos does collect these details</div><div>>> <a href="https://github.com/openstack/os-namos/blob/master/os_namos/sync.py#L124">https://github.com/openstack/os-namos/blob/master/os_namos/sync.py#L124</a></div><div>></div><div>>There are 2 issues with having a plugin access config values directly.</div><div>></div><div>>Configuration options are owned by the code that defines them, and</div><div>>are not considered a public "API" for other parts of the code. That</div><div>>means an application or library developer is free to change the</div><div>>name or location of a configuration option, without regard to code</div><div>>that might be trying to use it from outside of the owning module.</div><div>>oslo.config has support for renames so that *deployers* aren't</div><div>>broken, but we don't do anything to prevent code that accesses</div><div>>private values from breaking.  So, you don't want to build any</div><div>>assumptions into the plugins that they will be able to see configuration</div><div>>values.</div><div>></div><div>>Second, options do not "exist" as far as oslo.config is concerned</div><div>>until they are registered.  The registration step may happen at</div><div>>runtime in code that has not executed before the plugin is loaded. So</div><div>>even if we ignore the "private" nature of the option, there is a timing</div><div>>issue.</div><div>[KanagarajM] As part of the investigation, found that most of OpenStack<br></div><div>service components logs the complete configuration options in the log,</div><div>once service is started and I hope the same point, the discovery-hook</div><div>could be registered. (This could be avoided in future by using the</div><div>oslo-config-generator to get all options, i hope, if my understanding is</div><div>correct :)</div><div><br></div><div>>Well, I still think this is a poor design for the feature you want.<br></div><div>>It really seems like service management should happen from outside</div><div>>of the service being managed. I'm going to need to see a lot more</div><div>>detailed thought put into answers to those questions before I could</div><div>>support adding this feature to oslo.service.</div><div>></div><div>[KanagarajM] we already doing the in-band service deployment discovery <br></div><div>for nova, cinder, neutron and heat, which are reported in horizon</div><div>panel as well under 'system information' panel. When we look at the impl</div><div>of service discovery in each of these projects, all rpeats the same </div><div>implementation in each of their repository. Once this is in place, we </div><div>could enable the auto-discovery of each service deployment without</div><div>repeating the impl, and those projects also could start to levarage it</div><div>which releaves a considerable maintenance effort from each of the projects</div><div>for its deployment discovery.</div><div>>> >> On Wed, May 11, 2016 at 7:05 PM, Davanum Srinivas <<a href="mailto:davanum@gmail.com">davanum@gmail.com</a>><br></div><div>>> wrote:</div><div>>> >></div><div>>> >> > Kanagaraj,</div><div>>> > ></div><div>>> >> > Who is the first consumer? for what specific purpose?</div><div>>> >> ></div><div>>> >> > Thanks,</div><div>>> >> > Dims</div><div>>> >> ></div><div>>> >> > On Wed, May 11, 2016 at 9:27 AM, Kanagaraj Manickam <<a href="mailto:mkr1481@gmail.com">mkr1481@gmail.com</a>></div><div>>> >> > wrote:</div><div>>> >> > > Hi,</div><div>>> >> > ></div><div>>> >> > > When OpenStack service components are started/stooped,</div><div>>> >> > > operators or OpenStack Services want to execute some actives</div><div>>> >> > > before and/or after component is started/stopped.</div><div>>> >> > > Most of the time, operator needs to depends</div><div>>> >> > > on the start-up scripts to do it, which is an installer</div><div>>> >> > > dependent, while OpenStack service can't use this approach.</div><div>>></div><div>>> >Can you elaborate on this? I think you're saying that having a start-up</div><div>>> >script take action before a service is started won't work because it</div><div>>> >would require the operator to customize that script. Is that right?</div><div>>> >Aren't there already tools for doing this, though?</div><div>>></div><div>>> [KanagarajM] when we use start-up script, we can't do any pre/post</div><div>>> actions in every worker process, instead we can only do pre/post once</div><div>>> before/after launcher and all worker process started.</div><div>></div><div>>Can you describe some of the sorts of things you expect to need to do</div><div>>for each process?</div><div><br></div><div>[KanagarajM] one of the use case i was thinking of is, while upgrading, we need to put</div><div>the service components to maintenance state, so that it would stop taking</div><div>further request and once it finishes it current on going request processing,</div><div>it can exist. to do that, each worker process to be notified to go to maintenance</div><div>mode, by providing an maintenance-hook, any service it wants to support</div><div>the maintenance cycle, could leverage it. <br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 18, 2016 at 8:10 PM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Kanagaraj Manickam's message of 2016-05-18 19:48:13 +0530:<br>
<span class="">> > DIms,<br>
> >><br>
> >> Use case could be anything, which would needed by either<br>
> >> operator/community, who wants to perform an required task before and<br>
> after<br>
> >> service is started. This requirement is very generic by nature, and I<br>
> >> believe it will be very useful.<br>
> >><br>
> >> Would like to give the sample use cases from from Operator & OpenStack<br>
> >> community side as below.<br>
> >> Operator side, any pre/post actions could be hooked which is the<br>
> >> requirement for them. Simple example would be, one who wants to create an<br>
> >> journal of start/stop details like time, number of worker,<br>
> configurations,<br>
> >> etc in a common portal, this life-cycle hook would help.<br>
><br>
> > Is that information not available in the logs?<br>
><br>
</span><span class="">> [Kanagaraj M] its available in log, but one who wants to collect these info<br>
> in centralized portal,<br>
> it would help.<br>
><br>
> ><br>
> > OpenStack community side, sample use cases would be:<br>
> > 1. Most of the OpenStack components starts TextGuruMeditation, logging<br>
> > while those components are get started. These tasks could be provided as<br>
> > life cycle hooks and all OpenStack components could start to leverage it.<br>
><br>
> >All of those are things that need to be built into the app in a way that<br>
> >they are started at the right time, rather than at an arbitrary point<br>
> >defined by the plugin order a deployer has specified.<br>
><br>
> [Kanagaraj M] while i investigated the OpenStack service cmd, mostly<br>
> it follows the similar pattern on use these utils, so i thought, it would be<br>
> good to provide an plugin, which take care of it instead every service<br>
> code does take care of it. helps to reduces maintenance effort.<br>
<br>
</span>Except that we don't want deployers to turn them off, and we need to<br>
control the initialization order, and so we don't want them to be<br>
specified through a configuration option.<br>
<span class=""><br>
><br>
> >> 2. For automatically discovering the OpenStack deployment, this hooks<br>
> will<br>
> >> be very useful. Auto-discover-hook would report to pre-defined<br>
> destinations<br>
> >> while starting/stopping the service.<br>
><br>
> >Doing that usefully is going to require passing information to the hook<br>
> >so it knows where it is running (what service, what port, etc.). None of<br>
> >the APIs for doing this have been described yet. Do you have any plans<br>
> >put together?<br>
><br>
> [Kanagaraj M] I am trying to get all of these information from oslo.confg<br>
> global config variable. As we discussed about namos during austin summit,<br>
> namos does collect these details<br>
> <a href="https://github.com/openstack/os-namos/blob/master/os_namos/sync.py#L124" rel="noreferrer" target="_blank">https://github.com/openstack/os-namos/blob/master/os_namos/sync.py#L124</a><br>
<br>
</span>There are 2 issues with having a plugin access config values directly.<br>
<br>
Configuration options are owned by the code that defines them, and<br>
are not considered a public "API" for other parts of the code. That<br>
means an application or library developer is free to change the<br>
name or location of a configuration option, without regard to code<br>
that might be trying to use it from outside of the owning module.<br>
oslo.config has support for renames so that *deployers* aren't<br>
broken, but we don't do anything to prevent code that accesses<br>
private values from breaking.  So, you don't want to build any<br>
assumptions into the plugins that they will be able to see configuration<br>
values.<br>
<br>
Second, options do not "exist" as far as oslo.config is concerned<br>
until they are registered.  The registration step may happen at<br>
runtime in code that has not executed before the plugin is loaded. So<br>
even if we ignore the "private" nature of the option, there is a timing<br>
issue.<br>
<div><div class="h5"><br>
><br>
> >It feels very much like you're advocating that we create a thing like<br>
> >paste-deploy for non-WSGI apps: allow anyone to insert anything into<br>
> >the executing process for any purpose and with little control on the<br>
> >application authors' part. That introduces potential stability issues,<br>
> >and a lot of questions that haven't been answered. For example:<br>
><br>
> >Does service startup block until all of the plugins are done? If not,<br>
> >do we need to have a timeout management system built in or do we run<br>
> >the plugins in their own thread/subprocess so they can run in the<br>
> >background?<br>
><br>
> >Can a plugin change the execution of the service in some way (you<br>
> >mentioned having a plugin download config files when we spoke at the<br>
> >summit, is that still something you want to slip in this way instead of<br>
> >putting it into oslo.config)?<br>
><br>
> >Can a plugin cause the service to not start at all by exiting?<br>
><br>
> >What happens if one plugin fails but others succeed? Do we keep running?<br>
><br>
> >What information about the service can a plugin see? It's running in the<br>
> >same process, so it could see the configuration object, for example.<br>
> >It would only be able to see configuration options it adds (yes, that<br>
> >would work) or that were registered by the application before the plugin<br>
> >is run. So, not necessarily all options but potentially many, with more<br>
> >and more as apps shift to pre-registering all of their options in one<br>
> >place. Assuming these are things the deployer has selectively installed,<br>
> >maybe that's OK. OTOH, it does open another security surface.<br>
><br>
> >What happens when a service is told to restart its workers? Do the<br>
> >plugins run again?<br>
><br>
> >Can a plugin start listening for network connections on its own? Connect<br>
> >to the message bus?  Provide an RPC endpoint? Start processes? Threads?<br>
><br>
> [KanagarajM] It gives me a lots insight on what are different problems<br>
> would come and i really thank you.<br>
> Hooks will be provided by community and/or deployers. while community<br>
> provides, those hooks will be well documented, tested and configuration<br>
> would be<br>
> provided. so all of the above mentioned aspects would be taken care well by<br>
> community based on the hooks functionality. And deployer also would take<br>
>  care of similar safety measurement before using their hooks similar to how<br>
> would they take care when using startup scripts.<br>
<br>
</div></div>Well, I still think this is a poor design for the feature you want.<br>
It really seems like service management should happen from outside<br>
of the service being managed. I'm going to need to see a lot more<br>
detailed thought put into answers to those questions before I could<br>
support adding this feature to oslo.service.<br>
<span class=""><br>
> >> On Wed, May 11, 2016 at 7:05 PM, Davanum Srinivas <<a href="mailto:davanum@gmail.com">davanum@gmail.com</a>><br>
> wrote:<br>
> >><br>
> >> > Kanagaraj,<br>
> > ><br>
> >> > Who is the first consumer? for what specific purpose?<br>
> >> ><br>
> >> > Thanks,<br>
> >> > Dims<br>
> >> ><br>
> >> > On Wed, May 11, 2016 at 9:27 AM, Kanagaraj Manickam <<a href="mailto:mkr1481@gmail.com">mkr1481@gmail.com</a>><br>
> >> > wrote:<br>
> >> > > Hi,<br>
> >> > ><br>
> >> > > When OpenStack service components are started/stooped,<br>
> >> > > operators or OpenStack Services want to execute some actives<br>
> >> > > before and/or after component is started/stopped.<br>
> >> > > Most of the time, operator needs to depends<br>
> >> > > on the start-up scripts to do it, which is an installer<br>
> >> > > dependent, while OpenStack service can't use this approach.<br>
><br>
> >Can you elaborate on this? I think you're saying that having a start-up<br>
> >script take action before a service is started won't work because it<br>
> >would require the operator to customize that script. Is that right?<br>
> >Aren't there already tools for doing this, though?<br>
><br>
> [KanagarajM] when we use start-up script, we can't do any pre/post<br>
> actions in every worker process, instead we can only do pre/post once<br>
> before/after launcher and all worker process started.<br>
<br>
</span>Can you describe some of the sorts of things you expect to need to do<br>
for each process?<br>
<span class="HOEnZb"><font color="#888888"><br>
Doug<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>