<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Oleg - this is great!  I tried to find you on IRC to recommend we put this on a etherpad so several of us can collaborate together on requirements and brainstorming.  <div><br><div><div>On Nov 18, 2013, at 10:54 AM, Oleg Gelbukh <<a href="mailto:ogelbukh@mirantis.com">ogelbukh@mirantis.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><p dir="ltr">Hi,</p><p dir="ltr">I summarized a list of requirements to the config validation framework from this thread and other sources, including IRC discussions so far:</p><p dir="ltr"><a href="https://gist.github.com/ogelbukh/7533029">https://gist.github.com/ogelbukh/7533029</a></p><p dir="ltr">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.</p><p dir="ltr">I'd really appreciate any help with prioritization of requirements from the list above.</p><p dir="ltr">--<br>
Best regards,<br>
Oleg Gelbukh<br>
Mirantis Labs<br></p>
<div class="gmail_quot<blockquote class=" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> To be fair, we test only the subset that is set via devstack on the<br>
> stable side. That should be a common subset, but it is far from fully<br>
> comprehensive. Nova has over 600 config variables, so additional tooling<br>
> here would be goodness.<br>
<br>
I'm surely not arguing against additional testing of config stuff, I'm<br>
just saying I'm not sure there's an upgrade impact here. What we care<br>
about across upgrades is that the conf stays legit. A set of offline<br>
tests that look at the config shouldn't have anything useful to verify<br>
or report, other than just "this thingy is now deprecated, beware!"<br>
<br>
If we care about validating that reviewers didn't let some config<br>
element be removed that wasn't already deprecated, that's something that<br>
needs visibility into the two ends of the upgrade. I would think grenade<br>
would be the place to do this since it has both hashes, and I definitely<br>
think that could be instrumented easily. However, I don't think that has<br>
much overlap with the config checker thing that was discussed at summit,<br>
simply because it requires visibility into two trees.<br>
<br>
--Dan<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></blockquote></div><br></div></body></html>