Re: [openstack-dev] [oslo][oslo.config] Reloading configuration of service

2015-09-29 Thread Doug Hellmann
Excerpts from Joshua Harlow's message of 2015-09-29 11:39:16 -0700:
> mhorban wrote:
> >  > Excerpts from Josh's message:
> >
> >  >> So a few 'event' like constructs/libraries that I know about:
> >  >>
> >  >>
> > http://docs.openstack.org/developer/taskflow/types.html#taskflow.types.notifier.Notifier
> >
> >  >>
> >  >>
> >  >> I'd be happy to extract that and move to somewhere else if needed, it
> >  >> provides basic event/pub/sub kind of activities for taskflow
> > (in-memory,
> >  >> not over rpc...)
> >
> > I've investigated several event libraries...And chose taskflow because
> > first of all it fits all our requirements and it is already used in
> > openstack.
> 
> Very cool, will check more of that review out,
> 
> Although if we are going to go forward with this it's probably a good 
> idea to split that notification class/code out of taskflow and into its 
> own tiny library, so that taskflow and oslo.service can use it (this is 
> how https://github.com/openstack/automaton and 
> https://github.com/openstack/futurist came into being). That avoids 
> having to bring in all of taskflow when you are using just *one* of its 
> types/classes (and aren't really using the rest of taskflow).

+1 to streamlining

> 
> >
> >
> >  > Excerpts from Doug's message
> >
> >  >> We probably want the ability to have multiple callbacks. There are
> >  >> already a lot of libraries available on PyPI for handling "events" like
> >  >> this, so maybe we can pick one of those that is well maintained and
> >  >> integrate it with oslo.service?
> >
> > I've created raw review in oslo.service
> > https://review.openstack.org/#/c/228892/ .
> > I've used taskflow library(as Josh proposed).
> > By default I added one handler that reloads global configuration.
> > What do you think about such implementation?
> >
> > Marian
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo][oslo.config] Reloading configuration of service

2015-09-29 Thread Joshua Harlow

mhorban wrote:

 > Excerpts from Josh's message:

 >> So a few 'event' like constructs/libraries that I know about:
 >>
 >>
http://docs.openstack.org/developer/taskflow/types.html#taskflow.types.notifier.Notifier

 >>
 >>
 >> I'd be happy to extract that and move to somewhere else if needed, it
 >> provides basic event/pub/sub kind of activities for taskflow
(in-memory,
 >> not over rpc...)

I've investigated several event libraries...And chose taskflow because
first of all it fits all our requirements and it is already used in
openstack.


Very cool, will check more of that review out,

Although if we are going to go forward with this it's probably a good 
idea to split that notification class/code out of taskflow and into its 
own tiny library, so that taskflow and oslo.service can use it (this is 
how https://github.com/openstack/automaton and 
https://github.com/openstack/futurist came into being). That avoids 
having to bring in all of taskflow when you are using just *one* of its 
types/classes (and aren't really using the rest of taskflow).





 > Excerpts from Doug's message

 >> We probably want the ability to have multiple callbacks. There are
 >> already a lot of libraries available on PyPI for handling "events" like
 >> this, so maybe we can pick one of those that is well maintained and
 >> integrate it with oslo.service?

I've created raw review in oslo.service
https://review.openstack.org/#/c/228892/ .
I've used taskflow library(as Josh proposed).
By default I added one handler that reloads global configuration.
What do you think about such implementation?

Marian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [oslo][oslo.config] Reloading configuration of service

2015-09-29 Thread mhorban

> Excerpts from Josh's message:

>> So a few 'event' like constructs/libraries that I know about:
>>
>> 
http://docs.openstack.org/developer/taskflow/types.html#taskflow.types.notifier.Notifier 


>>
>>
>> I'd be happy to extract that and move to somewhere else if needed, it
>> provides basic event/pub/sub kind of activities for taskflow 
(in-memory,

>> not over rpc...)

I've investigated several event libraries...And chose taskflow because 
first of all it fits all our requirements and it is already used in 
openstack.



> Excerpts from Doug's message

>> We probably want the ability to have multiple callbacks. There are
>> already a lot of libraries available on PyPI for handling "events" like
>> this, so maybe we can pick one of those that is well maintained and
>> integrate it with oslo.service?

I've created raw review in oslo.service 
https://review.openstack.org/#/c/228892/ .

I've used taskflow library(as Josh proposed).
By default I added one handler that reloads global configuration.
What do you think about such implementation?

Marian
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo][oslo.config] Reloading configuration of service

2015-09-17 Thread Joshua Harlow

Agreed, +1 :)

Gotta start somewhere to get to somewhere else ;)

mhorban wrote:

Hi Josh,

 > Sounds like a useful idea if projects can plug-in themselves into the
 > reloading process. I definitely think there needs to be a way for
 > services to plug-in to this, although I'm not quite sure it will be
 > sufficient at the current time though.
 >
 > An example of why:
 >
 > -
 >
https://github.com/openstack/cinder/blob/stable/kilo/cinder/volume/__init__.py#L24

 > (unless this module is purged from python and reloaded it will likely
 > not reload correctly).
 >
 > Likely these can all be easily fixed (I just don't know how many of
 > those exist in the various projects); but I guess we have to start
 > somewhere so getting the underlying code able to be reloaded is a first
 > step of likely many.

Each of openstack component should contain code responsible for
reloading such objects.
What objects will be reloaded? It depends of inspire and desire of
developers/users.
Writing such code is a second step.

Marian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo][oslo.config] Reloading configuration of service

2015-09-17 Thread Joshua Harlow

So a few 'event' like constructs/libraries that I know about:

http://docs.openstack.org/developer/taskflow/types.html#taskflow.types.notifier.Notifier 



I'd be happy to extract that and move to somewhere else if needed, it 
provides basic event/pub/sub kind of activities for taskflow (in-memory, 
not over rpc...)


A second one that I almost used in taskflow (but didn't because it has 
more of a global registry, which didn't suit taskflow's non-global 
usage) that might fit this usage just fine...


https://pythonhosted.org/blinker/

Both could probably do the job...

-Josh

Doug Hellmann wrote:

Excerpts from mhorban's message of 2015-09-17 10:26:28 +0300:

Hi Doug,

  >  Rather than building hooks into oslo.config, why don't we build them
  >  into the thing that is catching the signal. That way the app can do lots
  >  of things in response to a signal, and one of them might be reloading
  >  the configuration.

Hm... Yes... It is really stupid idea to put reloading hook into
oslo.config.
I'll move that hook mechanism into oslo.service. oslo.service is
responsible for catching/handling signals.

Is it enough to have one callback function? Or should I must add ability
to register many different callback functions?

What is your point of view?

Marian



We probably want the ability to have multiple callbacks. There are
already a lot of libraries available on PyPI for handling "events" like
this, so maybe we can pick one of those that is well maintained and
integrate it with oslo.service?

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo][oslo.config] Reloading configuration of service

2015-09-17 Thread Doug Hellmann
Excerpts from mhorban's message of 2015-09-17 10:26:28 +0300:
> Hi Doug,
> 
>  > Rather than building hooks into oslo.config, why don't we build them
>  > into the thing that is catching the signal. That way the app can do lots
>  > of things in response to a signal, and one of them might be reloading
>  > the configuration.
> 
> Hm... Yes... It is really stupid idea to put reloading hook into 
> oslo.config.
> I'll move that hook mechanism into oslo.service. oslo.service is 
> responsible for catching/handling signals.
> 
> Is it enough to have one callback function? Or should I must add ability 
> to register many different callback functions?
> 
> What is your point of view?
> 
> Marian
> 

We probably want the ability to have multiple callbacks. There are
already a lot of libraries available on PyPI for handling "events" like
this, so maybe we can pick one of those that is well maintained and
integrate it with oslo.service?

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [oslo][oslo.config] Reloading configuration of service

2015-09-17 Thread mhorban

Hi Doug,

> Rather than building hooks into oslo.config, why don't we build them
> into the thing that is catching the signal. That way the app can do lots
> of things in response to a signal, and one of them might be reloading
> the configuration.

Hm... Yes... It is really stupid idea to put reloading hook into 
oslo.config.
I'll move that hook mechanism into oslo.service. oslo.service is 
responsible for catching/handling signals.


Is it enough to have one callback function? Or should I must add ability 
to register many different callback functions?


What is your point of view?

Marian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [oslo][oslo.config] Reloading configuration of service

2015-09-17 Thread mhorban

Hi Josh,

> Sounds like a useful idea if projects can plug-in themselves into the
> reloading process. I definitely think there needs to be a way for
> services to plug-in to this, although I'm not quite sure it will be
> sufficient at the current time though.
>
> An example of why:
>
> -
> 
https://github.com/openstack/cinder/blob/stable/kilo/cinder/volume/__init__.py#L24 


> (unless this module is purged from python and reloaded it will likely
> not reload correctly).
>
> Likely these can all be easily fixed (I just don't know how many of
> those exist in the various projects); but I guess we have to start
> somewhere so getting the underlying code able to be reloaded is a first
> step of likely many.

Each of openstack component should contain code responsible for 
reloading such objects.
What objects  will be reloaded? It depends of inspire and desire of 
developers/users.

Writing such code is a second step.

Marian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo][oslo.config] Reloading configuration of service

2015-09-15 Thread Doug Hellmann
Excerpts from mhorban's message of 2015-09-15 19:38:58 +0300:
> Hi guys,
> 
> I would like to talk about reloading config during reloading service.
> Now we have ability to reload config of service with SIGHUP signal.
> Right now SIGHUP causes just calling conf.reload_config_files().
> As result configuration is updated, but services don't know about it, 
> there is no way to notify them.
> I've created review https://review.openstack.org/#/c/213062/ to allow to 
> execute service's code on reloading config event.
> Possible usage can be https://review.openstack.org/#/c/223668/.
> 
> Any ideas or suggestions
> 

Rather than building hooks into oslo.config, why don't we build them
into the thing that is catching the signal. That way the app can do lots
of things in response to a signal, and one of them might be reloading
the configuration.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo][oslo.config] Reloading configuration of service

2015-09-15 Thread Joshua Harlow
Sounds like a useful idea if projects can plug-in themselves into the 
reloading process. I definitely think there needs to be a way for 
services to plug-in to this, although I'm not quite sure it will be 
sufficient at the current time though.


An example of why:

- 
https://github.com/openstack/cinder/blob/stable/kilo/cinder/volume/__init__.py#L24 
(unless this module is purged from python and reloaded it will likely 
not reload correctly).


Likely these can all be easily fixed (I just don't know how many of 
those exist in the various projects); but I guess we have to start 
somewhere so getting the underlying code able to be reloaded is a first 
step of likely many.


- Josh

mhorban wrote:

Hi guys,

I would like to talk about reloading config during reloading service.
Now we have ability to reload config of service with SIGHUP signal.
Right now SIGHUP causes just calling conf.reload_config_files().
As result configuration is updated, but services don't know about it,
there is no way to notify them.
I've created review https://review.openstack.org/#/c/213062/ to allow to
execute service's code on reloading config event.
Possible usage can be https://review.openstack.org/#/c/223668/.

Any ideas or suggestions

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [oslo][oslo.config] Reloading configuration of service

2015-09-15 Thread mhorban

Hi guys,

I would like to talk about reloading config during reloading service.
Now we have ability to reload config of service with SIGHUP signal.
Right now SIGHUP causes just calling conf.reload_config_files().
As result configuration is updated, but services don't know about it, 
there is no way to notify them.
I've created review https://review.openstack.org/#/c/213062/ to allow to 
execute service's code on reloading config event.

Possible usage can be https://review.openstack.org/#/c/223668/.

Any ideas or suggestions

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev