<div dir="ltr"><div>> DIms,<br></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 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, configurations,</div><div>>> etc in a common portal, this life-cycle hook would help.</div><div><br></div><div>> Is that information not available in the logs?</div><div><br></div><div>[Kanagaraj M] its available in log, but one who wants to collect these info in centralized portal,</div><div>it would help.</div><div><br></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><br></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><br></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><br></div><div>>> 2. For automatically discovering the OpenStack deployment, this hooks will</div><div>>> be very useful. Auto-discover-hook would report to pre-defined destinations</div><div>>> while starting/stopping the service.</div><div><br></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><br></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><br></div><div>>It feels very much like you're advocating that we create a thing like</div><div>>paste-deploy for non-WSGI apps: allow anyone to insert anything into</div><div>>the executing process for any purpose and with little control on the</div><div>>application authors' part. That introduces potential stability issues,</div><div>>and a lot of questions that haven't been answered. For example:</div><div><br></div><div>>Does service startup block until all of the plugins are done? If not,</div><div>>do we need to have a timeout management system built in or do we run</div><div>>the plugins in their own thread/subprocess so they can run in the</div><div>>background?</div><div><br></div><div>>Can a plugin change the execution of the service in some way (you</div><div>>mentioned having a plugin download config files when we spoke at the</div><div>>summit, is that still something you want to slip in this way instead of</div><div>>putting it into oslo.config)?</div><div><br></div><div>>Can a plugin cause the service to not start at all by exiting?</div><div><br></div><div>>What happens if one plugin fails but others succeed? Do we keep running?</div><div><br></div><div>>What information about the service can a plugin see? It's running in the</div><div>>same process, so it could see the configuration object, for example.</div><div>>It would only be able to see configuration options it adds (yes, that</div><div>>would work) or that were registered by the application before the plugin</div><div>>is run. So, not necessarily all options but potentially many, with more</div><div>>and more as apps shift to pre-registering all of their options in one</div><div>>place. Assuming these are things the deployer has selectively installed,</div><div>>maybe that's OK. OTOH, it does open another security surface.</div><div><br></div><div>>What happens when a service is told to restart its workers? Do the</div><div>>plugins run again?</div><div><br></div><div>>Can a plugin start listening for network connections on its own? Connect</div><div>>to the message bus?  Provide an RPC endpoint? Start processes? Threads?</div><div><br></div><div>[KanagarajM] It gives me a lots insight on what are different problems </div><div>would come and i really thank you. </div><div>Hooks will be provided by community and/or deployers. while community</div><div>provides, those hooks will be well documented, tested and configuration would be</div><div>provided. so all of the above mentioned aspects would be taken care well by</div><div>community based on the hooks functionality. And deployer also would take</div><div> care of similar safety measurement before using their hooks similar to how</div><div>would they take care when using startup scripts.</div><div><br></div><div><br></div><div><br></div><div>>> Regards</div><div>>> Kanagaraj M</div><div>>></div><div>>> On Wed, May 11, 2016 at 7:05 PM, Davanum Srinivas <<a href="mailto:davanum@gmail.com">davanum@gmail.com</a>> 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><br></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><br></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><br></div><div><br></div><div>Regards</div><div>Kanagaraj M</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 13, 2016 at 11:38 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-13 14:46:06 +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 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, configurations,<br>
> etc in a common portal, this life-cycle hook would help.<br>
<br>
</span>Is that information not available in the logs?<br>
<span class=""><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>
</span>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>
<span class=""><br>
> 2. For automatically discovering the OpenStack deployment, this hooks will<br>
> be very useful. Auto-discover-hook would report to pre-defined destinations<br>
> while starting/stopping the service.<br>
<br>
</span>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>
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>
<span class=""><br>
<br>
> Regards<br>
> Kanagaraj M<br>
><br>
> On Wed, May 11, 2016 at 7:05 PM, Davanum Srinivas <<a href="mailto:davanum@gmail.com">davanum@gmail.com</a>> 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>
</span>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>
<div class="HOEnZb"><div class="h5"><br>
> > ><br>
> > > Also using start-up script does not suite for below situations:<br>
> > > oslo.service spawns component in more than one processes<br>
> > > when workers count is more than 1. In this case, if we want<br>
> > > to execute some activities before/after on each process, start-up<br>
> > > script does not help.<br>
> > ><br>
> > > So to support these scenarios, thinking of below enhancement<br>
> > > in oslo.service as mentioned in blueprint [1]<br>
> > ><br>
> > > Most of the projects in OpenStack does make use of oslo.service<br>
> > > library to create/start/stop the service api and back-end components.<br>
> > > And by providing an configurable python hooks as below, and<br>
> > > enhance oslo.service to execute them appropriately.<br>
> > ><br>
> > > [oslo_service]<br>
> > > List of of pre-hook executed in sequence<br>
> > > pre-hook=<comma separated python module used as hooks><br>
> > > List of of pre-hook executed in sequence<br>
> > > post-hook=<comma separated python module used as hooks><br>
> > ><br>
> > > And to make sure the hooks does not break the running process,<br>
> > > try to execute them in try block.<br>
> > ><br>
> > > Kindly provide your comments/inputs. Thanks<br>
> > ><br>
> > > [1]: <a href="https://blueprints.launchpad.net/oslo.service/+spec/service-hook" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/oslo.service/+spec/service-hook</a><br>
> > ><br>
> > > Regards,<br>
> > > Kanagaraj M<br>
> > ><br>
> > ><br>
> > __________________________________________________________________________<br>
> > > OpenStack Development Mailing List (not for usage questions)<br>
> > > Unsubscribe:<br>
> > <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>
> > ><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > Davanum Srinivas :: <a href="https://twitter.com/dims" rel="noreferrer" target="_blank">https://twitter.com/dims</a><br>
> ><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>
> ><br>
<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></div>