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

Some work on this was done in Oslo during Havana, see:

  https://blueprints.launchpad.net/oslo/+spec/service-restart
  https://blueprints.launchpad.net/oslo/+spec/cfg-reload-config-files

Thanks,
Mark.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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.ibadk...@gmail.com>> wrote:

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 
mailto:harlo...@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" 
mailto:ik.ibadk...@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 
mailto:harlo...@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" 
mailto:ik.ibadk...@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 
mailto:harlo...@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" 
mailto:ik.ibadk...@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Thanks,
Ibad Khan
9686594607
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://list

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 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"  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 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"  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 
>> 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"  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@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>>  --
>>  Thanks,
>> Ibad Khan
>> 9686594607
>>
>>  ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
>  --
>  Thanks,
> Ibad Khan
> 9686594607
>
>  ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> Open

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 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" 
mailto:ik.ibadk...@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 
mailto:harlo...@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" 
mailto:ik.ibadk...@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 
mailto:harlo...@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" 
mailto:ik.ibadk...@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Thanks,
Ibad Khan
9686594607
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Thanks,
Ibad Khan
9686594607
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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:50 AM, Joshua Harlow 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"  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 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"  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@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
>  --
>  Thanks,
> Ibad Khan
> 9686594607
>
>  ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Thanks,
Ibad Khan
9686594607
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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 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" 
mailto:ik.ibadk...@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 
mailto:harlo...@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" 
mailto:ik.ibadk...@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Thanks,
Ibad Khan
9686594607
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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 service, if we terminate those process
> and restart them along with newly added backends. It might help us achieve
> the target.
>


It's not in the plans [1][2]. Having the idea spec'd out in the wiki and
setting an agenda item [3] for the next meeting
can get things going though.

[1] - https://launchpad.net/cinder/+milestone/icehouse-2
[2] - https://launchpad.net/cinder/+milestone/icehouse-3
[3] - https://wiki.openstack.org/wiki/CinderMeetings


-Mike Perez
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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 along with newly added backends. It might help us achieve
the target.


On Sun, Dec 15, 2013 at 12:49 PM, Joshua Harlow 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"  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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Thanks,
Ibad Khan
9686594607
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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 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" 
mailto:ik.ibadk...@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[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 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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev