Open Stack

Gary, Nikola,

The diagnostics service being developed by our labs could be of interest
for you [1]

The first use case we're working on is exactly what you suggest: validation
of configuration parameters across services before running them [2]

We now use a mix of approaches:
1. introduce extended config parameters typization and validate values
against those extended types (e.g. 'ip address' or 'port range')
2. validate cross-service configurations for consistency with scripted
inspections
3. validate parameter values using production rules

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.

[1] https://github.com/MirantisLabs/rubick/
[2] https://wiki.openstack.org/wiki/Rubick/OpenStack_Integration


On Mon, Nov 11, 2013 at 4:31 PM, Gary Kotton <gkotton at vmware.com> wrote:

> Hi,
> I think that John has a very valid point. My understanding from the
> session was that this should be a stand alone tool that will also work
> across services, that is, if neutron is configured then it will check that
> the neutron credentials are correct.
> Thanks
> Gary
>
> On 11/11/13 1:55 PM, "John Garbutt" <john at johngarbutt.com> wrote:
>
> >I like the idea of a more general config validation phase to help
> >people when first starting out.
> >
> >My worry is that it would slow down the starting back up of servers
> >for people deploying their code using CI, where the have already
> >verified their configuration. But maybe its so fast I don't care, but
> >I just felt I should raise that.
> >
> >John
> >
> >On 11 November 2013 11:44, Nikola Đipanov <ndipanov at redhat.com> wrote:
> >> Hey all,
> >>
> >> During the summit session on the the VMWare driver roadmap, a topic of
> >> validating the passed configuration prior to starting services came up
> >> (see [1] for more detail on how it's connected to that specific topic).
> >>
> >> Several ideas were thrown around during the session mostly documented in
> >> [1].
> >>
> >> There are a few more cases when something like this could be useful (see
> >> bug [2] and related patch [3]), and I was wondering if a slightly
> >> different approach might be useful. For example use an already existing
> >> validation hook in the service class [4] to call into a validation
> >> framework that will potentially stop the service with proper
> >> logging/notifications. The obvious benefit would be that there is no
> >> pre-run required from the user, and the danger of running a
> >> misconfigured stack is smaller.
> >>
> >> Since there is already a blueprint raised based on the etherpad [1]- I
> >> am bringing this up here so that we can agree on the approach, before
> >> raising another one to solve the same problem.
> >>
> >> Thanks,
> >>
> >> Nikola
> >>
> >> [1] https://etherpad.openstack.org/p/T4tQMQf5uS
> >> [2] https://bugs.launchpad.net/nova/+bug/1243614
> >> [3] https://review.openstack.org/#/c/53303/
> >> [4]
> >>http://git.openstack.org/cgit/openstack/nova/tree/nova/service.py#n283
> >>
> >> _______________________________________________
> >> 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/20131113/eaecdb2d/attachment.html>