| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-02-17 | |||
| 17:25:40 | dansmith | sean-k-mooney: I don't suppose you've poked at the resched/move operations with the latest patch set yet have you? | |
| 17:30:15 | efried | brinzhang: Are you taking over https://review.opendev.org/#/c/623120/ (safer remote console with password authentication)? | |
| 17:30:40 | efried | More specifically the code here https://review.opendev.org/#/c/622336/ (last updated in May) | |
| 17:39:17 | openstackgerrit | Merged openstack/nova-specs master: FUP for NUMA Topology spec https://review.opendev.org/708088 | |
| 17:39:18 | openstackgerrit | Merged openstack/nova-specs master: Fixed minor suggestions https://review.opendev.org/708058 | |
| 17:39:48 | sean-k-mooney | dansmith: no i have not. would you like me to prioitise that | |
| 17:40:22 | dansmith | sean-k-mooney: well, I just figured since you had been doing testing with that stuff it'd be easier sooner than later | |
| 17:41:14 | dansmith | I suppose we can get on with the set without knowing that and fix it later if it doesn't work it's just one of those things where if we're not going to be able to gate on it normally, it could just never get tested/fixed | |
| 17:42:50 | sean-k-mooney | ok well i deploy 2 vms later today and set up the multi node env with the fake driver. | |
| 17:44:51 | dansmith | sean-k-mooney: yeah doing it with the fake driver seems enough to make sure the plumbing is good at least | |
| 17:45:19 | sean-k-mooney | cool ill do that so. | |
| 17:45:22 | dansmith | sean-k-mooney: is it possible that hacking some multi-node-ness on top of the tempest test patch in this set would be worthwhile for gating? | |
| 17:45:53 | sean-k-mooney | well i can just run the standard tempest multinode test with a cyborg flavor | |
| 17:46:15 | sean-k-mooney | i could proably hack up an experimtal job to do that | |
| 17:46:24 | sean-k-mooney | but im not sure if that is worth it or not | |
| 17:46:38 | sean-k-mooney | i guess i could add tests to the plugin | |
| 17:54:17 | efried | lyarwood: virt-bfv-instance-rescue -- what state is this code in? Would you say ready for review? | |
| 17:54:29 | efried | https://review.opendev.org/#/q/topic:bp/virt-bfv-instance-rescue+status:open | |
| 17:59:37 | openstackgerrit | Merged openstack/nova master: Recalculate 'RequestSpec.numa_topology' on resize https://review.opendev.org/662522 | |
| 18:06:23 | efried | kashyap: What's the state of https://review.opendev.org/#/q/topic:bp/allow-secure-boot-for-qemu-kvm-guests+status:open ? | |
| 18:10:55 | gibi | dansmith: I will check the cyborg series tomorrow | |
| 18:30:45 | openstackgerrit | Eric Fried proposed openstack/nova-specs master: Move 'live migration with vpmems' spec https://review.opendev.org/708229 | |
| 18:37:37 | efried | lyarwood: what about this one https://review.opendev.org/#/q/topic:bp/virt-rescue-stable-disk-devices+status:open | |
| 18:41:21 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add test coverage of existing evacuate policies https://review.opendev.org/708230 | |
| 18:41:32 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add test coverage of existing evacuate policies https://review.opendev.org/708230 | |
| 18:41:41 | efried | dustinc: checking in on provider config. | |
| 18:49:53 | melwitt | efried: no code yet | |
| 18:49:59 | efried | thx | |
| 18:59:44 | dansmith | gibi: aight | |
| 19:00:27 | dansmith | efried: do you know enough about zuul things to guess at how difficult it would be to make the cyborg job run with multiple nodes? | |
| 19:00:49 | dansmith | it's been a long time since I've had to look at this stuff, and things have evolved way out of my scope of understanding | |
| 19:01:09 | dansmith | I'm wondering if it's tied to n-cpu enough that just spinning up another node where n-cpu will be installed would be enough to properly configure the cyborg bits? | |
| 19:01:24 | efried | dansmith: Sorry, no, I would probably ask sean-k-mooney's help if I had to go there. | |
| 19:01:56 | dansmith | yeah, trying not to just depend on him for everything :D | |
| 19:02:59 | efried | depending on me for anything might not be the best strategy either. | |
| 19:05:32 | sean-k-mooney | dansmith: making the job multinode is just changing the nodeset and then for the subnode defining sliktly differnet setting in the local.conf | |
| 19:06:30 | sean-k-mooney | dansmith: the cyborg devstack plugin appartly support multi node so when i get it stackted that way locally i can try and push a patch on top of the current cyborg tempest patch that deploys it multi node | |
| 19:07:11 | dansmith | sean-k-mooney: okay I was just about to look through the cyborg devstack stuff before my call just now to see, but good to know | |
| 19:07:51 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add test coverage of existing evacuate policies https://review.opendev.org/708230 | |
| 19:07:52 | sean-k-mooney | we basically just have to disabel the cyborg conductor and api services so that it just install the cyborg agent | |
| 19:08:42 | dansmith | yeah, I figured.. do they not look at n-cpu to determine whether or not they should install the other things? I would think that would be a reasonable sentinel | |
| 19:08:53 | dansmith | unless they really want to be able to be installed in isolation | |
| 19:14:40 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Introduce scope_types in os-evacuate https://review.opendev.org/708235 | |
| 19:20:03 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add new default roles in os-evacuate policies https://review.opendev.org/708237 | |
| 20:52:36 | prometheanfire | reqs update causing issues, might be mock https://review.opendev.org/#/c/707064/ | |
| 20:52:44 | prometheanfire | https://review.opendev.org/#/c/708232 is how octavia solved it | |
| 20:56:37 | sean-k-mooney | prometheanfire: whats the backport candiate lable in gerrit? is that new | |
| 20:57:05 | prometheanfire | ya, first time I've seen it | |
| 20:57:30 | sean-k-mooney | i wonder if that is enforced anyway e.g. will it prevent you form cherry picking or something | |
| 20:57:45 | sean-k-mooney | if not im not sure its very useful | |
| 20:57:49 | sean-k-mooney | although it might be | |
| 21:03:50 | efried | prometheanfire: are we really going to fix this, rather than letting mock fix self and blacklisting 4.0.1? | |
| 21:06:23 | prometheanfire | efried: talking about mock? Is there an upstream bug you are talking about? | |
| 21:07:05 | efried | prometheanfire: Yes. Don't know, would assume if it breaks half a dozen openstack projects that we know of, there will be, or there should be. | |
| 21:07:40 | sean-k-mooney | by the way now that we using python3 only is there any reason to keep using mock the lib | |
| 21:08:29 | sean-k-mooney | we should be able to drop it as a dep an just use the standard lib version now | |
| 21:08:50 | prometheanfire | sean-k-mooney: good point, but that's on the projects themselves :P | |
| 21:09:15 | sean-k-mooney | sure i was asking more for nova | |
| 21:09:16 | efried | sean-k-mooney: I don't even know how we would do that. Can you propose a patch? | |
| 21:09:27 | efried | sean-k-mooney: Like, how would we prevent picking up transitive deps etc? | |
| 21:09:55 | sean-k-mooney | ya so i dont know if we could prevent it | |
| 21:10:04 | sean-k-mooney | but we could just stop listing it in our test requirements | |
| 21:10:24 | sean-k-mooney | eventurally if we got all the project to do that we would stop using it | |
| 21:10:40 | efried | prometheanfire: At a quick look, there are on the order of a hundred uses of mock spec in nova. I would rather find a better way to fix this than hacking dir() into each of them (and it *is* a hack). | |
| 21:11:45 | efried | sean-k-mooney: since it's in the test env, hopefully projects only have it in their test-requirements, which *should* mean the only transitive deps we would have to worry about would be things like oslotest. But... no idea. | |
| 21:12:12 | prometheanfire | efried: if upstream considers it a bug (aka, they plan on fixing something) we can blacklist 4.0.0/4.0.1 | |
| 21:12:24 | prometheanfire | otherwise we are in denial | |
| 21:12:27 | efried | prometheanfire: okay, that was going to be my next question: also broken in 4.0.0? | |
| 21:12:43 | prometheanfire | efried: not sure, this jumped over it, but I imagine it has the same issue | |
| 21:12:51 | sean-k-mooney | ya so os-vif does not use it as far as i know. ill remove it if it does. os-brick might but other then that the only other poject nova really depends on is oslo | |
| 21:13:03 | sean-k-mooney | i guess hacking also | |
| 21:13:55 | efried | prometheanfire: okay, so we need to make sure an upstream issue is opened. They may kill it, but at least the path would be clear. If you don't know of one already, or know of someone who would know, I can go digging... | |
| 21:14:08 | efried | johnsom: ^ ? | |
| 21:14:40 | johnsom | Reading scroll back | |
| 21:14:52 | efried | meanwhile I'll try a local build with mock removed from reqs and see if the venv still installs it... | |
| 21:15:12 | sean-k-mooney | ya so bunch of oslo libs use it | |
| 21:15:14 | sean-k-mooney | http://codesearch.openstack.org/?q=mock&i=nope&files=test-requirements.txt&repos=openstack/oslo-cookiecutter,openstack/oslo-specs,openstack/oslo.cache,openstack/oslo.concurrency,openstack/oslo.config,openstack/oslo.context,openstack/oslo.db,openstack/oslo.i18n,openstack/oslo.limit,openstack/oslo.log,openstack/oslo.messaging,openstack/oslo.middleware,openstack/oslo.policy,openstack/oslo.privsep,opensta | |
| 21:15:16 | sean-k-mooney | ck/oslo.reports,openstack/oslo.rootwrap,openstack/oslo.serialization,openstack/oslo.service,openstack/oslo.tools,openstack/oslo.upgradecheck,openstack/oslo.utils,openstack/oslo.versionedobjects,openstack/oslo.vmware,openstack/oslotest | |
| 21:15:22 | efried | f | |
| 21:15:38 | johnsom | backport candidate is a tool the Octavia cores are using to track patches for backport to stable branches. We added that for our repos. | |
| 21:16:02 | johnsom | Since.... Storyboard...... Enough said | |
| 21:16:29 | efried | johnsom: I was poking you about whether there's a known bug opened against mock for this | |
| 21:16:33 | sean-k-mooney | efried: what we could do is update the requriements file only install mock on python2 | |
| 21:17:17 | johnsom | efried I burned my morning trying to fix a cause and or fix for this. No luck. I'm also not sure this is the same issue your project has with the UC changes. | |
| 21:17:21 | sean-k-mooney | we would then need to update all the projects. | |
| 21:17:25 | efried | sean-k-mooney: not sure that helps, | |
| 21:17:25 | efried | But taking that idea... | |
| 21:17:25 | efried | It might be possible to say | |
| 21:17:25 | efried | mock;python!=3.xx | |
| 21:17:46 | efried | johnsom: yeah, valid point, I didn't actually look. | |
| 21:17:53 | johnsom | We are having the same discussion, whether we should be using this package or reverting to the built-in now. | |
| 21:17:54 | sean-k-mooney | ya so we have a way to match based on python version in the requeriments file already | |
| 21:18:35 | efried | well, fwiw, simply removing mock from test-requirements didn't stop it from installing in the venv. Imagine we would have to yank it from oslotest and oslo.vmware at least. | |
| 21:18:37 | sean-k-mooney | efried: i can ask the requirements folk about it tomorrow seperate form the current disucssion | |
| 21:18:52 | sean-k-mooney | efried: yes we would | |
| 21:19:08 | sean-k-mooney | efried: if you mannually remove it form the enve does it resovel the issue | |
| 21:19:18 | efried | right -- prometheanfire fyi ^ unless you know a way we can explicitly prevent mock from installing, we'll still get it from transitive if we just remove it from our own test-requirements. | |
| 21:19:41 | johnsom | Agreed, it is a total hack, but it was only in "legacy" code for us, so we were like.... good enough, it's going to die anyway. | |
| 21:20:06 | prometheanfire | heh, that's a good point | |
| 21:20:35 | prometheanfire | efried: I don't know of one yet | |