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