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
