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 <nguyenhuukhoinw@gmail.com>
> 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/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
> >>
> >>
--
Slawek Kaplonski
Principal Software Engineer
Red Hat