| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-01 | |||
| 18:56:52 | mriedem | it is, it handles a TypeError and ValueError | |
| 18:56:59 | sdague | ok, then we are fine, right? | |
| 18:57:00 | mriedem | but that results in a warning for a successful response | |
| 18:57:04 | mriedem | no | |
| 18:57:20 | sdague | I'm not sure I buy that 204 is here intentionally | |
| 18:57:31 | mriedem | well, | |
| 18:57:38 | mriedem | it doesn't work for me because it started making my tests in https://review.openstack.org/#/c/435563/ fail | |
| 18:57:39 | sdague | the fact that the 204 unit test returned content, makes me again think this is randomly just added | |
| 18:57:44 | mriedem | because i was expecting one warning, not two | |
| 18:57:57 | mriedem | the 204 unit test doesn't return content | |
| 18:57:58 | sdague | mriedem: ... that I don't accept :) | |
| 18:58:04 | sdague | mriedem: it used to | |
| 18:58:28 | sdague | https://review.openstack.org/#/c/434339/3/nova/tests/unit/test_metadata.py@849 that's why that had to be changed | |
| 18:58:32 | mriedem | request_mock.return_value.status_code = response_code | |
| 18:58:45 | mriedem | the actual runtime was changed to not look at status_code | |
| 18:58:58 | mriedem | and so it just looks at request_mock.return_value which is truthy i guess | |
| 18:59:04 | sdague | mriedem: but the unit test simulating the 204 was returning content previously | |
| 18:59:26 | mriedem | yeah true | |
| 18:59:27 | sdague | which makes me really really believe none of this was part of the design, it was just a cantrib | |
| 18:59:33 | sdague | cantrip | |
| 18:59:40 | sdague | so stop reading so much meaning into it :) | |
| 18:59:43 | mriedem | i don't know wtf a cantrip is | |
| 18:59:48 | sdague | magic spell | |
| 19:00:05 | mriedem | duped by those aussies again! | |
| 19:00:12 | sdague | spin around 3 times, I don't get a cold, ok, just do that every day | |
| 19:00:21 | sdague | the talisman will keep the tigers away | |
| 19:00:32 | mriedem | headache is a demon in my head? | |
| 19:00:40 | sdague | yep, pretty much | |
| 19:02:53 | mriedem | so i'm still going to handle the if res and res.text case, because we don't know how people are going to use this, there could be like a first time checkin thing that returns data, and later calls don't, idk | |
| 19:03:02 | mriedem | i suspect that's maybe what mikal was thinking | |
| 19:03:19 | mriedem | that would seem pretty crappy though | |
| 19:03:29 | openstackgerrit | John Garbutt proposed openstack/nova-specs master: Add spec to use Cinder's new attachment APIs https://review.openstack.org/373203 | |
| 19:14:31 | sdague | mriedem: well, we're not handling any of the 30x stuff in real ways either, like processing the redirects | |
| 19:15:15 | sdague | mriedem: honestly, I think this is being overthought, this is a custom service that the op is writing, if they write it to do bad things, .... there is only so much protection here | |
| 19:16:13 | sdague | especially as this is in the metadata code which is ... you know, funky :) | |
| 19:19:13 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Check for 204 case in DynamicVendorData https://review.openstack.org/439785 | |
| 19:22:21 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Only create vendordata_dynamic ksa session if needed https://review.openstack.org/435563 | |
| 19:27:21 | mriedem | Vek: andreykurilin: tdurakov: we should have had a release note with this https://review.openstack.org/#/c/439141/ | |
| 19:27:42 | andreykurilin | oh.. | |
| 19:27:43 | andreykurilin | sure | |
| 19:27:49 | mriedem | we can just roll one on top | |
| 19:28:02 | Gorian | huh. I got pinged here, but it's been unusally active, so I don't have history that far back... | |
| 19:28:24 | mriedem | Gorian: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/ | |
| 19:28:43 | mriedem | ha http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-03-01.log.html#t2017-03-01T06:41:59 | |
| 19:28:49 | mriedem | who are you anyway? | |
| 19:28:53 | mriedem | :) | |
| 19:29:09 | Gorian | awesome, thanks! | |
| 19:29:12 | Gorian | mriedem so mean :( | |
| 19:29:20 | Gorian | lol, idk, just random person sitting in iRC :P | |
| 19:29:25 | mriedem | works for me | |
| 19:30:47 | Gorian | lol. Who are you? | |
| 19:31:50 | mriedem | i am who i am | |
| 19:32:09 | mriedem | this could get really zen like | |
| 19:34:01 | openstackgerrit | Matt Riedemann proposed openstack/python-novaclient master: Remove functional tests for removed commands https://review.openstack.org/439795 | |
| 19:34:05 | mriedem | andreykurilin: here is that test fix ^ | |
| 19:35:06 | FL1SK | Has anyone ever launched an instance from an ISO format that gives you EDD information unavailable from the kernel then eventually just reboots after a minute | |
| 19:35:46 | FL1SK | the same image a standard KVM Host does not show the EDD information unavailable error | |
| 19:36:14 | FL1SK | what would be different with Nova KVM? Does anyone have any clues | |
| 19:55:44 | openstackgerrit | melanie witt proposed openstack/nova-specs master: Proposal to count resources to check quota in API for cells https://review.openstack.org/431749 | |
| 20:01:03 | mriedem | mtreinish: i think i see the issue with that fuzzy ip filtering | |
| 20:02:31 | openstackgerrit | Timofey Durakov proposed openstack/python-novaclient master: Release note for cell_name deprecation https://review.openstack.org/439822 | |
| 20:03:12 | mtreinish | mriedem: cool, so I was right it was a nova bug? | |
| 20:03:21 | openstackgerrit | Timofey Durakov proposed openstack/python-novaclient master: Release note for cell_name deprecation https://review.openstack.org/439822 | |
| 20:04:04 | tdurakov | mriedem: hi, release note for nova-client^ | |
| 20:05:50 | mriedem | tdurakov: thanks, some nits inline | |
| 20:06:23 | mriedem | mtreinish: here https://github.com/openstack/nova/blob/3a2a181796664fea7f6069d49f9cd367b8cff825/nova/compute/api.py#L2496 | |
| 20:06:31 | mriedem | we don't filter the ip in the db query actually | |
| 20:06:58 | mriedem | on the first match, we return https://github.com/openstack/nova/blob/3a2a181796664fea7f6069d49f9cd367b8cff825/nova/compute/api.py#L2508 | |
| 20:07:20 | openstackgerrit | Timofey Durakov proposed openstack/python-novaclient master: Release note for cell_name deprecation https://review.openstack.org/439822 | |
| 20:07:28 | tdurakov | mriedem: done | |
| 20:09:03 | mriedem | http://paste.openstack.org/show/600998/ | |
| 20:09:05 | mriedem | mtreinish: ^ | |
| 20:09:07 | mriedem | that's the bug | |
| 20:10:56 | mriedem | mtreinish: so i'm thinking we build the list of matches, and if more than one, we have to filter the matches from most specific to least specific | |
| 20:11:10 | mtreinish | mriedem: oh, so that's much easier. It would have been a bit more involved if it was in the db layer | |
| 20:11:38 | mriedem | i'm not entirely sure how to do that, first thought is you throw ^<address>$ on there | |
| 20:11:45 | mtreinish | mriedem: yeah that makes sense. Could do a first pass on exact match (without a regex) or would that be too big a departure from the existing api semantics | |
| 20:12:07 | mriedem | that's actually easier | |
| 20:12:21 | mriedem | exact match first, if no hits, use regex | |
| 20:12:31 | mriedem | if multiple hits after regex... shrug? | |
| 20:12:40 | openstackgerrit | Timofey Durakov proposed openstack/python-novaclient master: Release note for cell_name deprecation https://review.openstack.org/439822 | |
| 20:12:51 | mtreinish | mriedem: return all? | |
| 20:13:07 | mtreinish | or return error | |
| 20:13:11 | mriedem | return all | |
| 20:13:14 | mriedem | this is a LIST operation | |
| 20:13:25 | mriedem | let the client sort it out | |
| 20:13:41 | mriedem | let me see how latent this is | |
| 20:15:18 | mriedem | i also wonder if it behaves this way because of https://github.com/openstack/nova/blob/3a2a181796664fea7f6069d49f9cd367b8cff825/nova/compute/api.py#L2362 | |
| 20:15:35 | mriedem | if you filter on fixed_ip it uses an exact regex match | |
| 20:16:09 | mriedem | the tempest test doesn't use that though | |
| 20:18:28 | openstackgerrit | Matt Riedemann proposed openstack/python-novaclient master: Release note for cell_name deprecation https://review.openstack.org/439822 | |
| 20:19:12 | mriedem | mtreinish: i put a -1 on the tempest patch and added nova to the bug report | |
| 20:22:05 | mriedem | mtreinish: so it looks like when vish added that long ago it returned all matches https://github.com/openstack/nova/commit/ae781ee97947c33d6d43e4c21df4f338c875bf1c | |
| 20:22:15 | mriedem | https://github.com/openstack/nova/commit/ae781ee97947c33d6d43e4c21df4f338c875bf1c#diff-516904cc81cade24a9122ecf96707bf0R2029 | |
| 20:22:44 | mriedem | this made it short circuit https://github.com/openstack/nova/commit/8fc7eee58ebd929dda75e467f93c381091da7ace | |
| 20:22:53 | erhudy | does anyone have any top tips for taking a particular SQL query and walking back to the SQLAlchemy statements that are responsible for it? perhaps particular settings in default_log_levels would print something useful out? | |
| 20:23:20 | mriedem | erhudy: i think there are trace options in the oslo.db section | |
| 20:24:25 | mtreinish | mriedem: heh, it always comes back to vish | |
| 20:25:56 | mriedem | heh, it's actually kaufer's regression | |
| 20:26:09 | mriedem | don't worry, i'm harranging him internally | |