Bug 1761903

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