| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-12-09 | |||
| 11:32:18 | sean-k-mooney | pip was in the lower constraits job | |
| 11:32:56 | stephenfin | virtualenv .venv --python=python3.6; source .venv/bin/activate; pip install 'pip<20.3'; pip install -c lower-constraints.txt -r requirements.txt -r test-requirements.txt . | |
| 11:32:57 | sean-k-mooney | the semantics of the old resovler was if it saw x==1 and later x==2 it ignored the x==2 | |
| 11:33:00 | stephenfin | then do pip freeze | |
| 11:33:11 | stephenfin | you'll get stestr 2.0.0 and hacking 1.1.0 | |
| 11:33:13 | lyarwood | so there was a comment in #openstack-infra that a virtualenv bump introduced pip 20.3 btw | |
| 11:33:38 | stephenfin | (do that on stable/train, obviously) | |
| 11:33:40 | lyarwood | I'm in favor of fixing LC tbh | |
| 11:33:45 | stephenfin | As am I | |
| 11:33:55 | lyarwood | yes it's a change but it's a fix | |
| 11:34:05 | stephenfin | yup | |
| 11:34:09 | lyarwood | and ultimatley you should end up with the same env | |
| 11:35:13 | lyarwood | brb | |
| 11:49:51 | elod | btw, in old stable branches pip should not be version 20.3. so I wonder where this new behavior comes from... :/ | |
| 11:52:36 | elod | (as for example, clearly 'hacking===0.12' (in LC) should have contradicted with hacking>=1.0.0 (in test-req) for ages) | |
| 11:54:36 | elod | and pip 20.3 resolver issue only appeared in grenade jobs, where pip is bootstrapped directly from pypi... hmmm... | |
| 11:55:19 | lyarwood | elod: I think the tox jobs are using it now after a virtualenv change that pulls in pip 20.3 by default | |
| 11:57:16 | elod | lyarwood: oh. interesting. so that's why :/ | |
| 11:58:55 | lyarwood | elod: that said devstack is now failing to deploy swift so maybe we do need https://review.opendev.org/c/openstack/devstack/+/764876 on stable/train | |
| 12:05:08 | elod | lyarwood: it was/is there in since newton :) https://review.opendev.org/c/openstack/devstack/+/269954 | |
| 12:06:03 | elod | so the issue must be something new with swift :/ | |
| 12:14:05 | lyarwood | hmmm I'm not sure that's used with devstack-gate and grenade | |
| 12:14:33 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: libvirt: Skip encryption metadata lookups if secret already exists on host https://review.opendev.org/c/openstack/nova/+/765771 | |
| 12:14:34 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: libvirt: Remove native LUKS compat code https://review.opendev.org/c/openstack/nova/+/766210 | |
| 12:14:41 | lyarwood | either way <= stable/train is borked now | |
| 12:19:51 | lyarwood | ah wait the bandit issue isn't related to pip it's just a broken release for py2 | |
| 12:19:57 | lyarwood | gah this is fun | |
| 12:20:35 | lyarwood | cinder is attempting to install it as well | |
| 12:23:55 | elod | lyarwood: I thought that too first, but as I saw in bandit's setup.cfg it should be OK... or there is something that I'm missing... :X | |
| 12:29:15 | elod | ok, meanwhile I read back the opendev infra and there are some things explained, too (new pip causes the errors; new pip is pulled in by latest virtualenv; latest virtualenv is installed via ensure-tox task -- http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2020-12-08.log.html#t2020-12-08T15:05:27 ) | |
| 12:32:27 | elod | so now I get why there are latest pip on old stable jobs :/ | |
| 12:36:01 | lyarwood | is there a cli for codesearch.opendev.org? | |
| 12:38:07 | elod | lyarwood: yes, beagle | |
| 12:40:31 | lyarwood | elod: ack thanks | |
| 12:41:00 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: [stable-only] Cap bandit while also raising hacking, flake and stestr LCs https://review.opendev.org/c/openstack/nova/+/766171 | |
| 12:41:01 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: libvirt: Remove native LUKS compat code https://review.opendev.org/c/openstack/nova/+/766210 | |
| 12:41:02 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: libvirt: Skip encryption metadata lookups if secret already exists on host https://review.opendev.org/c/openstack/nova/+/765771 | |
| 12:49:23 | lyarwood | hmm that doesn't let you search by branch | |
| 12:51:52 | sean-k-mooney | lyarwood: ya its master only | |
| 12:58:28 | elod | just as hound | |
| 13:00:46 | lyarwood | elod: coming back to the pip issue, do we want to pin the version of virtualenv? | |
| 13:00:51 | lyarwood | elod: on stable that is | |
| 13:01:32 | elod | lyarwood: I don't see yet how we can do it, as it is installed via ensure-tox zuul task | |
| 13:02:12 | sean-k-mooney | elod: virtualenv has a --pip <version> flag | |
| 13:02:26 | sean-k-mooney | so we can add a var to ensure tox for the version | |
| 13:02:56 | sean-k-mooney | leave it undefiend to the current behavior | |
| 13:03:21 | elod | hmmm, that could work | |
| 13:03:23 | sean-k-mooney | and override it in the openstack-tox definion per branch | |
| 13:04:16 | elod | sorry, need to go AFK, bbl | |
| 13:26:06 | elod | ok, I'm back | |
| 13:26:44 | elod | sean-k-mooney: thanks for the idea, I'm looking at if I can make it work | |
| 13:27:32 | lyarwood | I can back the lower-constraints changes out of https://review.opendev.org/c/openstack/nova/+/766171 and just handle the bandit cap there | |
| 13:27:44 | lyarwood | if we can work out a way of capping virtualenv for the tox jobs | |
| 13:30:52 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: [stable-only] Cap bandit to 1.6.2 https://review.opendev.org/c/openstack/nova/+/766171 | |
| 13:37:42 | openstackgerrit | Mamduh proposed openstack/os-vif stable/stein: Refactor code of linux_net to more cleaner and increase performace https://review.opendev.org/c/openstack/os-vif/+/765914 | |
| 13:37:59 | elod | ok, one more addition, the failure came already before the virtualenv 20.2.2 was released... e.g.: https://d13e36a31c498ea1cea8-86befd0513c66a7b4cc05c94ded6a0d4.ssl.cf1.rackcdn.com/periodic-stable/opendev.org/openstack/nova/stable/train/openstack-tox-py27/3fb6863/job-output.txt | |
| 13:38:26 | elod | so there should be something else that pulls in latest pip :'( | |
| 13:39:07 | lyarwood | elod: two different problems | |
| 13:39:19 | lyarwood | elod: the bandit failure is just with the 1.6.3 release | |
| 13:39:39 | elod | lyarwood: yes, sorry, you are right | |
| 13:39:48 | elod | my bad :X | |
| 13:39:54 | lyarwood | elod: and for that I honestly think we need to remove it from the blacklist in requirements | |
| 13:40:21 | lyarwood | elod: otherwise we need to update all projects etc | |
| 13:40:37 | lyarwood | elod: for both stable/train and stable/stein | |
| 13:40:41 | lyarwood | elod: thanks to grenade | |
| 13:41:26 | elod | lyarwood: the problem is that it could cause another repositories to break (according to the comment in blacklist.txt) :/ | |
| 13:41:47 | elod | however it would be the most convenient way | |
| 13:42:26 | elod | otherwise lots of branches in lots of repos needs to be patched separately :/ | |
| 13:42:35 | lyarwood | elod: I'll propose it and post to the ML | |
| 13:42:38 | lyarwood | elod: yeah indeed | |
| 13:43:50 | elod | lyarwood: thanks! let's see what we can do | |
| 13:48:27 | elod | lyarwood: or maybe if bandit 1.6.3 gets yanked... there's already the issue reported: https://github.com/PyCQA/bandit/issues/663 | |
| 13:53:49 | lyarwood | elod: ah cool | |
| 14:19:28 | bauzas | gibi: around ? | |
| 14:19:49 | bauzas | gibi: I was looking at your comment for https://review.opendev.org/c/openstack/nova/+/749068/2/nova/scheduler/request_filter.py@327 | |
| 14:20:31 | bauzas | actually, I think we need to discuss about why we shouldn't be get required_aggregates | |
| 14:20:57 | bauzas | this would be because Neutron doesn't create those aggregates | |
| 14:22:17 | sean-k-mooney | which aggreates | |
| 14:22:28 | bauzas | (well, Nova would create those aggregates as per https://docs.openstack.org/neutron/latest/admin/config-routed-networks.html step 10 ) | |
| 14:22:40 | bauzas | sean-k-mooney: see ^ | |
| 14:22:45 | sean-k-mooney | neutron creates the nova host aggates and addes server too it for the routed networks | |
| 14:23:12 | sean-k-mooney | i.e. neutron calls nova api and relyes on the replciation fo those host aggrates to placment aggreates | |
| 14:23:15 | bauzas | sean-k-mooney: is that nova or neutron ? | |
| 14:23:36 | bauzas | ah-ha ok | |
| 14:24:09 | bauzas | ok, so neutron directly asks the nova api to create the nova aggregates which then automatically creates the placement one | |
| 14:24:11 | bauzas | kk | |
| 14:24:12 | bauzas | so | |
| 14:24:57 | sean-k-mooney | https://github.com/openstack/neutron/blob/master/neutron/services/segments/plugin.py#L272-L289 | |
| 14:25:20 | sean-k-mooney | yes when its creatign the RPs and inventories | |
| 14:25:22 | bauzas | if an operator uses this prefilter for routed networks, then in case we can't find a routed network related aggregate, should we accept to find any host ? | |
| 14:25:47 | sean-k-mooney | no i dont think so | |
| 14:25:58 | bauzas | (I mean , when a user asks for a network when creating the instance) | |
| 14:26:41 | sean-k-mooney | can you rephase do you mean "openstack server create --network " | |
| 14:26:45 | sean-k-mooney | or somethign else | |
| 14:27:55 | bauzas | yup, this | |
| 14:28:04 | sean-k-mooney | if a server has a port that is connected to a routed network we shoudl always reuiqre the aggreate if the prefilter is enabled | |
| 14:28:33 | bauzas | sean-k-mooney: look at https://review.opendev.org/c/openstack/nova/+/749068/2/nova/scheduler/request_filter.py | |
| 14:28:33 | sean-k-mooney | neutron does not allow mixing routed subnets and unrouted subnets in the same network | |
| 14:28:56 | bauzas | sean-k-mooney: and gibi's concern on L327 | |
| 14:29:13 | bauzas | actually, the prefilter won't ask for any aggregate if we can't find them | |