neutron : going to shared network is working, going back not

[Peter Struys]

We have admin-generated provider-networks. Projects are allowed to create ports and instances on these networks. When we now set the "shared" property on these networks, we are no longer allowed to unset this property. We get the error : "Unable to reconfigure sharing settings for network net.vlan10.provider. Multiple tenants are using it.". Once all ports and instances created by non-admin projects are removed we can again unset the "shared" property. So, we are allowed to set a parameter for which it is afterwards no longer possible to unset. We have now a network that is visible by all and we do not prefer this situation. Removing the corresponding RBAC policy is also not allowed.

This is a OpenStack-Ansible installation with version Yoga.

[Bence Romsics (bence-romsics)]

Hi,

Thanks for the report!

I'm not sure if the behavior you describe is a bug. If multiple projects are actually using a shared network, why would you expect it to be unshared without an error? How should such a network work when it's shared=False but it has multiple tenants on it?

Maybe I'm missing what you mean. In that case can you please give me a series of commands, inlcuding which one should behave differently and how?

[Peter Struys (peterstruys)]

Hi Bense,

Thanks for taking time.

This is what we do. We have a provider netwerk which is created by
admin. The network is "not shared". We use the OpenStack CLI client and
enter admin credentials at the command prompt.

Now we create a port on this network (we export the variables here below
first) :

/openstack port create --project "$project" --project-domain hera_domain
--network "net.vlan$vlan.provider" --fixed-ip
"subnet=sub.vlan$vlan.provider,ip-address=$portip" "$portname"/

The port is created and can be used to attach an instance. Now we set
the network to "shared" and there is no going back to "not shared"
anymore. We get the error "Multile tenants are using it". In the first
colomn below you see the different tenants.

+----------------------------------+----------------------------------------------------------------------------------------------+--------+----------------------------------------+--------------------------------------+
| project_id                       | name | status |
device_owner                           |
network_id                           |
| 854729ccb76541deaa91b4531513b47c | prt_prv10_101 | ACTIVE |
compute:nova                           |
7b027485-51bd-489e-a483-f0e73d44558d |
| 854729ccb76541deaa91b4531513b47c | prt_prv10_102 | ACTIVE |
compute:nova                           |
7b027485-51bd-489e-a483-f0e73d44558d |
| 854729ccb76541deaa91b4531513b47c | prt_prv10_103 | ACTIVE |
compute:nova                           |
7b027485-51bd-489e-a483-f0e73d44558d |
| 0b3c8d0eedfb4010a5dc3ce9bd76258d | prt_prv10_104 | DOWN
|                                        |
7b027485-51bd-489e-a483-f0e73d44558d |
| 854729ccb76541deaa91b4531513b47c | prt_prv10_39 | ACTIVE |
compute:nova                           |
7b027485-51bd-489e-a483-f0e73d44558d |
| 854729ccb76541deaa91b4531513b47c | prt_prv10_40 | DOWN
|                                        |
7b027485-51bd-489e-a483-f0e73d44558d |
| 854729ccb76541deaa91b4531513b47c | prt_prv10_41 | DOWN
|                                        |
7b027485-51bd-489e-a483-f0e73d44558d |
| 854729ccb76541deaa91b4531513b47c | prt_prv10_42 | ACTIVE |
compute:nova                           |
7b027485-51bd-489e-a483-f0e73d44558d |
| 854729ccb76541deaa91b4531513b47c | prt_prv10_43 | ACTIVE |
compute:nova                           |
7b027485-51bd-489e-a483-f0e73d44558d |
| 854729ccb76541deaa91b4531513b47c | prt_prv10_47 | ACTIVE |
compute:nova                           |
7b027485-51bd-489e-a483-f0e73d44558d |

regards
Peter

On 2023-11-02 11:08, Bence Romsics wrote:
> Hi,
>
> Thanks for the report!
>
> I'm not sure if the behavior you describe is a bug. If multiple projects
> are actually using a shared network, why would you expect it to be
> unshared without an error? How should such a network work when it's
> shared=False but it has multiple tenants on it?
>
> Maybe I'm missing what you mean. In that case can you please give me a
> series of commands, inlcuding which one should behave differently and
> how?
>
> ** Changed in: neutron
> Status: New => Invalid
>

--
mvg
Peter Struys

Systeemgroep
Dept.Computerwetenschappen, KU Leuven
Cel...

[Bence Romsics (bence-romsics)]

Hi Peter,

What project and project_domain values do you use (either as environment variables or as command line arguments) in:

* openstack net create
* openstack port create
* openstack net set?

Can it be that the project_domain is different?

I'm asking this, because if I do what I pasted below, I don't get an error at 'set --no-share'.

$ source openrc admin admin

$ env | egrep ^OS
OS_REGION_NAME=RegionOne
OS_PROJECT_DOMAIN_ID=default
OS_CACERT=
OS_AUTH_URL=http://192.168.122.131/identity
OS_TENANT_NAME=admin
OS_USER_DOMAIN_ID=default
OS_USERNAME=admin
OS_VOLUME_API_VERSION=3
OS_AUTH_TYPE=password
OS_PROJECT_NAME=admin
OS_PASSWORD=devstack
OS_IDENTITY_API_VERSION=3

openstack net create net0 --external --provider-network-type vlan --provider-segment 100 --provider-physical-network public
openstack net set net0 --share
openstack net set net0 --no-share
openstack net delete net0

openstack net create net0 --external --provider-network-type vlan --provider-segment 100 --provider-physical-network public
openstack port create port0 --network net0
openstack net set net0 --share
openstack net set net0 --no-share
openstack port delete port0
openstack net delete net0

[Peter Struys (peterstruys)]

Hi Bence,

Yes, the network was created in the "default" domain by user "admin.

/# openstack network create net.vlan10.provider --project admin
--provider-network-type vlan --provider-physical-network vlan
--provider-segment 10 --external/

The ports are created also by admin but in another domain.

# openstack port create --project prj.xxx.yyy --project-domain
xyz_domain --network net.vlan10.provider --fixed-ip x.y.z.a just_a_port_name

Could that be the cause of what we see happening with shared/unshared ?

regards
Peter

On 2023-11-07 11:15, Bence Romsics wrote:
> Hi Peter,
>
> What project and project_domain values do you use (either as environment
> variables or as command line arguments) in:
>
> * openstack net create
> * openstack port create
> * openstack net set?
>
> Can it be that the project_domain is different?
>
> I'm asking this, because if I do what I pasted below, I don't get an
> error at 'set --no-share'.
>
> $ source openrc admin admin
>
> $ env | egrep ^OS
> OS_REGION_NAME=RegionOne
> OS_PROJECT_DOMAIN_ID=default
> OS_CACERT=
> OS_AUTH_URL=http://192.168.122.131/identity
> OS_TENANT_NAME=admin
> OS_USER_DOMAIN_ID=default
> OS_USERNAME=admin
> OS_VOLUME_API_VERSION=3
> OS_AUTH_TYPE=password
> OS_PROJECT_NAME=admin
> OS_PASSWORD=devstack
> OS_IDENTITY_API_VERSION=3
>
> openstack net create net0 --external --provider-network-type vlan --provider-segment 100 --provider-physical-network public
> openstack net set net0 --share
> openstack net set net0 --no-share
> openstack net delete net0
>
> openstack net create net0 --external --provider-network-type vlan --provider-segment 100 --provider-physical-network public
> openstack port create port0 --network net0
> openstack net set net0 --share
> openstack net set net0 --no-share
> openstack port delete port0
> openstack net delete net0
>

[Bence Romsics (bence-romsics)]

Hi Peter,

I believe that a project in one domain and a project with the same name but in a different domain are completely different projects. At least that's how I interpret this:

https://docs.openstack.org/security-guide/identity/domains.html

So, yes, that's probably the reason for the error ("Unable to reconfigure sharing settings ... Multiple tenants are using it.") you see.

Regards,
Bence

[Peter Struys (peterstruys)]

I understand. But these operations were possible without the network being “shared”. So, the check is done going from shared to unshared but not the other way round. Multiple tenants are allowed to create ports on a non-shared network.

We found the record in the db reflecting this network being shard. Would deleting this record be a option we can contemplate ?

Thank you for your time looking into this.

Regards
Peter

> Op 8 nov 2023 om 11:45 heeft Bence Romsics <email address hidden> het volgende geschreven:
>
> Hi Peter,
>
> I believe that a project in one domain and a project with the same name
> but in a different domain are completely different projects. At least
> that's how I interpret this:
>
> https://docs.openstack.org/security-guide/identity/domains.html
>
> So, yes, that's probably the reason for the error ("Unable to
> reconfigure sharing settings ... Multiple tenants are using it.") you
> see.
>
> Regards,
> Bence
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/2042089
>
> Title:
> neutron : going to shared network is working, going back not
>
> Status in neutron:
> Invalid
>
> Bug description:
> We have admin-generated provider-networks. Projects are allowed to
> create ports and instances on these networks. When we now set the
> "shared" property on these networks, we are no longer allowed to unset
> this property. We get the error : "Unable to reconfigure sharing
> settings for network net.vlan10.provider. Multiple tenants are using
> it.". Once all ports and instances created by non-admin projects are
> removed we can again unset the "shared" property. So, we are allowed
> to set a parameter for which it is afterwards no longer possible to
> unset. We have now a network that is visible by all and we do not
> prefer this situation. Removing the corresponding RBAC policy is also
> not allowed.
>
> This is a OpenStack-Ansible installation with version Yoga.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/neutron/+bug/2042089/+subscriptions
>