Description of problem: Routed network support was originally added upstream in newton (osp 10) https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/neutron-routed-networks.html customer have requestied that this feature be supproted in OSP and work is underway to enable it https://bugzilla.redhat.com/show_bug.cgi?id=1671811 https://bugzilla.redhat.com/show_bug.cgi?id=1721113 the current implemeantion of routed network relys on the use of ip_allocation=defer which requried the ip to be assigned only after a host is selected because the nova schduler and placment is not aware of the subnet affinity between netwrok segment and compute host. work is underway to report netwrok segments to palcement as aggregtes but to complete the integration work is need in nova to be able to include segment infomraiton in the placmenet query such that we can guarentee that the the select host will be conented to the correct neutron segment. this will allow better tacking of ip aviablity and ip locality enabling more accurate scheduling and will enable nova and placmenet to be aware of ip subnet restriction wehn migrating, resizing or unshelveing instances. To achive this nova need to be enhanced to schdule based on routed networks. This is an important usecase for edge deployments. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Some relevant bugs reported while testing routed networks: * Bug 1848481 - [OSP16.1][Routed-provider-networks]Migrate doesn't works if destination option isn't used * Bug 1848482 - [OSP16.1][Routed-provider-networks]Vm creation over ports isn't working properly * Bug 1848483 - [OSP16.1][Routed-provider-networks]Scheduler isn't working properly
The whole series has been merged now in time for the Wallaby release : https://review.opendev.org/q/topic:%2522bp/routed-networks-scheduling%2522+(status:open+OR+status:merged)+project:openstack/nova Moving the BZ to POST accordingly.
*** Bug 1848481 has been marked as a duplicate of this bug. ***
*** Bug 1848482 has been marked as a duplicate of this bug. ***
Hi Eran, As said by https://wimp.usersys.redhat.com/?change_id_input=upstream:I667f56612d7f63834863476694cb1f4c71a58302 you should find the patches in the rhos-17.0 branch (as it was imported directly from upstream when creating the branch from upstream Wallaby) and within any OSP17 puddle, like RHOS-17.0-RHEL-9-20220504.n.1 HTH, -Sylvain
(In reply to Sylvain Bauza from comment #16) > Hi Eran, > > As said by > https://wimp.usersys.redhat.com/?change_id_input=upstream: > I667f56612d7f63834863476694cb1f4c71a58302 you should find the patches in the > rhos-17.0 branch (as it was imported directly from upstream when creating > the branch from upstream Wallaby) and within any OSP17 puddle, like > RHOS-17.0-RHEL-9-20220504.n.1 > > HTH, > -Sylvain so don't we need to change the status of this BZ to On_QA?
(In reply to Eran Kuris from comment #17)> > so don't we need to change the status of this BZ to On_QA? Let me explain the context. This RFE was actually a stop-gap in Nova, closing a miss we had for a while because Routed Networks were a feature supported by Neutron for a couple of releases now without any scheduling support for instances using ports related to them. Accordingly, the implementation was nova-only and was just a scheduler (or rather Placement) filter which was verifying the port (whether it was within a routed network) and then asking to only get hosts related to this network if so. Now, in order to correctly QE it in our product (for 17), we need to provide an environment with multiple routed networks and do both positive and negative tests about creating and moving instances between them in order to verify the expected behaviour. For that reason, our Compute DFG agreed on the fact this RFE needs engagement from the Networking DFG, in particular its QE resources as you probably already have experience and testbeds for routed networks. To summarize and answer your question, we still need to put this BZ ON_QA if we want to have it supported in our OSP17 product. Eran, feel free to reach me in #rhos-compute if you prefer (IRC: sylvainb), we can even arrange some timeslot in our today's office hour in our weekly meeting if you want to engage with the whole team.
(In reply to Sylvain Bauza from comment #18) > (In reply to Eran Kuris from comment #17)> > > so don't we need to change the status of this BZ to On_QA? > > Let me explain the context. This RFE was actually a stop-gap in Nova, > closing a miss we had for a while because Routed Networks were a feature > supported by Neutron for a couple of releases now without any scheduling > support for instances using ports related to them. > Accordingly, the implementation was nova-only and was just a scheduler (or > rather Placement) filter which was verifying the port (whether it was within > a routed network) and then asking to only get hosts related to this network > if so. > > Now, in order to correctly QE it in our product (for 17), we need to provide > an environment with multiple routed networks and do both positive and > negative tests about creating and moving instances between them in order to > verify the expected behaviour. For that reason, our Compute DFG agreed on > the fact this RFE needs engagement from the Networking DFG, in particular > its QE resources as you probably already have experience and testbeds for > routed networks. > > To summarize and answer your question, we still need to put this BZ ON_QA if > we want to have it supported in our OSP17 product. > > Eran, feel free to reach me in #rhos-compute if you prefer (IRC: sylvainb), > we can even arrange some timeslot in our today's office hour in our weekly > meeting if you want to engage with the whole team. thanks for clarifying. We will double-check that we have the capacity to cover that RFE for 17.0 If we have a few more questions I will reach out to you. thanks
This RFE was not marked MVP for OSP 17.0, it will be moved to 17.1. If Tech Preview is required for OSP 17.0 please clone issue and follow procedure, contact the TRAC team.
This will need an enhancement release note to graduate it after tech preview (https://bugzilla.redhat.com/show_bug.cgi?id=2120410).
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 (Release of components for Red Hat OpenStack Platform 17.1 (Wallaby)), 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-2023:4577