| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-02-17 | |||
| 16:31:45 | sean-k-mooney | stephenfin: i have given up on unit test being enough anythime i go near numa at this point | |
| 16:32:12 | sean-k-mooney | i just always assume a new functional test will be needed | |
| 16:34:21 | stephenfin | agreed | |
| 16:36:56 | efried | sean-k-mooney: Technically the reason to never delete anything without providing a redirect is in case there's a link to the old thing somewhere in the wild. | |
| 16:37:12 | efried | For a template for $release I'm not super worried about it, really. | |
| 16:37:29 | efried | but it's the Right Thing To Do | |
| 16:45:06 | efried | sean-k-mooney: Cross-cell resize needs to not be moved to implemented for Train. So since a respin is needed, might as well add those redirects. | |
| 16:45:51 | efried | For that matter, I'm really not convinced we need those templates in the directories in the first place. Maybe starting in V we can just drop them and just have specs/victoria-template.rst | |
| 16:46:15 | efried | or actually I would prefer specs/victoria/template.rst | |
| 17:02:00 | sean-k-mooney | efried: sorry was in a meeting just saw your comments ya ill make those changes manually so and update the script in a seperate change | |
| 17:02:55 | sean-k-mooney | efried: and ya we dont need the templates in the directories | |
| 17:03:13 | sean-k-mooney | i think they were there to make copying them 1% simpler | |
| 17:23:57 | efried | melwitt: there's no code for nova-audit yet, right? | |
| 17:24:46 | dansmith | gibi: I saw you +2d the bottom patch of the cyborg stuff but there's only +2s three patches up the stack | |
| 17:25:20 | dansmith | gibi: are you comfortable with the whole stack now? I haven't circled back on all the resched stuff yet, but should I? | |
| 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. | |