> 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
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
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:
>
> -
>
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
Most of openstack services use ProcessLauncher(located in oslo.services)
to run services, fork new worker processes, reload configuration, etc.
Initialization of services in master process usually contains opening of
sockets, so that socket will be inherited in child processes. Then
Hi all,
During development process in nova I faced with an issue related with config
options. Now we have lists of config options and registering options mixed
with source code in regular files.
From one side it can be convenient: to have module-encapsulated config
options. But problems appear
On Tue, 16 Jun 2015, Sean Dague wrote:
I'd expect nova to be running on http://localhost/compute not
http://localhost:8774 when running under wsgi. That's going to probably
interestingly break a lot of weird assumptions by different projects,
but that's part of the reason for doing this
