| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-12-11 | |||
| 16:51:45 | dtantsur | mriedem, dansmith, sorry, could you please check https://review.openstack.org/#/c/508555/ ? we're waiting for it to unblock our CI | |
| 16:51:49 | dtantsur | others too ^^' | |
| 16:52:02 | edleafe | cdent: I'm still not clear why it should stay | |
| 16:52:26 | edleafe | cdent: By Queens, the flavors must all be migrated | |
| 16:52:58 | cdent | edleafe: I have no skin, I was fine with it moving, so it is mriedem and dtantsur you could be talking to | |
| 16:53:37 | edleafe | ok | |
| 16:53:39 | mriedem | i'm personally a bit uncomfortable at the moment with operators adoption / understanding of the new thing yet | |
| 16:53:53 | mriedem | especially if we don't have traits via flavors yet | |
| 16:53:59 | mriedem | to replace the capabilities filter | |
| 16:54:05 | gibi | cdent: soon we will have n-rp that also makes it possible to use CUSTOM resource so I think I will abandon those patches soon | |
| 16:54:50 | mriedem | i'm thinking of https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/ironic-driver-traits.html | |
| 16:55:04 | cdent | gibi: cool, just checking, i’m passing through the list I created on friday | |
| 16:55:41 | gibi | cdent: thanks for reminding me about this patch :) | |
| 16:56:31 | edleafe | mriedem: I get that that spec isn't completed. I'm just not clear how that impacts resources in extra_specs | |
| 16:58:13 | jaypipes | dtantsur: done | |
| 16:58:53 | jroll | edleafe: seems like the suggestion is to give operators more time to move to resource classes | |
| 16:59:03 | mriedem | holy crap | |
| 16:59:07 | jroll | I'm not sure the traits thing is relevant as people can still run the compute capabilities filter | |
| 16:59:16 | jroll | :P | |
| 16:59:49 | mriedem | maybe traits isn't relevant, i just don't have a good feeling about how much operators understand what's being asked of them to upgrade | |
| 17:00:10 | mriedem | and like i said, we should at least have a nova-status check for this to say, 'yup, you're good to upgrade' | |
| 17:00:45 | edleafe | jroll: hey stranger! | |
| 17:00:51 | jroll | hi :) | |
| 17:01:15 | edleafe | ok, if the idea is to not make resource classes required in queens, that's fine | |
| 17:01:18 | jroll | mriedem: I don't have enough recent context to agree, but totally see where you and dmitry are coming from | |
| 17:01:30 | edleafe | I hadn't heard about that change | |
| 17:01:51 | mriedem | edleafe: that's not what i'm saying | |
| 17:02:10 | mriedem | but before we make something required, i think we need a bit of work to help people know when their migration is done | |
| 17:02:21 | mriedem | like we do, for example, with schema blocker migrations at times | |
| 17:03:21 | edleafe | mriedem: that's fair. IMO, we should add that, but keeping the pike migration code around doesn't feel like it would help that | |
| 17:03:21 | mriedem | personally my rear end gets sore hearing about how hard upgrades are and how complicated nova makes everything | |
| 17:03:56 | mriedem | edleafe: keeping it around helps motivate writing the nova-status change :) | |
| 17:04:03 | mriedem | removing code is the carrot | |
| 17:05:01 | mriedem | dtantsur: jaypipes: if https://review.openstack.org/#/c/508555/ regresses something, does it only impact the ironic driver? | |
| 17:05:13 | mriedem | doesn't look like it https://review.openstack.org/#/c/508555/6/nova/compute/resource_tracker.py | |
| 17:05:35 | dtantsur | it's hard to tell for me, unfortunately | |
| 17:05:56 | dansmith | mriedem: I'm about to comment on the error message in that way | |
| 17:06:45 | jroll | seems like it's unlikely to affect non-ironic, but it could, in the drivers where it makes sense for host != nodename | |
| 17:07:04 | jroll | that's normal for vmware or something right? | |
| 17:07:13 | jaypipes | jroll: I don't think so any more... | |
| 17:07:19 | mriedem | dansmith: yeah just did | |
| 17:07:22 | mriedem | about the rebalance thing? | |
| 17:07:32 | dansmith | mriedem: yeah | |
| 17:08:02 | mriedem | because people eff up their compute nodes tables and service host records i'm sure | |
| 17:08:15 | jroll | jaypipes: ah, cool | |
| 17:09:15 | dansmith | or they change a hypervisor's name, | |
| 17:09:21 | dansmith | or have an accidental name overlap | |
| 17:09:37 | dansmith | or they point the compute service at the wrong hypervisor | |
| 17:09:49 | mriedem | or it's tuesday? | |
| 17:09:54 | dtantsur | wut? :D | |
| 17:10:05 | dansmith | since our UC is over (host,hypervisor_hostname) each hypervisor_hostname could be the same today technically | |
| 17:10:08 | mriedem | dtantsur: tuesday is random break your resource tracker day | |
| 17:10:16 | dtantsur | any suggestions for a flag name? allow_nodes_migration (hmm, "migrate" may be confusing) | |
| 17:10:21 | dtantsur | mriedem: good to know :) | |
| 17:11:06 | sean-k-mooney | dansmith: the UC is over (host,hypervisor_hostname) today for ironic correct? | |
| 17:13:13 | dansmith | sean-k-mooney: for everything | |
| 17:14:08 | sean-k-mooney | dansmith: well what i mean is the resone the unique constratint is (host,hypervisor_hostname) instaed of just (host) or (hypervisor_hostname) is because of how we track ironic nodes in the nova db | |
| 17:14:39 | dansmith | but we track nodes for every virt driver as well | |
| 17:14:42 | dansmith | they're just all 1:1 | |
| 17:16:13 | dtantsur | so, any ideas better than Driver.allow_nodes_migration? | |
| 17:17:08 | jroll | dtantsur: what about just if_driver_is_ironic() ? | |
| 17:17:24 | jroll | or however you might actually write that | |
| 17:17:29 | dtantsur | if driver.has_bears() :) | |
| 17:17:31 | dansmith | are you talking about checking a flag on the driver in RT? | |
| 17:17:37 | dtantsur | yep | |
| 17:18:50 | dansmith | I don't love that, but I'd vote for the generic-er flag name, with a comment above of "ironic strikes again" or something | |
| 17:19:05 | dtantsur | I was thinking about ^^^ as well | |
| 17:20:55 | mriedem | driver.rebalances_nodes? | |
| 17:21:08 | mriedem | that's specific to the problem here | |
| 17:21:12 | dtantsur | sounds good | |
| 17:21:14 | mriedem | doesn't talk about migration | |
| 17:21:24 | mriedem | and is obviously false for everything else | |
| 17:21:47 | dansmith | let's hope no other drivers try to use this to implement HA | |
| 17:22:17 | dtantsur | people never take a random feature and try to misuse it, right? | |
| 17:22:35 | dansmith | never | |
| 17:28:30 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Handle images with no data https://review.openstack.org/526329 | |
| 17:28:30 | openstackgerrit | Stephen Finucane proposed openstack/nova master: tests: Use correct response type in tests https://review.openstack.org/527182 | |
| 17:28:40 | sean-k-mooney | dtantsur: i mean if i can observer a specific semantic behavior or side effect of a pulic api/config option that is not documented anyware it was totally part of the public api contract that i can build my feature on correct? | |
| 17:29:20 | dtantsur | good plan, go for it | |
| 17:29:58 | openstackgerrit | Chris Dent proposed openstack/nova master: placement: skip authentication on root URI https://review.openstack.org/522002 | |
| 17:33:03 | stephenfin | mriedem: I'd to rework that patch. Turns out the glance API docs are wrong. Would appreciate a second look at it https://review.openstack.org/526329 | |
| 17:33:41 | mriedem | cdent: https://review.openstack.org/#/c/521640/ | |
| 17:34:11 | cdent | ack | |
| 17:38:46 | sean-k-mooney | stephenfin: you have a seperate bug open for the itorator to list conversion on line 179 of glance.py correct? | |
| 17:43:11 | openstackgerrit | Merged openstack/nova stable/pike: placement: avoid returning duplicated alloc_reqs when no sharing rp https://review.openstack.org/508885 | |
| 17:55:58 | cdent | mriedem: is your opinion we should go ahead with the want_version thing inside the serialization loop for the last-modified stuff. I read your first comment as maybe we should consider, and then as you progressed is became more certain. So I’ll take it as “doooo iiiiit” unless you feel like saying something to the contrary | |
| 18:28:44 | mriedem | cdent: i think we should probably do that for at least the requests that can generate a lot of results in a big cloud | |
| 18:28:53 | mriedem | so GET /traits and GET /resource_providers | |
| 18:29:09 | mriedem | GET /traits will always be at least reasonable size because of the library | |
| 18:29:26 | cdent | mriedem: i’ve done it for allocations, traits, resource classes, resource providers, but not inventories | |
| 18:29:32 | dtantsur | mriedem: re that patch: should I keep the functional tests changes, given that the behavior is no longer the default? | |
| 18:30:30 | mriedem | cdent: allocations are per provider or consumer right? so i didn't think that one was as big a deal | |
| 18:30:38 | mriedem | but if you're going to establish a pattern... | |
| 18:30:52 | mriedem | i just tend to think of allocations like inventories - they are mapped to a single provider | |
| 18:31:00 | cdent | mriedem: I was imagining something other than libvirt, where maybe the compute-mode is ginormous | |
| 18:31:05 | mriedem | dtantsur: i probably wouldn't | |
| 18:31:08 | cdent | or a shared disk | |
| 18:31:26 | dtantsur | k | |
| 18:31:36 | mriedem | cdent: or vmware :) | |
| 18:31:42 | mriedem | *vcenter | |