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
>>>
>>> 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 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
>>>>
>>>
>>
>