<div dir="ltr">Gary, Nikola,<div><br></div><div>The diagnostics service being developed by our labs could be of interest for you [1]</div><div><br></div><div>The first use case we're working on is exactly what you suggest: validation of configuration parameters across services before running them [2]</div>
<div><br></div><div>We now use a mix of approaches:</div><div>1. introduce extended config parameters typization and validate values against those extended types (e.g. 'ip address' or 'port range')</div><div>
2. validate cross-service configurations for consistency with scripted inspections</div><div>3. validate parameter values using production rules</div><div><br></div><div>We will consider contributing code that implements those approaches to projects where they suit most (e.g. extending parameters types and correspoding validations in oslo.config, like Mark proposed in this thread). But we would like to stick to the idea of tool that could function independently to validate configurations and architecture for cloud operators.</div>
<div><br></div><div>[1] <a href="https://github.com/MirantisLabs/rubick/">https://github.com/MirantisLabs/rubick/</a></div><div>[2] <a href="https://wiki.openstack.org/wiki/Rubick/OpenStack_Integration">https://wiki.openstack.org/wiki/Rubick/OpenStack_Integration</a></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 11, 2013 at 4:31 PM, Gary Kotton <span dir="ltr"><<a href="mailto:gkotton@vmware.com" target="_blank">gkotton@vmware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
I think that John has a very valid point. My understanding from the<br>
session was that this should be a stand alone tool that will also work<br>
across services, that is, if neutron is configured then it will check that<br>
the neutron credentials are correct.<br>
Thanks<br>
<span class="HOEnZb"><font color="#888888">Gary<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 11/11/13 1:55 PM, "John Garbutt" <<a href="mailto:john@johngarbutt.com">john@johngarbutt.com</a>> wrote:<br>
<br>
>I like the idea of a more general config validation phase to help<br>
>people when first starting out.<br>
><br>
>My worry is that it would slow down the starting back up of servers<br>
>for people deploying their code using CI, where the have already<br>
>verified their configuration. But maybe its so fast I don't care, but<br>
>I just felt I should raise that.<br>
><br>
>John<br>
><br>
>On 11 November 2013 11:44, Nikola Đipanov <<a href="mailto:ndipanov@redhat.com">ndipanov@redhat.com</a>> wrote:<br>
>> Hey all,<br>
>><br>
>> During the summit session on the the VMWare driver roadmap, a topic of<br>
>> validating the passed configuration prior to starting services came up<br>
>> (see [1] for more detail on how it's connected to that specific topic).<br>
>><br>
>> Several ideas were thrown around during the session mostly documented in<br>
>> [1].<br>
>><br>
>> There are a few more cases when something like this could be useful (see<br>
>> bug [2] and related patch [3]), and I was wondering if a slightly<br>
>> different approach might be useful. For example use an already existing<br>
>> validation hook in the service class [4] to call into a validation<br>
>> framework that will potentially stop the service with proper<br>
>> logging/notifications. The obvious benefit would be that there is no<br>
>> pre-run required from the user, and the danger of running a<br>
>> misconfigured stack is smaller.<br>
>><br>
>> Since there is already a blueprint raised based on the etherpad [1]- I<br>
>> am bringing this up here so that we can agree on the approach, before<br>
>> raising another one to solve the same problem.<br>
>><br>
>> Thanks,<br>
>><br>
>> Nikola<br>
>><br>
>> [1] <a href="https://etherpad.openstack.org/p/T4tQMQf5uS" target="_blank">https://etherpad.openstack.org/p/T4tQMQf5uS</a><br>
>> [2] <a href="https://bugs.launchpad.net/nova/+bug/1243614" target="_blank">https://bugs.launchpad.net/nova/+bug/1243614</a><br>
>> [3] <a href="https://review.openstack.org/#/c/53303/" target="_blank">https://review.openstack.org/#/c/53303/</a><br>
>> [4]<br>
>><a href="http://git.openstack.org/cgit/openstack/nova/tree/nova/service.py#n283" target="_blank">http://git.openstack.org/cgit/openstack/nova/tree/nova/service.py#n283</a><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>
><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>
<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></div></blockquote></div><br></div>