Open Stack

In principle I like the idea and concept, a lot. In practice I don't think glance code is ready in a state that we could say SIGHUP reloads our configs. Even more my concern is that based on the behavior seen some config options gets picked up and some does not.

As long as we do not have definite list documented what options gets updated on the fly and what is the actual behavior at the point when new config is picked up (lets say we have some locks in place and locking folder gets updated, what happens?) I don't think we should be taking this functionality in. Even the current behavior is fundamentally broken, at least it's broken in a way that it is consistent and the behavior is known.


-          Erno (jokke_) Kuvaja

kuvaja at hp.com

From: Kekane, Abhishek [mailto:Abhishek.Kekane at nttdata.com]
Sent: 03 September 2014 14:39
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [glance][feature freeze exception] Proposal for using Launcher/ProcessLauncher for launching services

Hi All,

Please give your support me for applying the  freeze exception for using oslo-incubator service framework in glance, based on the following blueprint:

https://blueprints.launchpad.net/glance/+spec/use-common-service-framework

I have ensured that after making these changes everything is working smoothly.

I have done the functional testing for following three scenarios:

1.       Enabled SSL and checked requests are processed by the Api service before and after SIGHUP signal

2.       Disabled SSL and  checked requests are processed by the Api service before and after SIGHUP signal

3.       I have also ensured reloading of the parameters like ilesystem_store_datadir, filesystem_store_datadirs are  working effectively after sending the SIGHUP signal.

To test 1st and 2nd I have created a python script which will send multiple requests to glance at a time and added a chron job to send a SIGHUP signal to the parent process.
I have tested above script for 1 hour and confirmed every request has been processed successfully.

Please consider this feature to be a part of Juno release.



Thanks & Regards,

Abhishek Kekane


From: Kekane, Abhishek [mailto:Abhishek.Kekane at nttdata.com]
Sent: 02 September 2014 19:11
To: OpenStack Development Mailing List (openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>)
Subject: [openstack-dev] [glance][feature freeze exception] Proposal for using Launcher/ProcessLauncher for launching services

Hi All,

I'd like to ask for a feature freeze exception for using oslo-incubator service framework in glance, based on the following blueprint:

https://blueprints.launchpad.net/glance/+spec/use-common-service-framework


The code to implement this feature is under review at present.

1. Sync oslo-incubator service module in glance: https://review.openstack.org/#/c/117135/2
2. Use Launcher/ProcessLauncher in glance: https://review.openstack.org/#/c/117988/


If we have this feature in glance then we can able to use features like reload glance configuration file without restart, graceful shutdown etc.
Also it will use common code like other OpenStack projects nova, keystone, cinder does.


We are ready to address all the concerns of the community if they have any.


Thanks & Regards,

Abhishek Kekane

______________________________________________________________________
Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding

______________________________________________________________________
Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140903/47b1e34a/attachment.html>