Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-02-17
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.
21:17:25 efried mock;python!=3.xx
21:17:25 efried It might be possible to say
21:17:25 efried But taking that idea...
21:17:25 efried sean-k-mooney: not sure that helps,
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.

Earlier   Later