| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-02-17 | |||
| 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. | |
| 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 | |
| 21:21:25 | efried | johnsom: I totally wasn't judging you btw :P | |
| 21:21:33 | sean-k-mooney | prometheanfire: have you confirmed if removing the lib version resolved the issue | |
| 21:21:40 | sean-k-mooney | also what is the issue? | |
| 21:22:14 | efried | https://ad2781ccb869c0ef3e99-0fce708e89812c28d28e2be1213f1c9b.ssl.cf5.rackcdn.com/707064/10/check/cross-nova-py36/d1c7fa6/testr_results.html | |
| 21:22:21 | prometheanfire | I don't have a link to an issue yet, this is bigger than I first though that it was | |
| 21:22:52 | johnsom | Yeah, your logs don't look like the same issue we had | |
| 21:23:35 | sean-k-mooney | "ValueError: Sentinels must not start with _" ? | |
| 21:23:40 | johnsom | Ah, ok, some are kind of similar | |
| 21:23:50 | johnsom | Yeah, that appears to be on a "spec" mock | |
| 21:23:52 | prometheanfire | heh https://github.com/testing-cabal/mock/pull/482 | |
| 21:25:29 | sean-k-mooney | right so we could just replace all uses of import mock with import unittest.mock? | |
| 21:25:45 | sean-k-mooney | to get rid of the dep on mock the lib | |
| 21:25:53 | efried | "just" | |
| 21:25:56 | sean-k-mooney | if we wanted too in the futrue and add a hacking check | |
| 21:26:24 | sean-k-mooney | efried: its hopefully 1 sed command but yes | |
| 21:26:29 | sean-k-mooney | it could explode | |
| 21:26:43 | efried | 384 occurrences. | |
| 21:27:38 | prometheanfire | well, there's a way to find out I guess | |
| 21:28:06 | efried | yeah, working on it. | |
| 21:28:57 | sean-k-mooney | there has been a long standing issue in nova where we cant use self.assertRaises as a context manager in a with statement which im pretty sure is caused by mock the lib by the way whic this might also fix | |
| 21:29:07 | efried | prometheanfire, sean-k-mooney, johnsom: so yeah, that fixes it, at least for the one instance I tried. | |
| 21:29:21 | efried | s/^import mock$/from unittest import mock/ | |
| 21:29:25 | prometheanfire | heh | |
| 21:29:36 | johnsom | Hmmm, so tempting..... grin | |
| 21:29:55 | sean-k-mooney | can you do that for all nova and see if the tests still run | |
| 21:29:59 | johnsom | Yeah, I think I will try that too | |
| 21:30:04 | efried | sean-k-mooney: yeah but I'm not gonna run locally. | |