Bug 1550937

Summary: Pools are not aware of ports subnet
Product: Red Hat OpenStack Reporter: Luis Tomas Bolivar <ltomasbo>
Component: openstack-kuryr-kubernetesAssignee: Luis Tomas Bolivar <ltomasbo>
Status: CLOSED ERRATA QA Contact: Ofer Blaut <oblaut>
Severity: medium Docs Contact:
Priority: medium    
Version: 13.0 (Queens)CC: asegurap, tsedovic, tvignaud
Target Milestone: Upstream M1Keywords: Triaged
Target Release: 14.0 (Rocky)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: openstack-kuryr-kubernetes-0.4.2-0.20180404104924.985c387.el7ost Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-01-11 11:48:58 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Luis Tomas Bolivar 2018-03-02 10:29:57 UTC
Description of problem:

By now there is only one subnet driver (default_subnet) at kuryr-kubernetes that always forces pods to use the same Neutron subnet. However, if a new subnet driver is added allowing pods to be on different networks, the pool drivers may misbehave as the current key used to differentiate between the pools does not include information about the network. This could lead to assigning a wrong port (from the wrong network) to a pod, as they can share the other components of the pool-key: hostIP/hostname, project_id and security groups.

How reproducible:
100%

Steps to Reproduce:
1. Enable pools and create a pod that will populate the pool
2. Change the subnet used at kuryr.conf and restart kuryr controller
3. Create a new pod

Actual results:
Pod is associated with a wrong port, as it belongs to a different network than the one specified at kuryr.conf

Expected results:
New port created in the new subnet, and attached to the pod


Additional info:

Comment 8 errata-xmlrpc 2019-01-11 11:48:58 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2019:0045