| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-12-11 | |||
| 16:02:36 | openstackgerrit | Merged openstack/python-novaclient stable/ocata: Move zuulv3 jobs to project repo https://review.openstack.org/522208 | |
| 16:02:36 | openstackgerrit | Merged openstack/python-novaclient stable/pike: Move zuulv3 jobs to project repo https://review.openstack.org/522207 | |
| 16:03:40 | openstackgerrit | Stephen Finucane proposed openstack/nova master: zuul: Move legacy jobs to project https://review.openstack.org/514309 | |
| 16:03:41 | openstackgerrit | Stephen Finucane proposed openstack/nova master: zuul: Remove WSGI functional tests https://review.openstack.org/527140 | |
| 16:07:14 | mriedem | first 3 patches in this series are ready to go i think https://review.openstack.org/#/c/524047/ | |
| 16:20:44 | openstackgerrit | Ed Leafe proposed openstack/nova master: Change compute RPC to use alternates for resize https://review.openstack.org/526436 | |
| 16:25:06 | mriedem | edleafe: i think my only hangup on https://review.openstack.org/#/c/516707/22 is the limits object<>dict conversion | |
| 16:25:15 | mriedem | i think we can hide all of that in the compute rpcapi client code | |
| 16:25:32 | mriedem | for build_and_run_instance, prep_resize, unshelve, etc | |
| 16:25:46 | mriedem | then conductor and compute managers don't need to check that | |
| 16:26:39 | mriedem | if/when we want to send the SchedulerLimits object to compute, we can bump the compute rpc api version and send the object down to compute and the compute will expect the object rather than the dict | |
| 16:26:48 | mriedem | but that's not necessary for this series | |
| 16:27:05 | mriedem | dansmith: ^ agree? or am i missing something? | |
| 16:27:51 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Deprecate file injection https://review.openstack.org/522027 | |
| 16:29:44 | mriedem | sdague: you want to take a pass through https://review.openstack.org/#/c/522027/ ? | |
| 16:32:03 | openstackgerrit | Stephen Finucane proposed openstack/nova master: zuul: Move legacy jobs to project https://review.openstack.org/514309 | |
| 16:32:04 | openstackgerrit | Stephen Finucane proposed openstack/nova master: zuul: Remove WSGI functional tests https://review.openstack.org/527140 | |
| 16:32:27 | dansmith | mriedem: you're proposing making the conductor and scheduler not check service version and do the dict conversion, but instead doing it in compute rpc based on rpc version? | |
| 16:32:32 | dansmith | mriedem: that is fine as long as there isn | |
| 16:32:57 | dansmith | isn't some other semantic detail that needs to happen.. like conductor needing to know if compute is new or old so it can do something different with some other data | |
| 16:33:42 | mriedem | dansmith: the latter yes, like he was doing in an older patch set https://review.openstack.org/#/c/516707/17/nova/compute/rpcapi.py | |
| 16:34:31 | mriedem | at this point i don't think we need to check the compute rpc version to convert to a primitive as we know no computes at this point can handle getting an object | |
| 16:35:23 | dansmith | you mean we always do the dict conversion at the moment, until we have a compute rpc bump to handle it, yes? | |
| 16:35:28 | mriedem | yes | |
| 16:37:32 | dansmith | yep makes sense to me | |
| 16:38:07 | edleafe | mriedem: ok, so just convert in the rpcapi layer, and assume dicts throughout compute | |
| 16:38:25 | mriedem | yup | |
| 16:38:31 | edleafe | ok, gimme a few... | |
| 16:38:35 | mriedem | edleafe: i.e. we shouldn't have any changes to compute in this patch | |
| 16:38:48 | mriedem | nova/compute/manager.py i mean | |
| 16:39:15 | edleafe | mriedem: gotcha. Most of those changes were defensive anyway. You know, "just in case" | |
| 16:40:01 | mriedem | sure, it's just that kind of stuff gets lost in the sands of time and a year from now i'll be looking at the compute code saying, "why is this here? it can never happen..." | |
| 16:40:58 | edleafe | mriedem: it probably was happening in the unit tests | |
| 16:41:26 | edleafe | I probably created SchedulerLimits objects everywhere. I'll make sure those are cleaned up, too | |
| 16:47:56 | cdent | edleafe: you happy to abandon this for later recovery (to get it off the radar), given neither dtantsur nor mriedem seem to want it now? https://review.openstack.org/#/c/494206/ | |
| 16:49:35 | mriedem | i think we need a nova-status check first at least | |
| 16:49:40 | mriedem | and probably backport that nova-status check to pike | |
| 16:50:54 | cdent | gibi: you still thinking about https://review.openstack.org/#/c/501252/ | |
| 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 | mriedem | personally my rear end gets sore hearing about how hard upgrades are and how complicated nova makes everything | |
| 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: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 | |