Open Stack

On Thu, Jul 25, 2013 at 10:16:54AM +0930, Christopher Yeoh wrote:
> On Wed, 24 Jul 2013 10:22:32 -0400
> Matthew Treinish <mtreinish at kortar.org> wrote:
> > On Wed, Jul 24, 2013 at 10:48:19PM +0930, Christopher Yeoh wrote:
> > > On Wed, 24 Jul 2013 21:08:03 +0800
> > > Zhu Bo <bozhu at linux.vnet.ibm.com> wrote:
> > > Just to expand on this a bit, from the logs it appears that within
> > > the grenade environment the compute_v3 endpoint can't be found.
> > > However the same test does pass within the normal tempest/devstack
> > > gate environment. We were wondering if there is perhaps some change
> > > that is required to add the compute_v3 endpoint into the grenade
> > > environment (more than the devstack changeset which has already
> > > been merged).
> > 
> > So if I remember correctly grenade uses devstack but has to use a
> > separate configuration because the defaults in devstack-gate are not
> > going to be the same from grizzly to master. (a good example is heat)
> > So you probably will have to make changes to ensure that it's getting
> > enabled when grenade is enabled. You can look at:
> > https://github.com/openstack-infra/devstack-gate/blob/master/devstack-vm-gate.sh
> > to see if there is anything that needs to be added for grenade (I
> > didn't see anything that would break v3 at first glance)
> 
> Thanks we'll double check those as well. Talking to Sean last night it
> looks like it is most likely due to the api-paste file not being
> updated when upgrading nova in grenade. This is deliberately not done
> automatically because of api-paste being considered a config file more
> than "code". But I've heard different opinions as well so if anyone else
> has an opinion please chime in :-) In the meantime we'll add some code
> to manually update the paste file to enable the v3 api when upgrading
> nova in grenade.
> 
> > But, I'm curious is there a reason that the v3 tests in tempest don't
> > api version endpoint discovery? I did this for the glance tests so
> > that if there isn't a v2 endpoint (or a v1 endpoint) then those tests
> > are just skipped. Something similar should easily be implementable
> > for nova's apis. This way nova v3 api isn't are hard requirement for
> > running tempest. (Which I don't think it should be) 
> 
> I don't think we should do auto skipping of tests for v3 (perhaps a
> config file option instead) because of the risk of accidentally
> skipping them. A config option instead perhaps.

That's a fair point, a config option would probably be better than auto
detection. That's the path we've gone down for all of the services in
general so we probably should extend it to api versions as well. We'll just
need to make sure it's easily auto-configurable from devstack.

> 
> I do think v3 testing will need to be come a hard requirement for
> tempest testing pretty soon. Otherwise we are going to regress pretty
> quickly given how easy it is to modify the v2 api without modifying the
> v3 one. 

So I meant in general not for gating. Of course we want this v3 on every gate
run. All I meant by hard requirement is that while there is still a v2 api in
nova we should not force people running tempest to be running v3 on there
instance of nova. A config option or api endpoint version discovery both
accomplish this.

> 
> > I'm also not sure testing the v3 api in grenade is needed at this
> > point since it wasn't in grizzly there really isn't an upgrade path
> > so I don't think that there is any extra value in testing it in
> > grenade too. (I might be wrong about this though)
> 
> I think that's true, but there isn't an easy way to disable tests just
> for grenade is there?
> 

If we add a config option for nova v3 enabled then we can just have grenade set
that to false. Right now you would have to manually exclude them. Also I believe
that grenade only runs the smoke tests. So if you don't tag the v3 tests as smoke
they shouldn't be run by grenade either. (This will only be an issue for the
neutron which is the other use case of the smoke attr)

-Matt Treinish