Hello. As I mentioned earlier, We have multi tenants and each has their own vlan networks. When I create vlan networks for them then I mask it as an external network(with this tenant not * in RABC Policy) and they cannot use this network for launching instances. If I want to use this network I must create a RABC policy shared with this project. Nguyen Huu Khoi On Tue, May 13, 2025 at 2:30 PM Sławek Kapłoński <skaplons@redhat.com> wrote:
Hi,
Dnia poniedziałek, 12 maja 2025 18:19:05 czas środkowoeuropejski letni Nguyễn Hữu Khôi pisze:
Hello.
Could we approve this feature in future releases?
What feature you are exactly asking for?
Nguyen Huu Khoi
On Sat, May 3, 2025 at 7:21 PM Nguyễn Hữu Khôi <
wrote:
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
cannot >>>>> create instances with the external network on this
tenant.
>>>>> >>>>> I must create RBAC Policies with shared and external
but I 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
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
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
are 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
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
nguyenhuukhoinw@gmail.com> this the 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
-- Slawek Kaplonski Principal Software Engineer Red Hat