| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-12-09 | |||
| 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 | |
| 14:29:30 | bauzas | it's just the method which would be returning either False or True | |
| 14:29:34 | sean-k-mooney | so we shoudl be rejecting the request | |
| 14:29:35 | bauzas | but, | |
| 14:29:56 | bauzas | returning False won't do anything AFAICT | |
| 14:30:05 | sean-k-mooney | i mean raise an excption | |
| 14:31:05 | bauzas | sean-k-mooney: k, i see | |
| 14:31:10 | bauzas | sean-k-mooney: that said, just a question | |
| 14:31:14 | bauzas | given two networks | |
| 14:31:33 | bauzas | one having routed segments, and one without any routed segments | |
| 14:32:00 | bauzas | neutron would then create aggregates for the routed segments mapping to net1 | |
| 14:32:11 | bauzas | but wouldn't do anything for net2, right? | |
| 14:32:14 | sean-k-mooney | in that case you want the intersection fo the aggreates | |
| 14:32:23 | sean-k-mooney | yes | |
| 14:32:39 | sean-k-mooney | well not the intersection | |
| 14:32:45 | bauzas | sean-k-mooney: k, so if a user is passing net2 when creating the instance, then we should be accepting it | |
| 14:33:04 | bauzas | and not rejecting the instance creation | |
| 14:33:08 | sean-k-mooney | yes althoughg its unlikely that there will be a mix | |
| 14:33:25 | sean-k-mooney | its vlaid but you tend to have one or the other | |
| 14:33:38 | bauzas | sure, but then the fact that we can't find aggregates for this network doesn't mean it's a blocker | |
| 14:33:50 | sean-k-mooney | correct | |
| 14:33:51 | bauzas | hence us not rejecting it | |
| 14:34:01 | sean-k-mooney | its only an issue if its a routed network | |
| 14:34:01 | bauzas | so we should keep it valid | |
| 14:34:16 | sean-k-mooney | since that should always have an aggreate per segment | |
| 14:34:16 | bauzas | and me just accepting gibi's change to turn it into True | |
| 14:34:34 | sean-k-mooney | you still need to rais in the routed case i think | |
| 14:34:42 | bauzas | sean-k-mooney: sure but the prefilter doesn't know why the aggregate wasn't there | |
| 14:34:55 | bauzas | nova only knows about aggregates | |
| 14:35:05 | sean-k-mooney | but it know if its a routed network request right? | |
| 14:35:11 | bauzas | how? | |