| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-17 | |||
| 19:31:12 | mlavalle | johnthetubaguy, mriedem: any chance you could take a look again on https://review.openstack.org/#/c/375580/? | |
| 19:31:30 | mriedem | 0 chance miguel | |
| 19:31:43 | mriedem | i've had the tab open all morning :) | |
| 19:33:09 | mriedem | should be able to get to it before parent / teacher conferences this afternoon, which are not going to go well | |
| 19:33:13 | mriedem | dansmith: ^ you know why | |
| 19:33:23 | dansmith | lol | |
| 19:33:28 | dansmith | wish I could go | |
| 19:34:32 | mlavalle | mriedem: thanks. good luck with the parent / teacher conference :-) I remember those days | |
| 19:37:18 | efried | sean-k-mooney Took another swing at the bandwidth spec | |
| 19:43:26 | melwitt | mriedem: I wonder if the problem is with cryptsetup and not luks (in your recreate patch). in the bug report lisali mentioned dmcrypt which would imply cryptsetup IIUC | |
| 19:43:41 | melwitt | the hard reboot is only in the luks test | |
| 19:43:41 | sean-k-mooney | efried: cool thanks ill review it with rodolfo tomorow when im back in the office | |
| 19:44:41 | melwitt | mriedem: ah but I see in the bug summary he uses LUKS in the repro steps. nvm | |
| 19:44:43 | mriedem | melwitt: i'll check the logs when they are available to make sure it's not something like reboot failed but the instance wasn't put into ERROR state | |
| 19:47:45 | mriedem | mlavalle: before you scamper off, | |
| 19:47:48 | mriedem | i have a question for you | |
| 19:48:00 | mriedem | https://bugs.launchpad.net/neutron/+bug/1718605 | |
| 19:48:01 | openstack | Launchpad bug 1718605 in neutron "[RFE] Support regex matching when filtering port with IP address" [Wishlist,Triaged] - Assigned to Zhenyu Zheng (zhengzhenyu) | |
| 19:48:14 | mriedem | mlavalle: would ^ be exposed via a new networking API extension? | |
| 19:48:26 | mriedem | i want to assert that it would be | |
| 19:48:35 | mriedem | so nova can tell if neutron is new enough to filter ports by an ip regex | |
| 19:49:47 | mlavalle | mriedem: yes, that makes sense | |
| 19:49:56 | mriedem | ok cool | |
| 19:50:06 | mlavalle | otherwise you don't know who you are talking about | |
| 19:50:14 | mlavalle | talking to^^^^ | |
| 19:50:36 | mlavalle | good thing you left a comment in the RFE | |
| 19:50:42 | mriedem | \o/ | |
| 19:50:54 | mlavalle | I'll make sure we talk about it in the drivers meeting | |
| 19:51:02 | mriedem | ok | |
| 19:59:29 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Improve the performance of filtering instances by IP. https://review.openstack.org/509326 | |
| 20:00:35 | melwitt | mriedem: looks like reboot succeeded, weird http://logs.openstack.org/60/512760/1/check/legacy-tempest-dsvm-neutron-scenario-multinode-lvm-multibackend/b6880f6/logs/screen-n-cpu.txt.gz#_Oct_17_19_08_20_972474 | |
| 20:02:03 | mriedem | are you sure that's the right request? | |
| 20:02:45 | melwitt | not totally sure but it's the only hard reboot in nova-api | |
| 20:03:01 | melwitt | I'm missing how to tie these to specific tests | |
| 20:03:15 | melwitt | not seeing any test ids or names | |
| 20:05:29 | mriedem | i think cbdc84d2-2f34-4868-8058-4c5503f5d815 is the volume id | |
| 20:09:02 | openstackgerrit | Merged openstack/nova stable/newton: Fix --max-count handling for nova-manage cell_v2 map_instances https://review.openstack.org/507557 | |
| 20:09:13 | mriedem | Stderr: u'Device /dev/sda is not a valid LUKS device.\nCommand failed with code 22: Device /dev/sda is not a valid LUKS device.\n' | |
| 20:09:30 | mriedem | oh i guess that's maybe normal | |
| 20:09:32 | mriedem | "/dev/sda is not a valid LUKS device; formatting device for first use" | |
| 20:10:49 | melwitt | I saw those errors too but they're not part of the reboot request (assuming the reboot request I found was the one you added) | |
| 20:10:55 | melwitt | there was only one so I assumed it had to be it | |
| 20:11:00 | mriedem | they aren't, they are part of the attach volume operation | |
| 20:11:19 | mriedem | req-b88ac35a-19f9-4aaa-8186-75028e85d14f is the reboot request | |
| 20:11:40 | melwitt | yeah, that's the one I found | |
| 20:12:18 | mriedem | ew why do we process all of the cpu/numa topology stuff again on reboot? | |
| 20:12:21 | mriedem | is that necessary? | |
| 20:12:58 | melwitt | it might be part of mdbooth's "redo all the things in reboot". I dunno | |
| 20:13:25 | mriedem | it's part of building the guest config after we destroyed it i guess | |
| 20:20:37 | openstackgerrit | Marco Chiappero proposed openstack/nova master: [WIP] Add a communication channel for power management support https://review.openstack.org/512815 | |
| 20:21:52 | mriedem | melwitt: yeah i came to the same conclusion http://logs.openstack.org/60/512760/1/check/legacy-tempest-dsvm-neutron-scenario-multinode-lvm-multibackend/b6880f6/logs/screen-n-cpu.txt.gz#_Oct_17_19_08_20_972474 | |
| 20:24:54 | mriedem | +2 on Kevin_Zheng's spec to proxy IP filtering to neutron as a way forward https://review.openstack.org/#/c/509326/ | |
| 20:25:01 | mriedem | for that perf thing | |
| 20:33:02 | openstackgerrit | Merged openstack/nova stable/newton: neutron: handle binding:profile=None during migration https://review.openstack.org/506323 | |
| 20:39:20 | openstackgerrit | Merged openstack/nova stable/pike: neutron: handle binding:profile=None during migration https://review.openstack.org/506319 | |
| 20:39:26 | openstackgerrit | Merged openstack/nova stable/ocata: neutron: handle binding:profile=None during migration https://review.openstack.org/506320 | |
| 20:39:32 | openstackgerrit | Merged openstack/nova stable/ocata: Provide original fault message when BFV fails https://review.openstack.org/493141 | |
| 20:40:29 | openstackgerrit | melanie witt proposed openstack/nova stable/newton: DNM: Test hard reboot with encrypted volumes attached https://review.openstack.org/512852 | |
| 20:42:39 | openstackgerrit | melanie witt proposed openstack/nova stable/newton: DNM: Test hard reboot with encrypted volumes attached https://review.openstack.org/512852 | |
| 20:54:53 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Add pagination and timestamp filtering support for os-migrations API https://review.openstack.org/506030 | |
| 20:55:11 | mriedem | dansmith: i think this migrations paging spec is ready to go ^ | |
| 20:55:16 | mriedem | has the multi-cell stuff in it | |
| 21:01:47 | openstackgerrit | Merged openstack/nova stable/newton: Provide original fault message when BFV fails https://review.openstack.org/493206 | |
| 21:03:46 | dansmith | mriedem: why descending order? | |
| 21:04:02 | dansmith | I mean, I know we do that in instance list but I don't know why that's good | |
| 21:04:29 | dansmith | it just means that pages are in the reverse order of display in a text screen, which annoys me | |
| 21:04:31 | mriedem | was just being consistent with the instance list | |
| 21:04:32 | mriedem | defaults | |
| 21:05:25 | mriedem | in some earlier patch sets we were talking about what to do and just settled on following what instance list does by default, | |
| 21:05:38 | dansmith | ugh | |
| 21:05:45 | mriedem | and that's only with the new microversion. the spec doesn't call it out, but if the request is < new microversion, we don't enforce any sort key/direction | |
| 21:05:56 | mriedem | so leave it to the natural order that we get today | |
| 21:06:40 | openstackgerrit | Moshe Levi proposed openstack/nova master: Don't overwrite binding-profile https://review.openstack.org/505613 | |
| 21:06:40 | dansmith | mriedem: which file in the api is this? not compute/migration.py right? | |
| 21:06:51 | mriedem | where the default order is? | |
| 21:07:11 | mriedem | https://github.com/openstack/nova/blob/master/nova/api/openstack/common.py#L142 | |
| 21:07:12 | dansmith | er, hmm, maybe it is | |
| 21:07:14 | mriedem | is what i was basing it on | |
| 21:12:32 | dansmith | mriedem: so, this changes id from an int to a uuid string | |
| 21:12:39 | dansmith | mriedem: which seems like unnecessary breakage for people | |
| 21:12:45 | dansmith | is that what we did on services, et al as well? | |
| 21:12:45 | mriedem | same as 2.53 | |
| 21:12:47 | mriedem | yes | |
| 21:12:51 | dansmith | bummer | |
| 21:13:00 | mriedem | it was either that, or return a new uuid key in the response like we did for aggregates | |
| 21:13:21 | mriedem | in 2.41 | |
| 21:13:46 | mriedem | doesn't matter too much to me either way we go, as long as it's one of those two options | |
| 21:13:53 | mriedem | he originally was going to drop the id key and only return a uuid key | |
| 21:13:55 | dansmith | right, returning a new uuid seems better to me, | |
| 21:13:59 | mriedem | which would be a new 3rd way of doing that | |
| 21:14:11 | dansmith | although you do end up with duplicate id fields, which is likely to be confusing if people assume that's an identifier | |
| 21:14:24 | mriedem | i told him i preferred what we did in 2.53 | |
| 21:14:34 | mriedem | which was more consistent with instances just have a single id key | |
| 21:14:54 | mriedem | also because then when you do GET /services/{service_id} do you pass the id or the uuid? | |
| 21:15:00 | dansmith | yeah but that's been a uuid forever (or almost) | |
| 21:15:16 | mriedem | yeah i know - i was really leaning more the direction of the 2.53 changes | |
| 21:15:30 | mriedem | we don't have a GET /os-migrations/{migration_id} so it's less of an issue | |
| 21:16:08 | mriedem | we do, however, have GET /servers/{server_id}/migrations/{migration_id} :) | |
| 21:16:12 | mriedem | which is the int id | |
| 21:16:18 | dansmith | yeah | |