[openstack-dev] [nova] Vendordata improvements

Michael Still mikal at stillhq.com
Wed Jun 22 20:40:33 UTC 2016

On Wed, Jun 22, 2016 at 11:13 PM, Sean Dague <sean at dague.net> wrote:

> On 06/22/2016 09:03 AM, Matt Riedemann wrote:
> > On 6/21/2016 12:53 AM, Michael Still wrote:
> >> So, https://review.openstack.org/#/c/317739 is basically done I think.
> >> I'm after people's thoughts on:
> >>
> >>  - I need to do some more things, as described in the commit message.
> >> Are we ok with them being in later patches to get reviews moving on
> this?
> >
> > I'd be OK with caching/performance improvements in subsequent changes.
> > Docs on this are going to be important to land, so they could be
> > separate but if this is going to get into Newton I'd want the docs to be
> > in Newton also.
> >
> >>
> >>  - I'm unsure what level of tempest testing makes sense here. How much
> >> would you like to see? Do we need to add a vendordata REST service to
> >> devstack? That might be complicated in the amount of time available...
> >
> > I don't think Tempest tests anything from the metadata API service. We
> > only have that running in a handful of jobs (the postgres job is the
> > main one). We could probably write a test though that ssh's into a guest
> > and then pulls the data from the metadata service. I'm not sure what
> > you'd populate into the dynamic vendor data endpoint though, maybe just
> > test data in devstack?
> >
> > I think we should have functional tests in the Nova tree for this at
> > least - how feasible would that be? In other words, would we have to
> > stub out stuff to the point that it would be a useless test in nova's
> > functional test tree?
> I'm pretty sure this could be tested reasonably well in Nova's
> functional test tree. You could have a real md server, and data behind
> it. The only stubbing would be the access path because you'll be hitting
> it from localhost instead of a server ip. But that shouldn't invalidate
> it too substantially.

I'm happy to take a look at functional tests.

What I am getting from this is that it sounds like its worth reviewing the
current patch while I work on functional tests. I can presumably beg nicely
to let a docs review in after the merge deadline if needed, but I'd like to
see the other two patches (including the one I haven't written yet) land
before the deadline.


Rackspace Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160623/1a352148/attachment.html>

More information about the OpenStack-dev mailing list