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" <ogelb...@mirantis.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@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 <gkot...@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" <j...@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 <ndipa...@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@lists.openstack.org > > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > >_______________________________________________ > > >OpenStack-dev mailing list > > >OpenStack-dev@lists.openstack.org > > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
