[openstack-dev] [nova] are we going to remove the novaclient v3 shell or what?
Ken'ichi Ohmichi
ken1ohmichi at gmail.com
Thu Sep 18 13:16:24 UTC 2014
2014-09-18 21:31 GMT+09:00 Alex Xu <xuhj at linux.vnet.ibm.com>:
> On 2014年09月18日 18:14, Day, Phil wrote:
>>>
>>> -----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.
v2.1 URL contains tenant_id already, and we can use /v2.1 endpoint like:
$ curl -i 'http://192.168.11.62:8774/v2.1/05d0f72534e449a0a3e70720c5d7c206/servers/detail'
-X GET -H "Accept: applica
tion/json" -H "X-Auth-Project-Id: demo" -H "X-Auth-Token:
f41776736ef34e56a7773e2b2d18d2e3"
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 1749
X-Openstack-Request-Id: req-96768644-be2a-43c4-8757-ad1802736970
Date: Thu, 18 Sep 2014 13:03:54 GMT
{"servers": [{"status": "ACTIVE", "updated": "2014-09-18T11:57:12Z",
"hostId": "8c63113abf9b1e13f1b11dd6a2dbdf511f7aa2199cff31e847582414",
"OS-EXT-SRV-ATTR:host": "oomichi-trusty", "addresses": {"private":
[{"version": 4, "type": "fixed", "addr": "10.0.0.14", "mac_addr":
"fa:16:3e:65:7e:ab"}]}, "links": [{"href":
"http://192.168.11.62:8774/v2.1/05d0f72534e449a0a3e70720c5d7c206/servers/bca4e77b-9763-4cf4-8a84-193df620eeb7",
"rel": "self"}, {"href":
"http://192.168.11.62:8774/05d0f72534e449a0a3e70720c5d7c206/servers/bca4e77b-9763-4cf4-8a84-193df620eeb7",
"rel": "bookmark"}], "key_name": "key-temporary", "image": {"id":
"2ac73d2e-f0d8-4576-a62c-3b53f70d071b", "links": [{"href":
"http://192.168.11.62:8774/05d0f72534e449a0a3e70720c5d7c206/images/2ac73d2e-f0d8-4576-a62c-3b53f70d071b",
"rel": "bookmark"}]}, "os-security-groups:security_groups": [{"name":
"sg-temporary"}], "os-pci:pci_devices": [], "OS-EXT-STS:task_state":
null, "os-extended-availability-zone:availability_zone": "nova",
"OS-EXT-STS:vm_state": "active", "OS-EXT-SRV-ATTR:instance_name":
"instance-0000000e", "OS-SRV-USG:launched_at":
"2014-09-18T11:57:12.000000", "OS-EXT-SRV-ATTR:hypervisor_hostname":
"oomichi-trusty", "flavor": {"id": "84", "links": [{"href":
"http://192.168.11.62:8774/05d0f72534e449a0a3e70720c5d7c206/flavors/84",
"rel": "bookmark"}]}, "id": "bca4e77b-9763-4cf4-8a84-193df620eeb7",
"OS-SRV-USG:terminated_at": null, "user_id":
"30bd25b4555d4664b1069d8d7e682eef", "name": "vm01", "created":
"2014-09-18T11:57:03Z", "tenant_id":
"05d0f72534e449a0a3e70720c5d7c206",
"os-extended-volumes:volumes_attached": [], "accessIPv4": "",
"accessIPv6": "", "OS-EXT-STS:locked_by": null, "progress": 0,
"OS-EXT-STS:power_state": 1, "config_drive": "", "metadata": {}}]}
$
DevStack doesn't register v2.1 endpoint to keytone now, but we can use
it with calling it directly.
It is true that it is difficult to use v2.1 API now and we can check
its behavior via v3 API instead.
>> 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)
v2.1 behavior(API URLs except the endpoint, request/response bodies,
status codes) should
be the same as v2. So if devstack registers v2.1 endpoint as the type
"computev21", we can
use it by specifying "computev21" as --service-type of current nova command.
>> 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)
>
>
> Actually we already can access v2.1 API as
> ''http://X.X.X.X:8774/v2.1/<tenant_id>/..'
> https://github.com/openstack/nova/blob/master/etc/nova/api-paste.ini#L64
Yes, right as I mentioned at the above.
Thanks
Ken'ichi Ohmichi
More information about the OpenStack-dev
mailing list