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 __________________________________________________________________________ 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
