Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1949762

Summary: [RFE] Implement "Boot a VM with an unaddressed port" blueprint
Product: Red Hat OpenStack Reporter: Michele Valsecchi <mvalsecc>
Component: openstack-novaAssignee: Sylvain Bauza <sbauza>
Status: CLOSED DEFERRED QA Contact: OSP DFG:Compute <osp-dfg-compute>
Severity: low Docs Contact:
Priority: low    
Version: 17.0 (Wallaby)CC: alifshit, ccamposr, dasmith, egallen, eglynn, jhakimra, kchamart, knoha, mariel, ralonsoh, sbauza, sgordon, stephenfin, vromanso
Target Milestone: ---Keywords: FutureFeature, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 2081254 (view as bug list) Environment:
Last Closed: 2023-04-14 20:18:57 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: Yoga
Embargoed:
Bug Depends On:    
Bug Blocks: 1266593, 2081254    

Description Michele Valsecchi 2021-04-15 02:41:33 UTC
Description of problem:

Instances are unable to be created using a port without a fixed-ip at the moment being (e.g. instances running NFV application using IP not directly managed by RHOSP).

from [1]
~~~
by design nova has required all ports to have ip adress before the vm is schdulerd until very recently.
in fact supporting addressless ports was rejected severall times.
~~~

A patch for said use case[2] was rejected in the past. 
However we can still see another blueprint[3] being "Pending Approval".

I can see security concern mentioned in private comments on BZ1669350 
and from [4] as well
~~~
because of the absence of strong firewalling, the network to which
the port is attached is insecure, as the attached VM can spoof any
other VM on the network.  For security reasons, we should only
permit unaddressed ports to be created by the tenant on tenant-owned
networks, or by the administrator on shared networks [...]
~~~

Version-Release number of selected component (if applicable):
17+ (as RFE period for 16.x is over)

How reproducible:
N/A

Steps to Reproduce:
N/A

Actual results:

Unable to create VM with ip-less port

Expected results:

Being able to create VM with ip-less port

Additional info:

As we can see in [1] and [5], there is an actual need for such feature in environment dealing with NFV applications.

As we are able to actually create a _similar_ end result, with the following workaround
~~~
 $ openstack port create --no-fixed-ip --no-security-group --disable-port-security <port-name> --network <network-id>
 $ openstack server create [...] <server-name>
 $ openstack server add port <server-name> <port-name>
~~~
it would be nice if we could avoid those extra steps, and work on the nova side, to allow the instance to be created  with a port without a fixed ip.

The business reason behind it is that in environments where NFV VM life cyrcle is done through THT, the lack of such feature[3] is a show stopper.
Because of that, let me push for bp [3] once more, as some time has passed since BZ1669350 comment #4.



[1] https://bugzilla.redhat.com/show_bug.cgi?id=1669350#c4
[2] https://review.opendev.org/#/c/97715/
[3] https://blueprints.launchpad.net/nova/+spec/boot-vm-with-unaddressed-port
[4] https://review.opendev.org/c/openstack/neutron-specs/+/97715/6/specs/juno/nfv-unaddressed-interfaces.rst#83
[5] https://bugzilla.redhat.com/show_bug.cgi?id=1559716

Comment 1 Artom Lifshitz 2021-04-19 20:54:50 UTC
Hi, thanks for the RFE!

We'd like to better understand the use case here, since as you've uncovered yourself thing has a long and storied history, and there are certain things that are already possible.

For instance, it is currently possible to boot a VM with a port with a "deferred" IP allocation policy, that assigns the port an IP only *after* the VM has been scheduled onto a compute host. This is mostly used for the "Routed networks" feature [1]. I suspect this is *not* what's being asked here.

When you say "IP not directly managed by RHOSP", can you clarify what kind of port that translates to? For instance, it could be an SRIOV VF port connected to a provider network. In addition, if the IP allocation is not being managed bu OSP, then how *is* it being managed, and how (if at all) is that management being exposed to OSP?

Thanks in advance for your answers!

[1] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.1/html/networking_guide/deploy-routed-prov-networks

Comment 2 Michele Valsecchi 2021-04-28 05:00:12 UTC
Thanks for getting back to us.

The use case is where the NFV application running on top of RHOSP _has to use_ an IP unknown to Neutron.
In this particular case the NFV application has come constrains out of control of the operator in these regards (i.e. vendor limitations, etc).

The current workaround is to assign a dummy IP to the port, and then let the NFV application take care of the rest.
However, this leads to a situation where the "real IP" used on that port by the NFV application, and what the operator sees from RHOSP layers is conflicting.

I've checked the link you've provided, and IIUC using the "deferred" IP policy would still lead to a situation in where the operator has to deal with this "dummy IP" situation.

Let me know if the info I provided here are enough to clear up your doubts.

Comment 17 Artom Lifshitz 2023-04-14 20:18:57 UTC
Tracked in https://issues.redhat.com/browse/OSPRH-57