Open Stack

Is there anything preventing these techniques from being included in a library that could be re-used between a stand-alone tool or a service init-hook?

# Shawn Hartsock


----- Original Message -----
> From: "Oleg Gelbukh" <ogelbukh at mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> Sent: Tuesday, November 12, 2013 4:12:55 PM
> Subject: Re: [openstack-dev] [Nova] Configuration validation
> 
> 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
> >
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>