Re: [openstack-dev] [Nova] Configuration validation

[Oleg Gelbukh]

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  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  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@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

Re: [openstack-dev] [Nova] Configuration validation

[Tracy Jones]

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  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@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

Re: [openstack-dev] [Nova] Configuration validation

[Oleg Gelbukh]

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@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

Re: [openstack-dev] [Nova] Configuration validation

[Dan Smith]

> 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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Configuration validation

[Sean Dague]

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.

Sean Dague
http://dague.net
On Nov 18, 2013 7:35 AM, "Dan Smith"  wrote:

> > Another issue that we might want to try and solve with this (and imho
> > another reason to keep the framework for this in oslo) is that we might
> > want to make these update aware, and allow for some graceful degradation
> > or something similar when for example an updated service is stated with
> > an outdated config.
> >
> > Maybe Dan could weigh in on this?
>
> Well, AFAIK, we require config compatibility between subsequent
> versions, so there really shouldn't be anything to report. It might be
> useful to report, when running the havana tool against an
> upgraded-from-grizzly config which things are deprecated though.
>
> We already test that the config upgrade works in the grenade test in the
> gate, so there really shouldn't be any degredation experienced by the
> user after an upgrade...
>
> --Dan
>
>
> ___
> 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

Re: [openstack-dev] [Nova] Configuration validation

[Dan Smith]

> Another issue that we might want to try and solve with this (and imho
> another reason to keep the framework for this in oslo) is that we might
> want to make these update aware, and allow for some graceful degradation
> or something similar when for example an updated service is stated with
> an outdated config.
> 
> Maybe Dan could weigh in on this?

Well, AFAIK, we require config compatibility between subsequent
versions, so there really shouldn't be anything to report. It might be
useful to report, when running the havana tool against an
upgraded-from-grizzly config which things are deprecated though.

We already test that the config upgrade works in the grenade test in the
gate, so there really shouldn't be any degredation experienced by the
user after an upgrade...

--Dan


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Configuration validation

[Nikola Đipanov]

On 13/11/13 18:49, Doug Hellmann wrote:
> 
> 
> 
> On Mon, Nov 11, 2013 at 6:08 PM, Mark McLoughlin  > wrote:
> 
> Hi Nikola,
> 
> On Mon, 2013-11-11 at 12:44 +0100, Nikola Đipanov 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.
> 
> One thing worth trying would be to encode the validation rules in the
> config option declaration.
> 
> Some rules could be straightforward, like:
> 
> opts = [
>   StrOpt('foo_url',
>  validate_rule=cfg.MatchesRegexp('(git|http)://')),
> ]
> 
> but the rule you describe is more complex e.g.
> 
> def validate_proxy_url(conf, group, key, value):
> if not conf.vnc_enabled:
> return
> if conf.ssl_only and value.startswith("http://";):
> raise ValueError('ssl_only option detected, but ...')
> 
> opts = [
>   StrOpt('novncproxy_base_url',
>  validate_rule=validate_proxy_url),
>   ...
> ]
> 
> I'm not sure I love this yet, but it's worth experimenting with.
> 
> 
> One thing to keep in mind with the move to calling register_opt() at
> runtime instead of import time is the service may run for a little while
> before it reaches the point in the code where the option validation code
> is triggered. So I like the idea, but we may want a shortcut for validation.
> 
> We could add a small app to oslo.config that will load the options in
> the same way the conf generator and doc tool will, but then also read
> the configuration file and perform the validation. Another benefit of a
> separate tool is it could produce a full list of warnings and errors,
> rather than having the service stop on each bad value.
> 

Another issue that we might want to try and solve with this (and imho
another reason to keep the framework for this in oslo) is that we might
want to make these update aware, and allow for some graceful degradation
or something similar when for example an updated service is stated with
an outdated config.

Maybe Dan could weigh in on this?

N.

> Doug
> 
> 
> 
> ___
> 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

Re: [openstack-dev] [Nova] Configuration validation

[Lorin Hochstein]

On Wed, Nov 13, 2013 at 3:38 PM, Doug Hellmann
wrote:

>
>
>
> On Wed, Nov 13, 2013 at 2:19 PM, Oleg Gelbukh wrote:
>
>> Doug,
>>
>>
>> On Wed, Nov 13, 2013 at 9:49 PM, Doug Hellmann <
>> doug.hellm...@dreamhost.com> wrote:
>>
>>>
>>>
>>>
>>>  On Mon, Nov 11, 2013 at 6:08 PM, Mark McLoughlin wrote:
>>>

 One thing worth trying would be to encode the validation rules in the
 config option declaration.

 Some rules could be straightforward, like:

 opts = [
   StrOpt('foo_url',
  validate_rule=cfg.MatchesRegexp('(git|http)://')),
 ]

 but the rule you describe is more complex e.g.

 def validate_proxy_url(conf, group, key, value):
 if not conf.vnc_enabled:
 return
 if conf.ssl_only and value.startswith("http://";):
 raise ValueError('ssl_only option detected, but ...')

 opts = [
   StrOpt('novncproxy_base_url',
  validate_rule=validate_proxy_url),
   ...
 ]

 I'm not sure I love this yet, but it's worth experimenting with.

>>>
>>> One thing to keep in mind with the move to calling register_opt() at
>>> runtime instead of import time is the service may run for a little while
>>> before it reaches the point in the code where the option validation code is
>>> triggered. So I like the idea, but we may want a shortcut for validation.
>>>
>>> We could add a small app to oslo.config that will load the options in
>>> the same way the conf generator and doc tool will, but then also read the
>>> configuration file and perform the validation.
>>>
>>
>> We implement similar approach in Rubick [1]. Collector script generates
>> configuration schema from code [2], while generator script [3] allows to
>> have different versions of configuration schema:
>>
>> [1] https://github.com/MirantisLabs/rubick/tree/master/rubick/schemas
>> [2]
>> https://github.com/MirantisLabs/rubick/blob/master/rubick/schemas/collector.py#L189
>> [3]
>> https://github.com/MirantisLabs/rubick/blob/master/rubick/schemas/generator.py
>>
>> I think it would be useful to discuss pros and cons of contributing parts
>> of this code to oslo.config.
>>
>
> There's definitely some overlap with the planned work from
> https://etherpad.openstack.org/p/icehouse-oslo-config-import-side-effectsand 
> the existing sample file generator, so it would be good to coordinate.
>
>
Also worth keeping in mind that we now generate documentation from config
files . If
we're going to embed typechecking-like constraints into the options, I'd
like to have a way to transform these constraints into
(non-Python-programmer) human-readable text when generating the config
guide. Since that's tricky to do for arbitrary Python code, we may want to
come up with a scheme that can be used both for validation and that can be
easily transformed into a natural-language description.


Lorin

-- 
Lorin Hochstein
Lead Architect - Cloud Services
Nimbis Services, Inc.
www.nimbisservices.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Configuration validation

[Doug Hellmann]

On Wed, Nov 13, 2013 at 2:19 PM, Oleg Gelbukh  wrote:

> Doug,
>
>
> On Wed, Nov 13, 2013 at 9:49 PM, Doug Hellmann <
> doug.hellm...@dreamhost.com> wrote:
>
>>
>>
>>
>> On Mon, Nov 11, 2013 at 6:08 PM, Mark McLoughlin wrote:
>>
>>>
>>> One thing worth trying would be to encode the validation rules in the
>>> config option declaration.
>>>
>>> Some rules could be straightforward, like:
>>>
>>> opts = [
>>>   StrOpt('foo_url',
>>>  validate_rule=cfg.MatchesRegexp('(git|http)://')),
>>> ]
>>>
>>> but the rule you describe is more complex e.g.
>>>
>>> def validate_proxy_url(conf, group, key, value):
>>> if not conf.vnc_enabled:
>>> return
>>> if conf.ssl_only and value.startswith("http://";):
>>> raise ValueError('ssl_only option detected, but ...')
>>>
>>> opts = [
>>>   StrOpt('novncproxy_base_url',
>>>  validate_rule=validate_proxy_url),
>>>   ...
>>> ]
>>>
>>> I'm not sure I love this yet, but it's worth experimenting with.
>>>
>>
>> One thing to keep in mind with the move to calling register_opt() at
>> runtime instead of import time is the service may run for a little while
>> before it reaches the point in the code where the option validation code is
>> triggered. So I like the idea, but we may want a shortcut for validation.
>>
>> We could add a small app to oslo.config that will load the options in the
>> same way the conf generator and doc tool will, but then also read the
>> configuration file and perform the validation.
>>
>
> We implement similar approach in Rubick [1]. Collector script generates
> configuration schema from code [2], while generator script [3] allows to
> have different versions of configuration schema:
>
> [1] https://github.com/MirantisLabs/rubick/tree/master/rubick/schemas
> [2]
> https://github.com/MirantisLabs/rubick/blob/master/rubick/schemas/collector.py#L189
> [3]
> https://github.com/MirantisLabs/rubick/blob/master/rubick/schemas/generator.py
>
> I think it would be useful to discuss pros and cons of contributing parts
> of this code to oslo.config.
>

There's definitely some overlap with the planned work from
https://etherpad.openstack.org/p/icehouse-oslo-config-import-side-effectsand
the existing sample file generator, so it would be good to coordinate.

Doug


>
> --
> Best regards,
> Oleg Gelbukh
> Mirantis Labs
>
> ___
> 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

Re: [openstack-dev] [Nova] Configuration validation

[Oleg Gelbukh]

Doug,


On Wed, Nov 13, 2013 at 9:49 PM, Doug Hellmann
wrote:

>
>
>
> On Mon, Nov 11, 2013 at 6:08 PM, Mark McLoughlin wrote:
>
>>
>> One thing worth trying would be to encode the validation rules in the
>> config option declaration.
>>
>> Some rules could be straightforward, like:
>>
>> opts = [
>>   StrOpt('foo_url',
>>  validate_rule=cfg.MatchesRegexp('(git|http)://')),
>> ]
>>
>> but the rule you describe is more complex e.g.
>>
>> def validate_proxy_url(conf, group, key, value):
>> if not conf.vnc_enabled:
>> return
>> if conf.ssl_only and value.startswith("http://";):
>> raise ValueError('ssl_only option detected, but ...')
>>
>> opts = [
>>   StrOpt('novncproxy_base_url',
>>  validate_rule=validate_proxy_url),
>>   ...
>> ]
>>
>> I'm not sure I love this yet, but it's worth experimenting with.
>>
>
> One thing to keep in mind with the move to calling register_opt() at
> runtime instead of import time is the service may run for a little while
> before it reaches the point in the code where the option validation code is
> triggered. So I like the idea, but we may want a shortcut for validation.
>
> We could add a small app to oslo.config that will load the options in the
> same way the conf generator and doc tool will, but then also read the
> configuration file and perform the validation.
>

We implement similar approach in Rubick [1]. Collector script generates
configuration schema from code [2], while generator script [3] allows to
have different versions of configuration schema:

[1] https://github.com/MirantisLabs/rubick/tree/master/rubick/schemas
[2]
https://github.com/MirantisLabs/rubick/blob/master/rubick/schemas/collector.py#L189
[3]
https://github.com/MirantisLabs/rubick/blob/master/rubick/schemas/generator.py

I think it would be useful to discuss pros and cons of contributing parts
of this code to oslo.config.

--
Best regards,
Oleg Gelbukh
Mirantis Labs
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Configuration validation

[Doug Hellmann]

On Mon, Nov 11, 2013 at 6:08 PM, Mark McLoughlin  wrote:

> Hi Nikola,
>
> On Mon, 2013-11-11 at 12:44 +0100, Nikola Đipanov 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.
>
> One thing worth trying would be to encode the validation rules in the
> config option declaration.
>
> Some rules could be straightforward, like:
>
> opts = [
>   StrOpt('foo_url',
>  validate_rule=cfg.MatchesRegexp('(git|http)://')),
> ]
>
> but the rule you describe is more complex e.g.
>
> def validate_proxy_url(conf, group, key, value):
> if not conf.vnc_enabled:
> return
> if conf.ssl_only and value.startswith("http://";):
> raise ValueError('ssl_only option detected, but ...')
>
> opts = [
>   StrOpt('novncproxy_base_url',
>  validate_rule=validate_proxy_url),
>   ...
> ]
>
> I'm not sure I love this yet, but it's worth experimenting with.
>

One thing to keep in mind with the move to calling register_opt() at
runtime instead of import time is the service may run for a little while
before it reaches the point in the code where the option validation code is
triggered. So I like the idea, but we may want a shortcut for validation.

We could add a small app to oslo.config that will load the options in the
same way the conf generator and doc tool will, but then also read the
configuration file and perform the validation. Another benefit of a
separate tool is it could produce a full list of warnings and errors,
rather than having the service stop on each bad value.

Doug
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Configuration validation

[Shawn Hartsock]

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" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> 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  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"  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  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

Re: [openstack-dev] [Nova] Configuration validation

[Oleg Gelbukh]

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  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"  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  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

Re: [openstack-dev] [Nova] Configuration validation

[Tracy Jones]

Mark - does Oslo.config already do any duplicate config checking?  If not 
that’s probably a good place for that part

On Nov 12, 2013, at 10:06 AM, Tracy Jones  wrote:

> Thanks folks for the interesting suggestions on this topic!  I’ll b updating 
> the BP this week with this and other info i am gathering. 
> 
> Please let me know if you are interested in being involved in brainstorming 
> on this issue and I will set up an irc meeting to discuss it further
> 
> On Nov 11, 2013, at 3:08 PM, Mark McLoughlin  wrote:
> 
>> Hi Nikola,
>> 
>> On Mon, 2013-11-11 at 12:44 +0100, Nikola Đipanov 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.
>> 
>> One thing worth trying would be to encode the validation rules in the
>> config option declaration.
>> 
>> Some rules could be straightforward, like:
>> 
>> opts = [
>>  StrOpt('foo_url',
>> validate_rule=cfg.MatchesRegexp('(git|http)://')),
>> ]
>> 
>> but the rule you describe is more complex e.g.
>> 
>> def validate_proxy_url(conf, group, key, value):
>>if not conf.vnc_enabled:
>>return
>>if conf.ssl_only and value.startswith("http://";):
>>raise ValueError('ssl_only option detected, but ...')
>> 
>> opts = [
>>  StrOpt('novncproxy_base_url',
>> validate_rule=validate_proxy_url),
>>  ...
>> ]
>> 
>> I'm not sure I love this yet, but it's worth experimenting with.
>> 
>> Mark.
>> 
>> 
>> ___
>> 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

Re: [openstack-dev] [Nova] Configuration validation

[Tracy Jones]

Thanks folks for the interesting suggestions on this topic!  I’ll b updating 
the BP this week with this and other info i am gathering. 

Please let me know if you are interested in being involved in brainstorming on 
this issue and I will set up an irc meeting to discuss it further

On Nov 11, 2013, at 3:08 PM, Mark McLoughlin  wrote:

> Hi Nikola,
> 
> On Mon, 2013-11-11 at 12:44 +0100, Nikola Đipanov 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.
> 
> One thing worth trying would be to encode the validation rules in the
> config option declaration.
> 
> Some rules could be straightforward, like:
> 
> opts = [
>  StrOpt('foo_url',
> validate_rule=cfg.MatchesRegexp('(git|http)://')),
> ]
> 
> but the rule you describe is more complex e.g.
> 
> def validate_proxy_url(conf, group, key, value):
>if not conf.vnc_enabled:
>return
>if conf.ssl_only and value.startswith("http://";):
>raise ValueError('ssl_only option detected, but ...')
> 
> opts = [
>  StrOpt('novncproxy_base_url',
> validate_rule=validate_proxy_url),
>  ...
> ]
> 
> I'm not sure I love this yet, but it's worth experimenting with.
> 
> Mark.
> 
> 
> ___
> 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

Re: [openstack-dev] [Nova] Configuration validation

[John Garbutt]

On 11 November 2013 22:12, Joe Gordon  wrote:
> On Nov 11, 2013 9:53 AM, "Russell Bryant"  wrote:
>> On 11/11/2013 07:38 AM, Nikola Đipanov wrote:
>> > On 11/11/13 12:55, John Garbutt 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.
>> >>
>> >
>> > Thanks John,
>> >
>> > This is a valid point that makes me think that there might be some
>> > upgrade implications to such an approach that we might want to consider
>> > also.
>>
>> I like the idea of doing it during service startup.  I'd like to
>> actually see that it's painfully slow and must be separate before
>> assuming that's the answer.  I really can't image it taking that long.
>> It's not a complex algorithm.  It's some sanity checks on combinations
>> of config values.

+1 this is what I meant really.

>
> ++  to doing it in service startup. Taking a step back I can see a user
> making two types of mistakes:
>
> * Set duplicate or nonexistent options.
> * set an invalid mix of settings.
>
> The first category should be a generic standalone tool, in fact there is a
> proof of concept in nova/tools
> The second category, the type being discussed here, should be done at
> service startup.

I think Joe has it here, there are two categories:
* the quick stuff, that we might be able to encode in the flag definition
* the slow stuff, that we will want as a standalone thing, maybe
something like "nova-manage config-check"

By slow stuff I mean things like ping glance, check its version, ping
vCenter, etc.

John

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Configuration validation

[Mark McLoughlin]

Hi Nikola,

On Mon, 2013-11-11 at 12:44 +0100, Nikola Đipanov 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.

One thing worth trying would be to encode the validation rules in the
config option declaration.

Some rules could be straightforward, like:

opts = [
  StrOpt('foo_url',
 validate_rule=cfg.MatchesRegexp('(git|http)://')),
]

but the rule you describe is more complex e.g.

def validate_proxy_url(conf, group, key, value):
if not conf.vnc_enabled:
return
if conf.ssl_only and value.startswith("http://";):
raise ValueError('ssl_only option detected, but ...')

opts = [
  StrOpt('novncproxy_base_url',
 validate_rule=validate_proxy_url),
  ...
]

I'm not sure I love this yet, but it's worth experimenting with.

Mark.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Configuration validation

[Joe Gordon]

On Nov 11, 2013 9:53 AM, "Russell Bryant"  wrote:
>
> On 11/11/2013 07:38 AM, Nikola Đipanov wrote:
> > On 11/11/13 12:55, John Garbutt 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.
> >>
> >
> > Thanks John,
> >
> > This is a valid point that makes me think that there might be some
> > upgrade implications to such an approach that we might want to consider
> > also.
>
> I like the idea of doing it during service startup.  I'd like to
> actually see that it's painfully slow and must be separate before
> assuming that's the answer.  I really can't image it taking that long.
> It's not a complex algorithm.  It's some sanity checks on combinations
> of config values.
>

++  to doing it in service startup. Taking a step back I can see a user
making two types of mistakes:

* Set duplicate or nonexistent options.
* set an invalid mix of settings.

The first category should be a generic standalone tool, in fact there is a
proof of concept in nova/tools
The second category, the type being discussed here, should be done at
service startup.

> --
> Russell Bryant
>
> ___
> 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

Re: [openstack-dev] [Nova] Configuration validation

[Russell Bryant]

On 11/11/2013 07:38 AM, Nikola Đipanov wrote:
> On 11/11/13 12:55, John Garbutt 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.
>>
> 
> Thanks John,
> 
> This is a valid point that makes me think that there might be some
> upgrade implications to such an approach that we might want to consider
> also.

I like the idea of doing it during service startup.  I'd like to
actually see that it's painfully slow and must be separate before
assuming that's the answer.  I really can't image it taking that long.
It's not a complex algorithm.  It's some sanity checks on combinations
of config values.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Configuration validation

[Tracy Jones]

I had envisioned this as a standalone tool which would be run after an initial 
deployment to validate the config.  I like the idea of hooking it into an 
existing framework - but i agree that we certainly don’t want to slow things 
down.  I wonder if we could use some sort of cookie to track when we validated 
the config and only revalidate when needed.  As i get further in the BP i’ll 
investigate these options.

Tracy

On Nov 11, 2013, at 4:31 AM, Gary Kotton  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"  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  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

Re: [openstack-dev] [Nova] Configuration validation

[Gary Kotton]

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"  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  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

Re: [openstack-dev] [Nova] Configuration validation

[Nikola Đipanov]

On 11/11/13 12:55, John Garbutt 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.
> 

Thanks John,

This is a valid point that makes me think that there might be some
upgrade implications to such an approach that we might want to consider
also.

N.

> John
> 
> On 11 November 2013 11:44, Nikola Đipanov  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

Re: [openstack-dev] [Nova] Configuration validation

[John Garbutt]

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  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