Open Stack

> -----Original Message-----
> From: Kenichi Oomichi [mailto:oomichi at mxs.nes.nec.co.jp]
> Sent: 18 September 2014 02:44
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [nova] are we going to remove the novaclient
> v3 shell or what?
> 
> 
> > -----Original Message-----
> > From: Matt Riedemann [mailto:mriedem at linux.vnet.ibm.com]
> > Sent: Wednesday, September 17, 2014 11:59 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: [openstack-dev] [nova] are we going to remove the novaclient v3
> shell or what?
> >
> > This has come up a couple of times in IRC now but the people that
> > probably know the answer aren't available.
> >
> > There are python-novaclient patches that are adding new CLIs to the v2
> > (v1_1) and v3 shells, but now that we have the v2.1 API (v2 on v3) why
> > do we still have a v3 shell in the client?  Are there plans to remove that?
> >
> > I don't really care either way, but need to know for code reviews.
> >
> > One example: [1]
> >
> > [1] https://review.openstack.org/#/c/108942/
> 
> Sorry for a little late response,
> I think we don't need new features of v3 into novaclient anymore.
> For example, the v3 part of the above[1] was not necessary because a new
> feature server-group quota is provided as v2 and v2.1, not v3.

That would be true if there was a version of the client that supported v2.1 today, but while the V2.1 API is still presented as V3 and doesn't include the tenant_id - making the V3 client the only simple way to test new V2.1 features in devstack as far as I can see.


How about this as a plan:

1) We add support to the client for "--os-compute-api-version=v2.1"   which maps into the client with the URL set to include v2.1    (this won't be usable until we do step 2)

2) We change the Nova  to present the v2.1 API  as 'http://X.X.X.X:8774/v2.1/<tenant_id>/....
 - At this point we will have a working client for all of the stuff that's been moved back from V3 to V2.1, but will lose access to any V3 stuff not yet moved (which is the opposite of the current state where the v3 client can only be used for things that haven't been refactored to V2.1)

3) We remove V3 from the client.


Until we get 1 & 2 done, to me it still makes sense to allow small changes into the v3 client, so that we keep it usable with the V2.1 API