Open Stack

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 <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/20131111/f76f70c4/attachment.html>