Re: [openstack-dev] [nova] are we going to remove the novaclient v3 shell or what?
-Original Message- From: Day, Phil [mailto:philip@hp.com] Sent: Friday, September 19, 2014 7:08 PM 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? 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. I posted a patch[1] for registering v2.1 endpoint to keystone, and I confirmed --service-type option of current nova command works for it. Ah - I'd misunderstood where we'd got to with the v2.1 endpoint, thanks for putting me straight. So with this in place then yes I agree we could stop fixing the v3 client. Since its actually broken for even operations like boot do we merge in the changes I pushed this week so it can still do basic functions, or just go straight to removing v3 from the client ? That would depend on what we will implement through v2.1+microversions. If the interface of the microversions is almost the same as v3 API, current v3 code of novaclient would be useful. Otherwise, it would be better to remove the code from novaclient. I posted a mail[1] for the direction of v2.1+microversions, I am glad if we get some consensus/direction. Thanks Ken'ichi Ohmichi --- [1]: http://lists.openstack.org/pipermail/openstack-dev/2014-September/046646.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] are we going to remove the novaclient v3 shell or what?
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. I posted a patch[1] for registering v2.1 endpoint to keystone, and I confirmed --service-type option of current nova command works for it. Ah - I'd misunderstood where we'd got to with the v2.1 endpoint, thanks for putting me straight. So with this in place then yes I agree we could stop fixing the v3 client. Since its actually broken for even operations like boot do we merge in the changes I pushed this week so it can still do basic functions, or just go straight to removing v3 from the client ? Phil ___ 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
Re: [openstack-dev] [nova] are we going to remove the novaclient v3 shell or what?
-Original Message- From: Kenichi Oomichi [mailto:oomi...@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:mrie...@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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] are we going to remove the novaclient v3 shell or what?
On 2014年09月18日 18:14, Day, Phil wrote: -Original Message- From: Kenichi Oomichi [mailto:oomi...@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:mrie...@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) +1 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 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 ___ 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
Re: [openstack-dev] [nova] are we going to remove the novaclient v3 shell or what?
2014-09-18 21:31 GMT+09:00 Alex Xu x...@linux.vnet.ibm.com:
On 2014年09月18日 18:14, Day, Phil wrote:
-Original Message-
From: Kenichi Oomichi [mailto:oomi...@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:mrie...@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-000e, OS-SRV-USG:launched_at:
2014-09-18T11:57:12.00, 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
Re: [openstack-dev] [nova] are we going to remove the novaclient v3 shell or what?
-Original Message-
From: Ken'ichi Ohmichi [mailto:ken1ohmi...@gmail.com]
Sent: Thursday, September 18, 2014 10:16 PM
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?
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-000e, OS-SRV-USG:launched_at:
2014-09-18T11:57:12.00, 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.
I posted a patch[1] for registering v2.1 endpoint to keystone, and I confirmed
--service-type option of current nova command works for it.
$ nova --debug --service-type computev21 list
[..]
REQ: curl -i
'http://192.168.11.62:8774/v2.1/82e5da1a875a4f26a3767fbdf63c0acc/servers/detail'
-X GET -H Accept: application/json -H User-Agent: python-novaclient -H
X-Auth-Project-Id: demo -H X-Auth-Token:
{SHA1}1fc6d248a5e7646a2e72dd89c1dfead0403c9178
INFO (connectionpool:258) Starting new HTTP connection (1): 192.168.11.62
DEBUG (connectionpool:375) Setting read timeout to 600.0
DEBUG (connectionpool:415) GET
/v2.1/82e5da1a875a4f26a3767fbdf63c0acc/servers/detail HTTP/1.1 200 1693
RESP: [200] CaseInsensitiveDict({'date': 'Fri, 19 Sep 2014 02:12:06 GMT',
'content-length': '1693', 'content-type': 'application/json',
'x-openstack-request-id': 'req-7de9edfd-8884-42e5-9a81-2f79f01b59ad'})
RESP BODY: {servers: [{OS-EXT-STS:task_state: null, addresses:
{private: [{version: 4, type: fixed, addr: 10.0.0.2, mac_addr:
fa:16:3e:25:70:9a}]}, links: [{href:
http://192.168.11.62:8774/v2.1/82e5da1a875a4f26a3767fbdf63c0acc/servers/55ee8d4c-bdbe-4fe7-a759-dff7b9184626;,
rel: self}, {href:
http://192.168.11.62:8774/82e5da1a875a4f26a3767fbdf63c0acc/servers/55ee8d4c-bdbe-4fe7-a759-dff7b9184626;,
rel: bookmark}], image: {id: e5468cc9-3e91-4449-8c4f-e4203c71e365,
links: [{href:
Re: [openstack-dev] [nova] are we going to remove the novaclient v3 shell or what?
On Wed, 17 Sep 2014 17:42:30 + Day, Phil philip@hp.com wrote: I think in the hopefully not too distant future we'll be able to make the v1_1 client handle both V2 and V2.1 (who knows. Maybe we can even rename it v2) - and that's what we should do because it will prove if we have full compatibility or not. We should definitely do that cleanup in kilo. Though with microversions hard coding a version number into the directory structure might not make sense. Right now the two things holding that back are the V3 - V2.1 API migration hasn't yet got to the point where the URLs include the tenant ID, and the URL still includes the v3 tag - so the v3 client it the only easy way to exercise the v2.1 API in devstack. For example I needed to do this to test the server group quota changes worked in devstack via V2.1 (I don't trust just getting the unit tests to pass).To do that I had to get boot working and accepting hints, and add support for the limits API. So in the short term it seemed worth pushing those kinds of things back in for now in case they are useful to others. Its not a big overhead to fix the v3 API at the same time (its mostly copied or sub-classed code) until we can add v2.1 support via the v2 client. So the only reason I can think for keeping the v2.1/v3 version of novaclient is if we want to break the python novaclient backwards compatibility to do some cleanups. AFAIK we don't have a policy around python novaclient backwards compatibility and if its ever ok to break it. Chris Phil -Original Message- From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com] Sent: 17 September 2014 15:59 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/ -- Thanks, Matt Riedemann ___ 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
Re: [openstack-dev] [nova] are we going to remove the novaclient v3 shell or what?
-Original Message- From: Matt Riedemann [mailto:mrie...@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. Tempest also should be considered about this topic, and I think the same thing about Tempest also. Thanks Ken'ichi Ohmichi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
