Open Stack

Hi,

I summarized a list of requirements to the config validation framework from
this thread and other sources, including IRC discussions so far:

https://gist.github.com/ogelbukh/7533029

Seems like we have 2 work items here, one being extension which adds more
complex flags types to Oslo.config, and the other is standalone service for
stateful validation of cfg across services. We're working on design for
such service in frame of Rubick project.

I'd really appreciate any help with prioritization of requirements from the
list above.

--
Best regards,
Oleg Gelbukh
Mirantis Labs
> To be fair, we test only the subset that is set via devstack on the
> stable side. That should be a common subset, but it is far from fully
> comprehensive. Nova has over 600 config variables, so additional tooling
> here would be goodness.

I'm surely not arguing against additional testing of config stuff, I'm
just saying I'm not sure there's an upgrade impact here. What we care
about across upgrades is that the conf stays legit. A set of offline
tests that look at the config shouldn't have anything useful to verify
or report, other than just "this thingy is now deprecated, beware!"

If we care about validating that reviewers didn't let some config
element be removed that wasn't already deprecated, that's something that
needs visibility into the two ends of the upgrade. I would think grenade
would be the place to do this since it has both hashes, and I definitely
think that could be instrumented easily. However, I don't think that has
much overlap with the config checker thing that was discussed at summit,
simply because it requires visibility into two trees.

--Dan


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131118/bb6a033c/attachment.html>