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

iKhan ik.ibadkhan at gmail.com
Mon Dec 16 05:39:12 UTC 2013


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 <harlowja at yahoo-inc.com>wrote:

>  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 for me. Others may be more tolerant
> though, seems worth further discussion IMHO.
>
>
> Sent from my really tiny device...
>
> On Dec 15, 2013, at 8:39 PM, "iKhan" <ik.ibadkhan at gmail.com> wrote:
>
>   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:50 AM, Joshua Harlow <harlowja at yahoo-inc.com>wrote:
>
>>  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 does require
>> some changes in the underlying codebase to do this "refresh").
>>
>>
>> Sent from my really tiny device...
>>
>> On Dec 15, 2013, at 3:11 AM, "iKhan" <ik.ibadkhan at gmail.com> 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 service, if we terminate those process
>> and restart them along with newly added backends. It might help us achieve
>> the target.
>>
>>
>> On Sun, Dec 15, 2013 at 12:49 PM, Joshua Harlow <harlowja at yahoo-inc.com>wrote:
>>
>>>  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 config values/affected by the old config values).
>>>
>>>  I would start with a simple trial of this if u want to so it, part if
>>> the issue will likely be oslo.config (can that library understand dynamic
>>> reloading?) and then cinder drivers themselves (perhaps u need to create a
>>> registry of drivers that can dynamically reload on config reloads?). Start
>>> out with something simple, isolate the reloading as much as u can to a
>>> single area (something like the mentioned registry of objects that can be
>>> reloaded when a SIGHUP arrives) and see how it goes.
>>>
>>>  It does seem like a nice feature if u can get it right :-)
>>>
>>> Sent from my really tiny device...
>>>
>>> On Dec 13, 2013, at 8:57 PM, "iKhan" <ik.ibadkhan at gmail.com> 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 create a child process that runs in background.
>>>
>>>  I am thinking of a way to re-initialize or dynamically configure
>>> cinder driver. So that I can accept the configuration from user on fly and
>>> perform operations. I think solution lies somewhere around
>>> "oslo.config.cfg", but I am still unclear about how re-initializing can be
>>> achieved.
>>>
>>>  Let know if anyone here is aware of any approach to re-initialize or
>>> dynamically configure a driver.
>>>
>>>  --
>>>  Thanks,
>>> IK
>>>
>>>   _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>>  --
>>  Thanks,
>> Ibad Khan
>> 9686594607
>>
>>  _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
>  --
>  Thanks,
> Ibad Khan
> 9686594607
>
>  _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Thanks,
Ibad Khan
9686594607
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131216/8b64b3c3/attachment.html>


More information about the OpenStack-dev mailing list