Open Stack

Excerpts from Emilien Macchi's message of 2017-04-07 11:16:34 -0400:

> I've resurrected an old spec: https://review.openstack.org/#/c/243114/
> - addressed some comments and put TODOs that Doug and I will work
> together.
> The target is set to Queens but we might provide some proof-of-concept
> during Pike to make progress.
> TripleO project is very interested by this feature and I'm pretty sure
> other deployment tools might be too. Any feedback on the work here is
> more than welcome!

After discussing this with Emilien for a while this afternoon, I've
completely rewritten the spec. I abandoned the old one in favor of
https://review.openstack.org/#/c/454897/, but include a reference
to the old one for attribution and archaeologists.

One of the hardest aspects to address was the "mutable" option
feature we recently added. The current implementation of that feature
includes a lot of protective logic to try to avoid letting an
application reload a config setting with a different value unless
the application has explicitly said it knows how to handle cases
where the value changes (think about connection strings for long-lived
database connections).

Although I was a proponent of having the reload feature address
that issue, I'm not sure the complexity of the current implementation
is something we want to hang on to. In the new spec, I propose an
alternative treatment, which is to not cache mutable values in the
first place so the service never needs to receive a signal to reload.
The reload API is retained, and simply discards *everything* and
starts the configuration object over as though it was being freshly
created. This will be a big change, but the feature is new I think
the propose behavior better fits the spirit of the need anyway. Please
provide feedback if you think otherwise.

Doug