Earlier  
Posted Nick Remark
#openstack-nova - 2017-12-11
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
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: tests: Use correct response type in tests https://review.openstack.org/527182
17:28:30 openstackgerrit Stephen Finucane proposed openstack/nova master: Handle images with no data https://review.openstack.org/526329
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

Earlier   Later