Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-02-12
15:57:33 efried yeah
15:57:56 efried now I'm forced to hand-edit the file after that first time. Or remember to blow it away so it can be regenerated, but then I lose my customizations.
15:58:03 sean-k-mooney you first update teh yaml file then send a sig hup to the compute agent then you remove the hardware
15:58:35 efried as opposed to just... removing the hardware and everything works.
15:59:01 sean-k-mooney that is not really a thing today
15:59:14 efried neither is generic numa affinity
15:59:18 sean-k-mooney i mean i "might" work in some cases
15:59:45 efried Seems like all of this is stuff we're striving for.
16:00:16 efried The whole reason update_provider_tree happens on a loop is so that it can, in the future, automatically adjust the provider tree when stuff like this happens.
16:00:27 sean-k-mooney i think https://etherpad.openstack.org/p/nova-ptg-train everyting from lin 7-30 is very related
16:01:35 efried In fact, I think that it might "just work" after Sylvain's vgpu stuff lands to hot-(un)plug a GPU.
16:01:45 efried if you unplug one that has allocations against it, you can expect problems; but otherwise...
16:02:07 efried and even then, I think we've accounted for that by setting reserved=total.
16:02:37 sean-k-mooney well there were edgecases like this https://review.openstack.org/#/c/626381/
16:03:12 sean-k-mooney if the device you remove had allocation against it we cant remove it form placemetn until those allocation are also removed
16:03:48 sean-k-mooney so the auto updating is greate but there are also dragons lurking there
16:05:09 efried right, like I said, that case is accounted for (at least I definitely remember this code in the xen vgpu patches) where, if a card goes away, but has allocations against it, we set reserved=total so no futher allocations can be made against it, until all the existing allocations go away, at which point we can delete the provider.
16:06:12 sean-k-mooney ya so we have solution for this edgecase and likely other but its a little more involved then you would assume at first glance
16:06:12 openstackgerrit Balazs Gibizer proposed openstack/nova master: Calculate RequestGroup resource provider mapping https://review.openstack.org/616239
16:06:12 openstackgerrit Balazs Gibizer proposed openstack/nova master: Fill the RequestGroup mapping during schedule https://review.openstack.org/619528
16:06:13 openstackgerrit Balazs Gibizer proposed openstack/nova master: Pass resource provider mapping to neutronv2 api https://review.openstack.org/616240
16:06:13 openstackgerrit Balazs Gibizer proposed openstack/nova master: Recalculate request group - RP mapping during re-schedule https://review.openstack.org/619529
16:06:14 openstackgerrit Balazs Gibizer proposed openstack/nova master: Send RP uuid in the port binding https://review.openstack.org/569459
16:06:14 openstackgerrit Balazs Gibizer proposed openstack/nova master: Test boot with more ports with bandwidth request https://review.openstack.org/573317
16:06:15 openstackgerrit Balazs Gibizer proposed openstack/nova master: Remove port allocation during detach https://review.openstack.org/622421
16:06:15 openstackgerrit Balazs Gibizer proposed openstack/nova master: Record requester in the InstancePCIRequest https://review.openstack.org/625310
16:06:16 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add pf_interface_name tag to passthrough_whitelist https://review.openstack.org/625311
16:06:16 openstackgerrit Balazs Gibizer proposed openstack/nova master: Ensure that bandwidth and VF are from the same PF https://review.openstack.org/623543
16:06:17 openstackgerrit Balazs Gibizer proposed openstack/nova master: Support server create with ports having resource request https://review.openstack.org/636360
16:07:09 openstackgerrit Balazs Gibizer proposed openstack/nova master: Support server create with ports having resource request https://review.openstack.org/636360
16:09:39 mriedem lyarwood: mdbooth: +2 on https://review.openstack.org/#/c/551302/
16:09:43 mriedem dansmith: ^
16:11:24 mdbooth mriedem: Thanks!
16:15:00 lyarwood mriedem: cheers
16:16:03 openstackgerrit Balazs Gibizer proposed openstack/nova master: Support server create with ports having resource request https://review.openstack.org/636360
16:17:20 efried aspiers, mriedem: Were either of you planning to resurrect https://review.openstack.org/#/c/538498/ ?
16:17:54 sean-k-mooney mriedem: when you have a sec can you let me know if the responces in https://review.openstack.org/#/c/624842/8//COMMIT_MSG make sense. if you are happy with them i can resping with that info added to the commit and your other comments addressed in an hour or so
16:18:21 mriedem efried: i'm not working on it
16:19:45 stephenfin efried: Comments on https://review.openstack.org/#/c/582392/
16:19:51 efried ...
16:19:52 mriedem sean-k-mooney: i guess....
16:20:05 mriedem setting the vif mac to 0s works depending on the underlying driver
16:20:08 mriedem is the summary i'm getting
16:20:15 sean-k-mooney yes
16:20:19 mriedem i'm not sure how the minimum libvirt version plays into any of that
16:20:37 sean-k-mooney oh with libvirt 3.2 it takes care of all of this
16:20:42 mriedem set_vf_interface_vlan doesn't document it's expected exit codes at all either so i had no idea
16:20:49 sean-k-mooney so we can delete this code
16:23:57 aspiers efried: I started to rebase it and got confused by the conflicts through lack of familiarity with the code, so I installed git-irebase and started to incrementally rebase it one commit at a time, so that the conflicts are smaller and there's more chance of me understanding how to handle them correctly
16:24:15 efried aspiers: tldr you're working on it?
16:24:23 aspiers well, trying ;-)
16:24:39 aspiers I reserve the right to give up through incompetence though
16:25:02 sean-k-mooney mriedem: the behavior chagne 2 weeks ago in https://github.com/openstack/nova/commit/13e283cc82e7cab564850501f9781385fb7b3f68 ill have to respin anyway now.
16:25:12 aspiers efried, mriedem: however I've just taken a brief pause to review the SEV patches my colleague just posted
16:25:54 efried aspiers: Just lmk if you do decide to give up on it, and I'll take over. I want it to get finished one way or another. (No particular hurry, just don't want it stalled indefinitely.)
16:25:57 mriedem sean-k-mooney: behavior change?
16:26:02 aspiers efried: sure thing
16:26:09 efried and thank you.
16:26:13 aspiers yw
16:27:08 mriedem efried: have you taken a gander at https://review.openstack.org/#/c/616239/ yet? that's gibi's "Calculate RequestGroup resource provider mapping" change which i figure you're the best person to review that
16:27:12 sean-k-mooney mriedem: actully no never mind the exit_code = [0, 2, 254] is now donw internally in another fucntion instead of pased in
16:27:38 sean-k-mooney never mind i dont need to respin due to a behavior change but i will to adress you comments
16:27:51 efried mriedem: It's on my list, but I admit my list is currently more of a... cloud. I can bump it.
16:28:02 mriedem same
16:28:47 dansmith mriedem: lyarwood mdbooth: Tell me why we have to do the partial() and I'll remove my -1, otherwise that seems nuts to me
16:29:12 mriedem b/c the virt driver calls the post method
16:29:16 mriedem and doesn't have the source bdms
16:29:23 mriedem it's a callback
16:30:10 dansmith mriedem: right, but we can modify that interface
16:30:22 mriedem and update all virt drivers to lookup and pass the bdms?
16:30:54 dansmith eff yeah, otherwise you're just stacking partial()s on top of each other until the end of time
16:30:58 openstackgerrit Eric Fried proposed openstack/nova master: Use tox 3.1.1 fixes https://review.openstack.org/582392
16:30:58 openstackgerrit Eric Fried proposed openstack/nova master: tox: Don't write byte code (maybe) https://review.openstack.org/636378
16:31:07 dansmith and nobody actually knows how/where all those things come from
16:31:12 mriedem dansmith: actually it's already too late
16:31:17 mriedem once the virt driver calls the post method,
16:31:24 mriedem the bdms have been modified via pre_live_migration on the dest
16:31:31 mriedem which is why he's looking them up before call pre_live_migration
16:31:46 dansmith mriedem: too late for stacking the partials you mean right?
16:31:47 efried stephenfin: fixed, good suggestion.
16:32:24 mriedem too late for the virt driver on the source host to lookup the bdms to pass to _post_live_migration because that happens *after* pre_live_migration has modified the bdms
16:32:34 dansmith mriedem: all I'm saying is pass these things to the method you want to have pass them back, instead of wrapping
16:32:40 dansmith mriedem: I'm not saying have the virt driver look them up
16:32:52 efried mriedem: don't forget to send a courtesy note to the ML so OOT drivers aren't blindsided :*
16:32:53 mriedem so pass through the driver.live_migration method
16:33:08 dansmith mriedem: right
16:33:54 mriedem i don't feel strongly either way, but this has to be backported and as noted that interface change will require all drivers to be updated lockstep
16:34:12 mriedem so if we were going to change the interface, i'd do it in a follow up which isn't backported
16:34:22 dansmith mriedem: well, then backport this and fix it after if you want
16:34:33 lyarwood ack, I can take that if mdbooth can't
16:34:44 dansmith I would also define the partial right before you make the call to the driver,
16:34:53 mdbooth dansmith: TBH, I actually like the partial better, and in this context I'd partial all the things.
16:35:00 dansmith mdbooth: I have no doubt that you do
16:35:12 mriedem rollback still has to be fixed as well
16:35:13 mriedem for the same issue
16:35:29 mdbooth dansmith: The reason is that is simplifies the interface between compute and the driver by removing arguments which are purely local the the calling method.
16:35:45 mdbooth So the callback method only passes relevant data, and everything else remains local.
16:36:00 mdbooth However, that isn't why I used one here. Here's it's just so I didn't have to change the interface.
16:36:11 dansmith mdbooth: yeah, I get the obvious argument for it, I just think it hurts readability and understandability if you're just focused on that one method
16:36:44 dansmith it'd be slightly better if you define the partial and all the extra things you're going to pass down right before you make the call to the driver,

Earlier   Later