Open Stack

On 05/14/2018 05:46 PM, Doug Hellmann wrote:
> Excerpts from Lance Bragstad's message of 2018-05-14 15:20:42 -0500:
>> On 05/14/2018 02:24 PM, Doug Hellmann wrote:
>>> Excerpts from Lance Bragstad's message of 2018-05-14 13:13:51 -0500:
>>>> On 03/19/2018 09:22 AM, Jim Rollenhagen wrote:
>>>>> On Sat, Mar 17, 2018 at 9:49 PM, Doug Hellmann <doug at doughellmann.com
>>>>> <mailto:doug at doughellmann.com>> wrote:
>>>>>
>>>>>     Both of those are good ideas.
>>>>>
>>>>>
>>>>> Agree. I like the socket idea a bit more as I can imagine some
>>>>> operators don't want config file changes automatically applied. Do we
>>>>> want to choose one to standardize on or allow each project (or
>>>>> operators, via config) the choice?
>>>> Just to recap, keystone would be listening for when it's configuration
>>>> file changes, and reinitialize the logger if the logging settings
>>>> changed, correct?
>>> Sort of.
>>>
>>> Keystone would need to do something to tell oslo.config to re-load the
>>> config files. In services that rely on oslo.service, this is handled
>>> with a SIGHUP handler that calls ConfigOpts.mutate_config_files(), so
>>> for Keystone you would want to do something similar.
>>>
>>> That is, you want to wait for an explicit notification from the operator
>>> that you should reload the config, and not just watch for the file to
>>> change. We could talk about using file modification as a trigger, but
>>> reloading is something that may need to be staged across several
>>> services in order so we chose for the first version to make the trigger
>>> explicit. Relying on watching files will also fail when the modified
>>> data is not in a file (which will be possible when we finish the driver
>>> work described in
>>> http://specs.openstack.org/openstack/oslo-specs/specs/queens/oslo-config-drivers.html).
>> Hmm, these are good points. I wonder if just converting to use
>> oslo.service would be a lower bar then?
> I thought keystone had moved away from that direction toward deploying
> only within Apache? I may be out of touch, or have misunderstood
> something, though.

Oh - never mind... For some reason I was thinking there was a way to use
oslo.service and Apache.

Either way, I'll do some more digging before tomorrow. I have this as a
topic on keystone's meeting agenda to go through our options [0]. If we
do come up with something that doesn't involve intercepting signals
(specifically for the reason noted by Kristi and Jim in the mod_wsgi
documentation), should the community goal be updated to include that
option? Just thinking that we can't be the only service in this position.

[0] https://etherpad.openstack.org/p/keystone-weekly-meeting

>
> Doug
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180514/63c50ea6/attachment.sig>