[openstack-dev] Re-initializing or dynamically configuring cinder driver

2013-12-13 Thread iKhan
Hi All, At present cinder driver can be only configured with adding entries in conf file. Once these driver related entries are modified or added in conf file, we need to restart cinder-volume service to validate the conf entries and create a child process that runs in background. I am thinking o

Re: [openstack-dev] Re-initializing or dynamically configuring cinder driver

2013-12-14 Thread Joshua Harlow
I don't currently know of a one size fits all solution here. There was talk at the summit of having the cinder app respond to a SIGHUP signal and attempting to reload config on this signal. Dynamic reloading is tricky business (basically u need to unravel anything holding references to the old c

Re: [openstack-dev] Re-initializing or dynamically configuring cinder driver

2013-12-15 Thread iKhan
I don't know if this is being planned in Icehouse, if not probably proposing an approach will help. We have seen cinder-volume service initialization part. Similarly if we can get our hands on child process that are running under cinder-volume service, if we terminate those process and restart them

Re: [openstack-dev] Re-initializing or dynamically configuring cinder driver

2013-12-15 Thread Mike Perez
On Sun, Dec 15, 2013 at 3:08 AM, iKhan wrote: > I don't know if this is being planned in Icehouse, if not probably > proposing an approach will help. We have seen cinder-volume service > initialization part. Similarly if we can get our hands on child process > that are running under cinder-volume

Re: [openstack-dev] Re-initializing or dynamically configuring cinder driver

2013-12-15 Thread Joshua Harlow
In your proposal does it means that the child process will be restarted (that means kill -9 or sigint??). If so, without taskflow to help (or other solution) that means operations in progress will be corrupted/lost. That seems bad... A SIGHUP approach could be handled more gracefully (but it doe

Re: [openstack-dev] Re-initializing or dynamically configuring cinder driver

2013-12-15 Thread iKhan
How about sending SIGTERM to child processes and then starting them? I know this is the hard way of achieving the objective and SIGHUP approach will handle it more gracefully. As you mentioned it is a major change, tentatively can we use SIGTERM to achieve the objective? On Mon, Dec 16, 2013 at 9

Re: [openstack-dev] Re-initializing or dynamically configuring cinder driver

2013-12-15 Thread Joshua Harlow
It depends on the "corruption" that u are willing to tolerate. Sigterm means the process just terminates, what if said process was 3/4 through some operation (create_volume for example)?? Personally I am willing to tolerate zero corruption, reliability and consistency are foundational things fo

Re: [openstack-dev] Re-initializing or dynamically configuring cinder driver

2013-12-15 Thread iKhan
Ok, I though we can make make cinder-volume aware of SIGTERM call and make sure it terminates with cleaning all the existing operations. If its not possible then probably SIGHUB is the only solution. :( On Mon, Dec 16, 2013 at 10:25 AM, Joshua Harlow wrote: > It depends on the "corruption" that

Re: [openstack-dev] Re-initializing or dynamically configuring cinder driver

2013-12-16 Thread Joshua Harlow
Ah, u might be able to do what u said. Try it out and see how far u can get :) I would be interested to know how u plan on waiting for all existing operations to finish. Maybe it's not so hard, not really sure... Sent from my really tiny device... On Dec 15, 2013, at 9:43 PM, "iKhan" mailto:ik

Re: [openstack-dev] Re-initializing or dynamically configuring cinder driver

2013-12-16 Thread Mark McLoughlin
Hi, On Sat, 2013-12-14 at 10:23 +0530, iKhan wrote: > Hi All, > > At present cinder driver can be only configured with adding entries in conf > file. Once these driver related entries are modified or added in conf file, > we need to restart cinder-volume service to validate the conf entries and >