Earlier  
Posted Nick Remark
#openstack-nova - 2019-02-28
22:32:39 mriedem marst: you inspired me https://review.openstack.org/640205
22:32:52 mriedem feedback appreciated on if any of that doesn't work for you
22:38:50 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Move legacy-grenade-dsvm-neutron-multinode-live-migration in-tree https://review.openstack.org/640207
22:45:57 marst mriedem: thank you! I'll try it, but pretty sure it'll work as expected.
22:46:12 mriedem easy +w https://review.openstack.org/#/c/635350/5
22:53:51 tonyb cfriesen: because they have different consumers and a requirements file is different from a constraints file
22:54:21 tonyb cfriesen: I get it's a little duplication but is it really that bad? How would you chnage it?
22:59:28 efried jroll: done, thanks for the squash.
22:59:37 jroll efried: np, thanks for the reviews
23:02:24 efried mriedem: I'm gonna leave stephenfin to that +W. I would nitpick it to death.
23:02:46 mriedem yar matey
23:06:43 openstackgerrit Matt Riedemann proposed openstack/nova stable/ocata: Drop legacy-grenade-dsvm-neutron-multinode-live-migration https://review.openstack.org/640219
23:07:55 melwitt mriedem: want to make sure this is kosher for backporting (ironic driver virt api change) https://review.openstack.org/636699
23:08:31 mriedem well i can certainly look
23:09:03 cfriesen tonyb: I just was surprised because I was upversioning os-traits and didn't realize it needed to be changed in two places.
23:10:06 cfriesen tonyb: seems silly to specify "I need at least version 0.11.0 of os-traits" in two different ways.
23:10:16 melwitt mriedem: I just looked at it. TypeError handled but no warning log for out-of-tree people. I made a comment
23:10:45 melwitt maybe that's overkill for helping out-of-tree. it's mentioned in the reno already
23:10:54 cfriesen tonyb: I can live with it of course. :)
23:12:49 mriedem melwitt: same, plus it's broken
23:13:10 mriedem melwitt: you'd handle the type error and then get another error for an undefined variable
23:13:19 melwitt ohh
23:13:23 melwitt ouch
23:13:35 openstackgerrit Adam Spiers proposed openstack/nova master: Convert driver supported capabilities to compute node provider traits https://review.openstack.org/538498
23:13:37 mriedem well maybe not
23:14:00 mriedem oh i guess we'd just fallback to doing what we did before right?
23:15:38 aspiers mriedem, efried: fixed version is now uploaded https://review.openstack.org/#/c/538498/19..20//COMMIT_MSG
23:15:46 aspiers mriedem, efried: now I will rebase and fix the conflict
23:15:56 mriedem jroll: check my logic in here https://review.openstack.org/#/c/636699/
23:16:59 melwitt seems like it would fall back, given that vm_power_state is passed into the method and the new code just overwrites it if the driver can pull from not cache
23:17:11 mriedem yeah ok
23:17:43 openstackgerrit Adam Spiers proposed openstack/nova master: Convert driver supported capabilities to compute node provider traits https://review.openstack.org/538498
23:18:16 aspiers mriedem, efried: now rebased in patch set 21
23:19:15 efried aspiers: looking. Will try to get it done before I have to leave for class...
23:19:24 aspiers efried: thanks :)
23:20:17 efried else mañana
23:25:49 efried aspiers: Done, that was pretty easy.
23:26:06 efried great work there, Adam, really appreciate you picking that up and sticking with it through all our waffling.
23:26:18 aspiers :)
23:28:49 openstackgerrit Adam Spiers proposed openstack/nova master: Convert driver supported capabilities to compute node provider traits https://review.openstack.org/538498
23:29:14 aspiers efried: nit addressed
23:29:51 openstackgerrit Merged openstack/python-novaclient master: Add support for microversion 2.70 - expose device tags https://review.openstack.org/636779
23:30:12 efried aspiers: +2 again. Assuming others don't notice, we've asserted a design statement there about trait namespacing :)
23:30:20 mriedem melwitt: Kevin_Zheng: artom: dansmith: see if we're in agreement with this summary of the nova meeting discussion about the root volume detach/attach + tag issue http://lists.openstack.org/pipermail/openstack-discuss/2019-February/003367.html
23:30:24 aspiers efried: right ;-)
23:32:28 Kevin_Zheng mriedem: thanks for putting this up, I agree with the current agreement
23:34:50 melwitt mriedem: yeah, matches my understanding. I get that it's not great to go half-baked, but I tend toward it being nicer to make some progress and not have to dump context and start all over again from a mental standpoint. reloading the concept is still necessary but I personally still find it easier when partial support has landed, vs not
23:57:51 mriedem Kevin_Zheng: so i didn't look yet, but you added the code to change the RequestSpec.image when attaching a new root volume?
23:57:56 mriedem so that unshelve will schedule properly?
23:58:22 Kevin_Zheng Yeah I did that and also added a test
23:58:49 mriedem https://review.openstack.org/#/c/623981/21/nova/tests/functional/test_attach_detach_root_volume.py
#openstack-nova - 2019-03-01
00:03:17 dansmith mriedem: melwitt Kevin_Zheng: sent a reply to the list
00:05:39 Kevin_Zheng dansmith: cool, thanks, will check it later
00:06:14 dansmith Kevin_Zheng: no, you will check it now!
00:06:19 dansmith I mean, of course :P
00:07:43 mriedem Kevin_Zheng: i left some comments in that functional test
00:08:19 mriedem Kevin_Zheng: i'd like to see a functional test that exercises that when attaching a new root volume with a new image, we properly update the request spec to ensure we unshelve on a host that only works for that new image
00:09:16 melwitt I definitely sympathize with the idea of not wiping the tag on detach. that was my worry, was someone not realizing that would happen
00:10:29 melwitt I need more brain to think about the rest of it right now
00:12:43 mriedem where the virus lives
00:12:46 mriedem nice
00:17:32 Kevin_Zheng mriedem: I will try to write one today
00:17:53 melwitt a virus? geez kevin
00:19:11 artom mriedem, I don't even know anymore. I saw we revert device tagging altogether, who needs it anyways?
00:19:15 artom *say
00:21:29 Kevin_Zheng melwitt: I will try my best:)
00:21:55 Kevin_Zheng Check the news tomorrow
00:22:02 melwitt :D
00:23:57 mriedem trump told us we can't trust those huawei guys
00:24:03 artom Out of curiosity, do we have a way to scope CONF objects (fixtures?) to a single service in func tests - specifically, I want 2 computes with different vcpu_pin_set (for example)
00:24:28 mriedem dansmith: Kevin_Zheng: replied with some questions for clarification - i know it's getting late so probably have to pick this up tomorrow
00:24:46 mriedem Kevin_Zheng: regardless of the tag decision, my comments on the functional tests are probably enough to keep you busy for a bit
00:25:28 mriedem artom: since CONF is global changes are no
00:25:39 mriedem *chances
00:25:48 melwitt artom: I _think_ you can do that by self.flags(value for compute 1) start compute service 1, self.flags(value for compute 2), start compute service 2
00:25:51 mriedem there is a ConfFixture, and fixtures are context managers,
00:26:02 mriedem so it's possible you could temporarily set config via context
00:26:11 melwitt but maybe it won't stick, if it's going to look at it after startup
00:26:42 mriedem i'm going to be in big trouble for not getting dinner started so i have to run
00:26:47 melwitt yeah, maybe what I said would only work if it's a conf value only considered during init_host
00:27:04 artom Reason I'm asking is - without this, I don't see a way to func test NUMA LM meaningfully
00:27:11 artom melwitt, that'd be enough, I tihnk
00:27:19 dansmith melwitt: only if the values are read and cached at start
00:27:32 dansmith when I wrote the oschown thing, I chased that down
00:27:35 dansmith it's a huge problem
00:27:40 melwitt yeah, I think it won't work if the conf option is read later on
00:27:48 dansmith in that it's completely fundamentally global as heck forever
00:27:53 melwitt but I know I've done something like this before in func test where it was startup only
00:27:57 melwitt haha yeah
00:28:17 dansmith melwitt: right, if it's read at startup and ever again, and it does that before the start returns, then it'll work, but it's fragile
00:28:36 melwitt yeah. definitely not saying it's robust
00:28:40 artom Bleah, vpcu_pin_set is read after startup
00:28:48 melwitt it's the kind of janky thing I do in tests when I find them
00:29:01 melwitt after the desperation sets in
00:30:21 artom dansmith, so, we can follow up on ML, but I think that rules out NUMA LM func testing?
00:30:35 artom I don't see another way to "force a conflict", so to speak
00:31:02 dansmith artom: it means you have to mock something out, which we try to avoid in functional tests, but can't really avoid for hardware things (like virt driver stuff)
00:31:06 dansmith which is why functional is not enough
00:31:37 artom dansmith, mock to different values with 2 compute services running?
00:31:52 dansmith artom: mock somewhere other than config

Earlier   Later