Hello. Because other tenants need external network to use with routers, float ips as well as magnum. I think it will be need for private cloud. On Sat, May 3, 2025, 2:31 AM Slawek Kaplonski <skaplons@redhat.com> wrote:
Hi,
W dniu 2.05.2025 o 20:23, Brian Haley pisze:
Hi,
On 5/2/25 8:36 AM, Nguyễn Hữu Khôi wrote:
Could we find a solution for this case? Because they own vlan networks Currently, I can create RBAC Policies to allow tenants using external networks.
I've read this thread a couple of times and I still don't exactly understand what the ask is from Neutron. This tenant "owns" a VLAN network and wants to integrate it and a range of IP addresses into Neutron as an external network?
I also have some problem to understand what the issue is really. First of all I just checked in our code, and policy for port creation don't tell anything about external network. It is allowed for the ADMIN_OR_PROJECT_MEMBER or SERVICE - see
https://github.com/openstack/neutron/blob/7c0aac975a67b5f49bef7b2fb6f643d128... - so if tenant owns this vlan network, it should be doable to create port in such network IMO (but I don't have env up now to check it)
Another thing which I am not sure is why this vlan network needs to be marked as external - are You using it also as external gateway for routers and have floating ips from it? If not (and that's what I understood from the thread so far) you don't need to set `router:external` to `True`.
Also, I don't recall any previous discussions that took place, maybe someone else on the Neutron team does though and can comment next week.
Thanks,
-Brian
On Fri, May 2, 2025 at 5:39 AM Sean Mooney <smooney@redhat.com <mailto:smooney@redhat.com>> wrote:
On 01/05/2025 23:23, melanie witt wrote: > On 5/1/25 15:11, Sean Mooney wrote: >> >> On 01/05/2025 20:22, melanie witt wrote: >>> On 5/1/25 08:17, Sean Mooney wrote: >>>> >>>> On 01/05/2025 15:56, Nguyễn Hữu Khôi wrote: >>>>> Hello. >>>>> I created an external network for a specified project but I cannot >>>>> create instances with the external network on this tenant. >>>>> >>>>> I must create RBAC Policies with shared and external policies then >>>>> my instances can get IP addresses and run properly. >>>>> >>>> booting to a external network is admin only by default. >>>> >>>> depending on your release nova used to enforce this too but in >>>> newer release we defer to neutron to enforce that policy >>> >>> I think I actually looked at this recently while re-triaging old >>> bugs downstream and AFAICT it's still an issue: >>> >>> https://bugs.launchpad.net/nova/+bug/1675486 <https://bugs.launchpad.net/nova/+bug/1675486> >>> >>> We have mentioned the idea of deferring to Neutron for this entirely >>> (and I expect we can with no ill side effects) but I don't believe >>> we formally discussed with the Neutron team to confirm whether it >>> would be 100% OK to do. >>> >>> I think it would be nice to follow up on ^ and finally remove the >>> external network policy check in Nova. >>> >>> -melwitt >> >> we merged https://review.opendev.org/c/openstack/nova/+/794360 <https://review.opendev.org/c/openstack/nova/+/794360> 3 >> years ago >> >> but looking at the code change it just removed the commen so we still >> have our own >> >> NETWORK_ATTACH_EXTERNAL polciy which is admin only. >> >> so i guess an operat can chagne that to project_member but your >> right we never actully removed the proejct. >> >> we probably should do that but ya we can see if neutron are still ok >> with this. >> >> im 99% sure that we talked about it with them in a past ptg but its >> definetly been a couple of years. > > Good to know, it is highly likely that I missed it or forgot given the > time that has passed since then. > > I'm supportive of going ahead and removing it now and give it a lot of > bake time this cycle to uncover potential issues. > >> one thing to keep in mind. external network do not have neutron >> router as there defautl gateway >> >> by default neutron implements the metadata proxy via the l3 agent if >> your ussing ml2/ovs so you need >> >> to enable the option to do that via the dhcp agent if you are still >> usign ml2/ovs or your vms wont have >> >> metadata. for ml2/ovn i think it will just work but perhaps not. > > I didn't understand any of that unfortunately :) but if it's a > potential problem with deferring to Neutron it's good to look out for it. > > -melwitt
sorry i didnt explain it well.
the way the nova metadata api is made aviable to vm is via a neutron proxy, that proxy when not using ovn is provide
by a iptables port forwading rule combinde with a proxy service that translates the users request without any auth into a authitcated request
to novas metadata api.
the metadtat proxy and iptables rule can be deploy be either the neutron l3 agent in the router network namespace or
by the neutron dhcp agent in in the dhcp servers namespace.
the default when not using ovn is for it to be in the router namespace.
because the derault route when you place a port directly on an external network is your datacenter router
not a neutron one a request form teh vm to 169.whatever wil not be proxied to nova so metadta in the vm wont work out of the box
unless you do metadata via the dhcp server instead.
if your using ovn i think this just work because ovn has a metadta proxy on every compute node and it isntalls an openflow rule
that matches on the destination ip to redirect it to that local proxy. so for ovn i belive it will just work.
on the flip side port on an external network wont have there traffic nat'd when going to the internet
external network in neutron are expected to have subnets that are routeable to the WAN so operator need to confiugre there data center routeres
to perform nat if that is not the case and they will also need to provide the eant with an ip pool or precreated subnet+network.
while not un heard of providign tenant with there own external vlan network like this is not very clody in the normal self service workflow but it can have some advantages by allowing the routing to be delgated to a hardware router in your data center.
that can allow your tenats to bring there own ip block to to your datacenter but it need a lot of hand holding from the operator to get setup
initally.
> >> >>> >>>>> Is it normal? Pls correct me if I am wrong >>>> >>>> yes its normal, neutron may have change the defautl to allow non >>>> admins but booting direclty to an extenal network was >>>> >>>> always considerd privaldged in the past. >>>> >>>>> >>>>> Thank you. >>>>> >>>>> Nguyen Huu Khoi >>>> >>> >> >
-- Slawek Kaplonski Principal Software Engineer Red Hat