[Yahoo-eng-team] [Bug 2047849] [NEW] [RFE] Start using oslo messaging namespaces
Public bug reported: Currently, neutron does not utilize oslo.messaging namespaces for RPC layers. All namespaces are set to None [1]. This can cause issues as more methods are added and can start clashing with each other. For example, in this patch[2] we wanted to add a get_ports method to the dhcp agent but that method already exists in the metadata agent RPC layer[3] This RFE is to cover the work needed to introduce unique namespaces in the RPC layer. Special consideration has to be taken for upgrade scenarios and SLURP releases. One way how to implement this RFE was discussed in the neutron meeting[4]. That is, 1. Give unique names to all RPC namespaces and test it with grenade jobs to see how it works 2. If that works fine we can go with this approach, if there will be problem with upgrades, we will need to: 3(migration path) 3. The migration path would be to setup two listeners on the server side, one in None namespace and the other with the new namespace name. This would have to happen over 4 releases due to SLURP. Start in release C(Caracal) until release E. See more info here [5] [1] https://opendev.org/openstack/neutron-lib/src/commit/9e3a3a608670d2d7bc0ae98fd39551920e563efe/neutron_lib/constants.py#L566-L581 [2] https://review.opendev.org/c/openstack/neutron/+/903572 [3] https://opendev.org/openstack/neutron/src/commit/de58c1b99523104a471420ef0468147f13c9e98d/neutron/agent/metadata/agent.py#L70 [4] https://meetings.opendev.org/meetings/networking/2024/networking.2024-01-02-14.00.log.html#l-89 [5] https://meetings.opendev.org/meetings/networking/2024/networking.2024-01-02-14.00.log.html#l-130 ** Affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2047849 Title: [RFE] Start using oslo messaging namespaces Status in neutron: New Bug description: Currently, neutron does not utilize oslo.messaging namespaces for RPC layers. All namespaces are set to None [1]. This can cause issues as more methods are added and can start clashing with each other. For example, in this patch[2] we wanted to add a get_ports method to the dhcp agent but that method already exists in the metadata agent RPC layer[3] This RFE is to cover the work needed to introduce unique namespaces in the RPC layer. Special consideration has to be taken for upgrade scenarios and SLURP releases. One way how to implement this RFE was discussed in the neutron meeting[4]. That is, 1. Give unique names to all RPC namespaces and test it with grenade jobs to see how it works 2. If that works fine we can go with this approach, if there will be problem with upgrades, we will need to: 3(migration path) 3. The migration path would be to setup two listeners on the server side, one in None namespace and the other with the new namespace name. This would have to happen over 4 releases due to SLURP. Start in release C(Caracal) until release E. See more info here [5] [1] https://opendev.org/openstack/neutron-lib/src/commit/9e3a3a608670d2d7bc0ae98fd39551920e563efe/neutron_lib/constants.py#L566-L581 [2] https://review.opendev.org/c/openstack/neutron/+/903572 [3] https://opendev.org/openstack/neutron/src/commit/de58c1b99523104a471420ef0468147f13c9e98d/neutron/agent/metadata/agent.py#L70 [4] https://meetings.opendev.org/meetings/networking/2024/networking.2024-01-02-14.00.log.html#l-89 [5] https://meetings.opendev.org/meetings/networking/2024/networking.2024-01-02-14.00.log.html#l-130 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2047849/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 2041861] Re: [ovn] instance in a shared network owned by another project is unreachable via floating IP
Hello: About the bug description. I can't reproduce the issue reported. I've deployed master branch and I can use VLAN, VXLAN or Geneve as tenant network without any issue. The metadata agent creates the corresponding namespaces and provides the metadata to the cloud-init requests without any issue. IMO, but this is just a surmise, the problem could be in the OVN metadata agent you have deployed. Please check the logs and report them here if there is any issue. As Bence commented, if the issue is in the OS cloud-init, then you need further investigation on the OS itself but not related to Neutron. About c#3 comment, I can't neither reproduce that. I've used Geneve and VXLAN networks, shared from a project to another. The VMs created from the project owner and the other one, are both working when connected to a floating IP. The only missing step in c#3 I would comment is the SG rule needed to accept ping packets from an external device (I'm pinging from the host, that is an IP that doesn't belong to the SG remote group): # openstack security group rule create --ethertype IPv4 --protocol icmp --ingress $sg Once added the SG rule, I can ping to the floating IP of the VMs from both projects (owner of the network, project using the shared network). I'll keep this bug as "status=invalid" unless new logs/evidences/reproducers are reported. Regards. ** Changed in: neutron Status: Triaged => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2041861 Title: [ovn] instance in a shared network owned by another project is unreachable via floating IP Status in neutron: Invalid Bug description: In my openstack environment, whenever I create an instance in a shared network owned by another project, the instance becomes unreachable even via floating IP. I'm using the latest kolla ansible with ovn network. I cannot even ssh into the server because it does not run the cloud-inti to set the password (and also because public network unreachable). Spice brings the login prompt but cannot login due to lack of credentials. Any suggestion on how to solve the issue? To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2041861/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 2047049] Re: [UT] OVN fake resources ``create`` method should return instance
Reviewed: https://review.opendev.org/c/openstack/neutron/+/904133 Committed: https://opendev.org/openstack/neutron/commit/e45c403676f30d8fe33977f61c027761427c2d41 Submitter: "Zuul (22348)" Branch:master commit e45c403676f30d8fe33977f61c027761427c2d41 Author: Rodolfo Alonso Hernandez Date: Wed Dec 20 03:40:27 2023 + [UT] OVN fake resources factory method should return instance The OVN fake resources factory method should return an instance of the requested object, not a "type" metaclass object. Closes-Bug: #2047049 Change-Id: I85c613dd628d7d2b67446d999b3e4d7b91eaf9fe ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2047049 Title: [UT] OVN fake resources ``create`` method should return instance Status in neutron: Fix Released Bug description: ``FakeChassis``, ``FakeOVNRouter`` and ``FakeOVNPort`` factory methods should return an instance of the object instead of returning a "type" metaclass object. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2047049/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
