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/7c0aac975a67b5f49bef7b2fb6f643d128688b3e/neutron/conf/policies/port.py#L72
- 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