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
>
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
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
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
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
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
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
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
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
