| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-17 | |||
| 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 | |
| 21:16:20 | mriedem | and DELETE /servers/{server_id}/migrations/{migration_id} | |
| 21:16:38 | mriedem | so i'd be fine with adding a new uuid key to the response for os-migrations like we did in 2.41 | |
| 21:16:38 | dansmith | but presumably you're doing /servers/id/migrations/ to get that id | |
| 21:16:52 | mriedem | yeah, presumably | |
| 21:16:54 | mriedem | but... | |
| 21:16:56 | dansmith | well, I already +Wd but lodged by discontent | |
| 21:17:03 | dansmith | *my | |
| 21:17:59 | mriedem | like i said, i'd be fine with just returning a new uuid key if yo'ure worried about breaking people, or making it confusing | |
| 21:18:40 | dansmith | it's just unnecessary breakage which I think we should try to avoid unless we need to | |
| 21:19:15 | openstackgerrit | Eric Fried proposed openstack/nova master: placement: add nested resource providers https://review.openstack.org/377138 | |
| 21:19:15 | openstackgerrit | Eric Fried proposed openstack/nova master: placement: allow filter providers in tree https://review.openstack.org/377215 | |
| 21:19:16 | openstackgerrit | Eric Fried proposed openstack/nova master: placement: adds REST API for nested providers https://review.openstack.org/384807 | |
| 21:19:16 | dansmith | but it's +Wd | |
| 21:19:16 | openstackgerrit | Eric Fried proposed openstack/nova master: placement: update client to set parent provider https://review.openstack.org/385693 | |
| 21:19:17 | openstackgerrit | Eric Fried proposed openstack/nova master: Reformat _get_all_with_shared https://review.openstack.org/512799 | |
| 21:20:08 | mriedem | dansmith: we can amend | |
| 21:20:40 | dansmith | I leave it to you, your highness | |
| 21:20:45 | mriedem | gdi | |
| 21:21:00 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Add pagination and timestamp filtering support for os-migrations API https://review.openstack.org/506030 | |
| 21:22:08 | dansmith | mriedem: I meant leave the decision to you | |
| 21:22:51 | mriedem | yeah i agree with your point, | |
| 21:23:02 | mriedem | i hadn't thought about the lack of GET /os-migratoins/{migration_id} or PUT etc | |
| 21:23:24 | mriedem | i will say, the api-ref docs changes for communicating the id->uuid thing in 2.53 sucked | |
| 21:23:27 | mriedem | so i'd like to avoid that again | |
| 21:23:43 | dansmith | so, another way to decide would be: | |
| 21:23:52 | dansmith | assuming we update the instance-scoped one to be the same, | |
| 21:24:02 | dansmith | would you prefer that one to just be id:$uuid because of the GET/ ? | |
| 21:24:22 | dansmith | if so, then maybe they should both be the same and just put the uuid in the id | |
| 21:24:27 | mriedem | we don't need to return the uuid out of the instance-scoped one, because when we lookup the instance we know which cell the migration record is in | |
| 21:24:29 | dansmith | I don't know tbh | |
| 21:24:44 | mriedem | ^ is why i didn't have to handle returning a uuid for the instance-scoped migrations in 2.53 | |
| 21:24:47 | dansmith | the least amount of total breakage would be just a new uuid field on the global one | |
| 21:26:47 | dansmith | mriedem: well, I have to run off and do something else in a few | |
| 21:26:58 | dansmith | mriedem: so you choose and either proxy my +2 on there or I'll hit it later on when I'm back | |
| 21:27:11 | mriedem | i -1ed, yikun can update tonight, we'll +W tomorrow | |
| 21:27:15 | mriedem | i have to see ms engle soon | |
| 21:27:18 | dansmith | okay | |
| 21:27:21 | dansmith | haha | |
| 21:27:37 | mriedem | laura will dress up of course and i'll look the slob | |
| 21:27:55 | dansmith | same old story every time I leave the house | |