| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-12 | |||
| 22:03:07 | mriedem | which from the entry point is going to just have api_version set to '3.0' | |
| 22:03:17 | mriedem | so looking at that cinderclient code, it's not going to send the header for 3.0 | |
| 22:03:19 | mriedem | and kaboom | |
| 22:04:08 | mriedem | ildikov: so nova is going to create the client object using this https://github.com/openstack/python-cinderclient/blob/1.10.0/cinderclient/client.py#L711 | |
| 22:04:35 | mriedem | actually, | |
| 22:04:41 | mriedem | nova would be using this https://github.com/openstack/python-cinderclient/blob/1.10.0/cinderclient/client.py#L656 | |
| 22:04:48 | scottda | ildikov: are you using this patch? https://review.openstack.org/#/c/385682/3/nova/volume/cinder.py | |
| 22:04:54 | mriedem | ildikov: note that does " return importutils.import_class(client_path)" | |
| 22:05:01 | mriedem | which doesn't pass in the api_version kwarg | |
| 22:05:15 | mriedem | compared to https://github.com/openstack/python-cinderclient/blob/1.10.0/cinderclient/client.py#L735 which does pass in the api_version kwarg | |
| 22:05:25 | ildikov | scottda: no, I'm depending on another one already | |
| 22:05:27 | mriedem | and ^ is going to be using 3.0 | |
| 22:06:14 | mriedem | anyway that gets us here https://github.com/openstack/python-cinderclient/blob/1.10.0/cinderclient/v3/client.py#L72 | |
| 22:06:23 | mriedem | and then https://github.com/openstack/python-cinderclient/blob/1.10.0/cinderclient/v3/client.py#L112 | |
| 22:06:30 | scottda | ildikov: Does your patch call api_versions.get_highest_version(client) ? | |
| 22:06:56 | mriedem | and then we create a session client here https://github.com/openstack/python-cinderclient/blob/1.10.0/cinderclient/client.py#L607 | |
| 22:06:59 | mriedem | because nova is using a session | |
| 22:07:07 | scottda | ildikov: or point me to your patch(es) | |
| 22:07:16 | mriedem | when session client makes a request it updates the headers here https://github.com/openstack/python-cinderclient/blob/1.10.0/cinderclient/client.py#L109 | |
| 22:07:30 | mriedem | which gets us here https://github.com/openstack/python-cinderclient/blob/1.10.0/cinderclient/api_versions.py#L310 | |
| 22:07:32 | ildikov | scottda: I don't touch the client part in my patch | |
| 22:07:40 | mriedem | and for whatever reason, that only sets the header if the minor version is > 0 | |
| 22:07:44 | mriedem | which seems like a bug | |
| 22:07:56 | ildikov | scottda: so I don't call get_highest_version either | |
| 22:08:31 | scottda | Well, the cinderclient doesn't auto-negotiate to the highest mutually supported version (yet) | |
| 22:08:31 | mriedem | i bet you $100 that that's just a copy/paste from the novaclient update_headers code | |
| 22:08:43 | mriedem | because 2.0 is legacy compute api, 2.1 is new hotness with microversions | |
| 22:08:45 | mriedem | there is no nova 3.0 | |
| 22:08:51 | mriedem | but cinder decided to jump from 2.0 to 3.0 | |
| 22:09:03 | mriedem | scottda: ildikov: so yeah your client is busted | |
| 22:09:19 | mriedem | i'll take the $100 consulting fee in cash or check | |
| 22:10:07 | smcginnis | mriedem: Nova auto-negotiates to the highest? Don't you consider that a risk? | |
| 22:10:19 | mriedem | smcginnis: for the shell, | |
| 22:10:20 | ildikov | mriedem: does that contain the figuring out the endpoint not found issue too? :) | |
| 22:10:21 | mriedem | not the python API | |
| 22:10:26 | mriedem | ildikov: no | |
| 22:10:28 | mriedem | that's ksa | |
| 22:10:32 | smcginnis | mriedem: Still seems like a risk. | |
| 22:10:43 | mriedem | smcginnis: if you're coding to the shell...well... | |
| 22:10:50 | ildikov | mriedem: fair enough | |
| 22:11:00 | mriedem | if you're coding to the shell you deserve to get broken | |
| 22:11:24 | smcginnis | Well, if you're just running commands from the CLI, that seems a risk that suddenly you could get different behavior. | |
| 22:13:38 | ildikov | mriedem: thanks much for the help/explanation of the pain I'm experiencing with testing :) | |
| 22:14:31 | mriedem | ildikov: https://bugs.launchpad.net/python-cinderclient/+bug/1656105 | |
| 22:14:31 | openstack | Launchpad bug 1656105 in python-cinderclient "api_versions.update_headers doesn't set the microversion header if version is 3.0" [Undecided,New] | |
| 22:14:56 | ildikov | mriedem: thanks much! | |
| 22:15:01 | scottda | I'll put up a patch for that ^^^..When I get back from the bus stop. | |
| 22:15:38 | ildikov | scottda: sounds great, thanks | |
| 22:15:39 | mriedem | smcginnis: if you're coding to the shell you can override with --os-compute-api-version | |
| 22:15:43 | mriedem | to opt in or pin the version | |
| 22:15:57 | mriedem | which is exactly what you have to do if you're requesting specific microversions via the python API | |
| 22:15:59 | scottda | ildikov: But why are you using 3.0? You'll still need the version with the new APIs | |
| 22:16:06 | mriedem | microversions in the python API bindings is opt-in, | |
| 22:16:21 | mriedem | the shell is a convenience to use the latest available that the client understands and the server can provide, | |
| 22:16:34 | scottda | BBIAB | |
| 22:16:34 | mriedem | if you're coding to the shell and worry about changes with microversions, then you also have to pin with --os-compute-api-version | |
| 22:17:18 | ildikov | scottda: I'm trying to make Nova pick up the new Cinder APIs and I kind of got stuck with how to do that and hence the questions on every relevant channel | |
| 22:21:17 | openstackgerrit | Dan Smith proposed openstack/nova: Make api_samples tests use simple cell environment https://review.openstack.org/410473 | |
| 22:21:21 | openstackgerrit | Dan Smith proposed openstack/nova: WIP Move instance creation to conductor https://review.openstack.org/319379 | |
| 22:26:43 | cdent | #success edleafe found narrowed down an important bug in gabbi | |
| 22:26:44 | openstackstatus | cdent: Added success to Success page | |
| 22:26:58 | cdent | huh | |
| 22:27:03 | cdent | I've wanted to try that for a while | |
| 22:27:18 | mriedem | found narrowed down? | |
| 22:28:12 | cdent | both | |
| 22:28:35 | cdent | english, when typed, is my 6th language | |
| 22:28:41 | mriedem | heh | |
| 22:31:04 | cdent | sadly, I'm a total fail at solving the bug | |
| 22:31:12 | cdent | I guess that'll have to be tomorrow | |
| 22:32:56 | mriedem | just mark the bug as low-hanging-fruit | |
| 22:33:04 | mriedem | you'll have 10 new contributors lined up to fix it | |
| 22:33:32 | stewie925_ | hello all, hopefully a quick question - I have set up compute on my openstack and then I tried "sudo service nova-api restart" - it returned "nova-api stop/waiting nova-api start/running, process 4383" | |
| 22:33:41 | stewie925_ | is that a confirmation that the nova-api restarted successfully? | |
| 22:33:59 | mriedem | stewie925_: i know you're not new to this channel, but see the channel topic | |
| 22:34:15 | cdent | mriedem: that explains it. I haven't been tagging the bugs. | |
| 22:34:22 | mriedem | how you're deploying it on which distro and what packages etc etc isn't really for this channel | |
| 22:34:31 | stewie925_ | sorry | |
| 22:34:52 | mriedem | np - you'll know it's running if there are logs somewhere | |
| 22:51:15 | openstackgerrit | Davanum Srinivas (dims) proposed openstack/nova: [WIP][py35] Trying to get cinder+rally working https://review.openstack.org/419476 | |
| 22:53:18 | dims | mriedem : i think i am very close to nova boot a vm with this https://review.openstack.org/#/c/419476/ | |
| 22:56:26 | mriedem | [WIP][py35] Trying to get cinder+rally working ? | |
| 22:56:30 | mriedem | wrong title? | |
| 22:57:20 | dims | mriedem : actually i am watching gate-rally-dsvm-py35-cinder-nv over at https://review.openstack.org/#/c/418643/ and debugging nova started from a rally test | |
| 23:07:20 | mriedem | jroll: fyi https://review.openstack.org/#/c/415867/ | |
| 23:07:29 | mriedem | just updated that thing | |
| 23:08:23 | jroll | mriedem: u-c already landed, and I put up https://review.openstack.org/#/c/419630/ this morning | |
| 23:08:42 | mriedem | jroll: https://review.openstack.org/#/c/415867/ is the one that the nova change depends on | |
| 23:08:49 | jroll | yeah, I see that now | |
| 23:08:49 | mriedem | https://review.openstack.org/#/c/364413/ depends on ^ | |
| 23:08:56 | mriedem | and is therefore infinitely more important :) | |
| 23:09:31 | jroll | ya | |
| 23:46:33 | openstackgerrit | Ed Leafe proposed openstack/nova: Remove the Allocation.create() method. https://review.openstack.org/416751 | |
| 23:46:33 | openstackgerrit | Ed Leafe proposed openstack/nova: Add check for invalid allocation amounts https://review.openstack.org/416752 | |
| 23:46:34 | openstackgerrit | Ed Leafe proposed openstack/nova: Fix missing RP generation update https://review.openstack.org/419137 | |
| 23:54:51 | dims | nova.boot_server/attach_volume/detach_volume works! http://logs.openstack.org/43/418643/2/check/gate-rally-dsvm-py35-cinder-nv/c48f74a/rally-plot/results.html.gz#/CinderVolumes.create_and_attach_volume/details | |
| 23:54:56 | dims | (py35) | |
| #openstack-nova - 2017-01-13 | |||
| 02:12:02 | openstackgerrit | Zhenyu Zheng proposed openstack/nova: Don't delete neutron port when attach failed https://review.openstack.org/403568 | |
| 02:24:42 | alex_xu | Kevin_Zheng: just commented on https://review.openstack.org/#/c/419256/7, we still can make it simpler | |
| 02:25:12 | Kevin_Zheng | Thanks | |
| 02:45:35 | openstackgerrit | Jeremy Liu proposed openstack/python-novaclient: Enable coverage report in console output https://review.openstack.org/419723 | |