[openstack-dev] [Nova] Configuration validation

Oleg Gelbukh ogelbukh at mirantis.com
Tue Nov 19 08:20:19 UTC 2013


Tracy,

I've created etherpad with the summary:
https://etherpad.openstack.org/p/w5BwMtCG6z

--
Best regards,
Oleg Gelbukh


On Mon, Nov 18, 2013 at 11:17 PM, Tracy Jones <tjones at vmware.com> wrote:

> 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.
>
> On Nov 18, 2013, at 10:54 AM, Oleg Gelbukh <ogelbukh at mirantis.com> wrote:
>
> 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
>  _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> 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/20131119/0703734e/attachment.html>


More information about the OpenStack-dev mailing list