[kolla] [train] Horizon port security group management fails
We're running kolla train and we're seeing an apparent bug when we try to add or remove security groups on a port. We see error "Failed to update port <ID>". It works fine in CLI; we only see this in Horizon. Is this a known bug, or are we doing something wrong?
Hello,
This is more likely to be a Horizon bug than an issue with Kolla itself, since Kolla doesn't change much from the default configuration.
You should check Horizon logs in /var/log/kolla/horizon to find the error. I would also encourage you to upgrade to a more recent release, since Train has been marked as End of Life in Kolla recently.
Cheers, Pierre Riteau (priteau)
On Fri, 9 Sept 2022 at 15:41, Albert Braden ozzzo@yahoo.com wrote:
We're running kolla train and we're seeing an apparent bug when we try to add or remove security groups on a port. We see error "Failed to update port <ID>". It works fine in CLI; we only see this in Horizon. Is this a known bug, or are we doing something wrong?
Unfortunately we are running RHOSP in which Train is the latest and greatest. This is what we see in horizon.log:
[Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid 139683266553600] [remote 10.232.233.11:57498] Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau pierre@stackhpc.com wrote:
Hello, This is more likely to be a Horizon bug than an issue with Kolla itself, since Kolla doesn't change much from the default configuration. You should check Horizon logs in /var/log/kolla/horizon to find the error. I would also encourage you to upgrade to a more recent release, since Train has been marked as End of Life in Kolla recently. Cheers,Pierre Riteau (priteau) On Fri, 9 Sept 2022 at 15:41, Albert Braden ozzzo@yahoo.com wrote:
We're running kolla train and we're seeing an apparent bug when we try to add or remove security groups on a port. We see error "Failed to update port <ID>". It works fine in CLI; we only see this in Horizon. Is this a known bug, or are we doing something wrong?
If you are running RHOSP, you might have a support contract with Red Hat?
Are you trying to remove all the security groups from a port that has port_security enabled?
On Tue, Sep 13, 2022 at 11:53 AM Albert Braden ozzzo@yahoo.com wrote:
Unfortunately we are running RHOSP in which Train is the latest and greatest. This is what we see in horizon.log:
[Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid 139683266553600] [remote 10.232.233.11:57498] Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau < pierre@stackhpc.com> wrote:
Hello,
This is more likely to be a Horizon bug than an issue with Kolla itself, since Kolla doesn't change much from the default configuration.
You should check Horizon logs in /var/log/kolla/horizon to find the error. I would also encourage you to upgrade to a more recent release, since Train has been marked as End of Life in Kolla recently.
Cheers, Pierre Riteau (priteau)
On Fri, 9 Sept 2022 at 15:41, Albert Braden ozzzo@yahoo.com wrote:
We're running kolla train and we're seeing an apparent bug when we try to add or remove security groups on a port. We see error "Failed to update port <ID>". It works fine in CLI; we only see this in Horizon. Is this a known bug, or are we doing something wrong?
On CLI I can type "openstack port set --no-security-group <ID>" to remove all security groups. In Horizon, the equivalent operation would be using the - button to remove all groups and then clicking "Update." Using the + button would be the equivalent of typing "openstack port set --security-group <group ID>". There doesn't seem to be a way to remove a single security group via CLI; I think the only way would be to set --no-security-group and then add back the desired groups.
I can successfully add security groups to a port via CLI, or I can remove all security groups. If I go into Horizon and try these operations then I get the error when I click "Update." So it appears that security groups can be added and removed, with port security set, via CLI. We only see the failure when we try to do it via Horizon.
Regarding RHOSP support; I assume that you are joking, or maybe haven't experienced the support that they offer. On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont laurentfdumont@gmail.com wrote:
If you are running RHOSP, you might have a support contract with Red Hat? Are you trying to remove all the security groups from a port that has port_security enabled? On Tue, Sep 13, 2022 at 11:53 AM Albert Braden ozzzo@yahoo.com wrote:
Unfortunately we are running RHOSP in which Train is the latest and greatest. This is what we see in horizon.log:
[Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid 139683266553600] [remote 10.232.233.11:57498] Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau pierre@stackhpc.com wrote:
Hello, This is more likely to be a Horizon bug than an issue with Kolla itself, since Kolla doesn't change much from the default configuration. You should check Horizon logs in /var/log/kolla/horizon to find the error. I would also encourage you to upgrade to a more recent release, since Train has been marked as End of Life in Kolla recently. Cheers,Pierre Riteau (priteau) On Fri, 9 Sept 2022 at 15:41, Albert Braden ozzzo@yahoo.com wrote:
We're running kolla train and we're seeing an apparent bug when we try to add or remove security groups on a port. We see error "Failed to update port <ID>". It works fine in CLI; we only see this in Horizon. Is this a known bug, or are we doing something wrong?
Hi Albert,
While I may not be the best person to address your Horizon concern. I can probably help you with your Red Hat support concerns. If you had any issues you wanted addressed, or feedback you wanted to provide. Feel free to give me a yell.
Looking at your Horizon issue though. It seems the default policy file is what prevents you from updating that port. We can see the default policy like this for example:
[root@controller-2 ~]# podman exec -it neutron_api oslopolicy-policy-generator --namespace neutron | grep "update_port:port_security_enabled" "update_port:port_security_enabled": "rule:context_is_advsvc or rule:admin_or_network_owner"
When you execute the command via the CLI, which user are you using? Are you just sourcing the overcloudrc file, or using export OS_CLOUD=overcloud. If that’s the case then you would be using the admin user on the CLI, but probably a different user when logging into Horizon.
I too would suggest opening a support case. It sounds like you have previously had a negative experience with that. If you want to open a new one and share the case number with me, I can follow up on that for you. As someone who personally knows a lot of the RHOSP Technical Support team from around the world. I’m confident we can right whatever wrong may have occurred there.
Let me know if I can help in any way.
Regards,
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 14 Sep 2022, at 10:36 pm, Albert Braden ozzzo@yahoo.com wrote:
On CLI I can type "openstack port set --no-security-group <ID>" to remove all security groups. In Horizon, the equivalent operation would be using the - button to remove all groups and then clicking "Update." Using the + button would be the equivalent of typing "openstack port set --security-group <group ID>". There doesn't seem to be a way to remove a single security group via CLI; I think the only way would be to set --no-security-group and then add back the desired groups.
I can successfully add security groups to a port via CLI, or I can remove all security groups. If I go into Horizon and try these operations then I get the error when I click "Update." So it appears that security groups can be added and removed, with port security set, via CLI. We only see the failure when we try to do it via Horizon.
Regarding RHOSP support; I assume that you are joking, or maybe haven't experienced the support that they offer. On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont laurentfdumont@gmail.com wrote:
If you are running RHOSP, you might have a support contract with Red Hat?
Are you trying to remove all the security groups from a port that has port_security enabled?
On Tue, Sep 13, 2022 at 11:53 AM Albert Braden <ozzzo@yahoo.com mailto:ozzzo@yahoo.com> wrote: Unfortunately we are running RHOSP in which Train is the latest and greatest. This is what we see in horizon.log:
[Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid 139683266553600] [remote 10.232.233.11:57498 http://10.232.233.11:57498/] Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau <pierre@stackhpc.com mailto:pierre@stackhpc.com> wrote:
Hello,
This is more likely to be a Horizon bug than an issue with Kolla itself, since Kolla doesn't change much from the default configuration.
You should check Horizon logs in /var/log/kolla/horizon to find the error. I would also encourage you to upgrade to a more recent release, since Train has been marked as End of Life in Kolla recently.
Cheers, Pierre Riteau (priteau)
On Fri, 9 Sept 2022 at 15:41, Albert Braden <ozzzo@yahoo.com mailto:ozzzo@yahoo.com> wrote: We're running kolla train and we're seeing an apparent bug when we try to add or remove security groups on a port. We see error "Failed to update port <ID>". It works fine in CLI; we only see this in Horizon. Is this a known bug, or are we doing something wrong?
Hi Brendan, thanks for offering to help! I'll contact you privately with info about some languishing cases.
Here's the policy line: "update_port:port_security_enabled": "rule:context_is_advsvc or rule:admin_or_network_owner"
Does this policy only affect Horizon? I'm using the same non-admin user for both CLI and Horizon, on a project where that user is a member. The network was created by the admin user. On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard bshephar@redhat.com wrote:
Hi Albert, While I may not be the best person to address your Horizon concern. I can probably help you with your Red Hat support concerns. If you had any issues you wanted addressed, or feedback you wanted to provide. Feel free to give me a yell. Looking at your Horizon issue though. It seems the default policy file is what prevents you from updating that port. We can see the default policy like this for example: [root@controller-2 ~]# podman exec -it neutron_api oslopolicy-policy-generator --namespace neutron | grep "update_port:port_security_enabled""update_port:port_security_enabled": "rule:context_is_advsvc or rule:admin_or_network_owner" When you execute the command via the CLI, which user are you using? Are you just sourcing the overcloudrc file, or using export OS_CLOUD=overcloud. If that’s the case then you would be using the admin user on the CLI, but probably a different user when logging into Horizon. I too would suggest opening a support case. It sounds like you have previously had a negative experience with that. If you want to open a new one and share the case number with me, I can follow up on that for you. As someone who personally knows a lot of the RHOSP Technical Support team from around the world. I’m confident we can right whatever wrong may have occurred there. Let me know if I can help in any way. Regards, Brendan Shephard Senior Software Engineer Brisbane, Australia
On 14 Sep 2022, at 10:36 pm, Albert Braden ozzzo@yahoo.com wrote: On CLI I can type "openstack port set --no-security-group <ID>" to remove all security groups. In Horizon, the equivalent operation would be using the - button to remove all groups and then clicking "Update." Using the + button would be the equivalent of typing "openstack port set --security-group <group ID>". There doesn't seem to be a way to remove a single security group via CLI; I think the only way would be to set --no-security-group and then add back the desired groups.
I can successfully add security groups to a port via CLI, or I can remove all security groups. If I go into Horizon and try these operations then I get the error when I click "Update." So it appears that security groups can be added and removed, with port security set, via CLI. We only see the failure when we try to do it via Horizon.
Regarding RHOSP support; I assume that you are joking, or maybe haven't experienced the support that they offer. On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont laurentfdumont@gmail.com wrote:
If you are running RHOSP, you might have a support contract with Red Hat? Are you trying to remove all the security groups from a port that has port_security enabled? On Tue, Sep 13, 2022 at 11:53 AM Albert Braden ozzzo@yahoo.com wrote:
Unfortunately we are running RHOSP in which Train is the latest and greatest. This is what we see in horizon.log:
[Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid 139683266553600] [remote 10.232.233.11:57498] Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau pierre@stackhpc.com wrote:
Hello, This is more likely to be a Horizon bug than an issue with Kolla itself, since Kolla doesn't change much from the default configuration. You should check Horizon logs in /var/log/kolla/horizon to find the error. I would also encourage you to upgrade to a more recent release, since Train has been marked as End of Life in Kolla recently. Cheers,Pierre Riteau (priteau) On Fri, 9 Sept 2022 at 15:41, Albert Braden ozzzo@yahoo.com wrote:
We're running kolla train and we're seeing an apparent bug when we try to add or remove security groups on a port. We see error "Failed to update port <ID>". It works fine in CLI; we only see this in Horizon. Is this a known bug, or are we doing something wrong?
That’s a bit strange. I’ll give it a try.
Regarding RH support, I wasn’t trying to be sarcastic. Like any large scale support service, the quality might vary a little bit but it’s been fairly good in my personal experience.
Of course, a good TAM and some poking is always a good asset.
On Wed, Sep 14, 2022 at 12:25 PM Albert Braden ozzzo@yahoo.com wrote:
Hi Brendan, thanks for offering to help! I'll contact you privately with info about some languishing cases.
Here's the policy line: "update_port:port_security_enabled": "rule:context_is_advsvc or rule:admin_or_network_owner"
Does this policy only affect Horizon? I'm using the same non-admin user for both CLI and Horizon, on a project where that user is a member. The network was created by the admin user. On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard < bshephar@redhat.com> wrote:
Hi Albert,
While I may not be the best person to address your Horizon concern. I can probably help you with your Red Hat support concerns. If you had any issues you wanted addressed, or feedback you wanted to provide. Feel free to give me a yell.
Looking at your Horizon issue though. It seems the default policy file is what prevents you from updating that port. We can see the default policy like this for example:
[root@controller-2 ~]# podman exec -it neutron_api oslopolicy-policy-generator --namespace neutron | grep "update_port:port_security_enabled" "update_port:port_security_enabled": "rule:context_is_advsvc or rule:admin_or_network_owner"
When you execute the command via the CLI, which user are you using? Are you just sourcing the overcloudrc file, or using export OS_CLOUD=overcloud. If that’s the case then you would be using the admin user on the CLI, but probably a different user when logging into Horizon.
I too would suggest opening a support case. It sounds like you have previously had a negative experience with that. If you want to open a new one and share the case number with me, I can follow up on that for you. As someone who personally knows a lot of the RHOSP Technical Support team from around the world. I’m confident we can right whatever wrong may have occurred there.
Let me know if I can help in any way.
Regards,
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 14 Sep 2022, at 10:36 pm, Albert Braden ozzzo@yahoo.com wrote:
On CLI I can type "openstack port set --no-security-group <ID>" to remove all security groups. In Horizon, the equivalent operation would be using the - button to remove all groups and then clicking "Update." Using the + button would be the equivalent of typing "openstack port set --security-group <group ID>". There doesn't seem to be a way to remove a single security group via CLI; I think the only way would be to set --no-security-group and then add back the desired groups.
I can successfully add security groups to a port via CLI, or I can remove all security groups. If I go into Horizon and try these operations then I get the error when I click "Update." So it appears that security groups can be added and removed, with port security set, via CLI. We only see the failure when we try to do it via Horizon.
Regarding RHOSP support; I assume that you are joking, or maybe haven't experienced the support that they offer. On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont < laurentfdumont@gmail.com> wrote:
If you are running RHOSP, you might have a support contract with Red Hat?
Are you trying to remove all the security groups from a port that has port_security enabled?
On Tue, Sep 13, 2022 at 11:53 AM Albert Braden ozzzo@yahoo.com wrote:
Unfortunately we are running RHOSP in which Train is the latest and greatest. This is what we see in horizon.log:
[Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid 139683266553600] [remote 10.232.233.11:57498] Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau < pierre@stackhpc.com> wrote:
Hello,
This is more likely to be a Horizon bug than an issue with Kolla itself, since Kolla doesn't change much from the default configuration.
You should check Horizon logs in /var/log/kolla/horizon to find the error. I would also encourage you to upgrade to a more recent release, since Train has been marked as End of Life in Kolla recently.
Cheers, Pierre Riteau (priteau)
On Fri, 9 Sept 2022 at 15:41, Albert Braden ozzzo@yahoo.com wrote:
We're running kolla train and we're seeing an apparent bug when we try to add or remove security groups on a port. We see error "Failed to update port <ID>". It works fine in CLI; we only see this in Horizon. Is this a known bug, or are we doing something wrong?
Hey Albert,
The policy is the default Neutron policy in OpenStack Train. These can indeed be changed and customised, but my assumption is that you haven’t created any custom policies. Horizon uses the default for each service unless it’s been overwritten.
If I create a non-admin user and try to change security groups I also get the same error: 2022-09-14 22:01:33,370 64 INFO openstack_dashboard.dashboards.project.networks.ports.workflows Failed to update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
And I can reproduce your same scenario ff I try via the CLI using these steps: 1. Add entry for new user to clouds.yaml file: bne-home-test: auth: auth_url: https://openstack.bne-home.net:13000 password: "test" project_domain_name: Default project_name: bne-home user_domain_name: Default username: test cacert: ~/.certs/overcloud-cacert.pem identity_api_version: '3' region_name: regionOne volume_api_version: ‘3'
2. export OS_CLOUD=bne-home-test
3. Try to remove security group from port: ❯ openstack server show test-lb-net -c security_groups -c addresses -f yaml addresses: lb-mgmt-net: - 172.24.0.90 vlan4-infra: - 172.20.13.175 security_groups: - name: management-bne
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips -c port_security_enabled -c security_group_ids -f yaml fixed_ips: - ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 port_security_enabled: true security_group_ids: - a3ae6e20-67df-4a72-9d5b-cc21ad87464f
❯ openstack port unset --security-group a3ae6e20-67df-4a72-9d5b-cc21ad87464f 4df563ce-5464-4f7d-8aaf-c5496cdaefda ❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips -c port_security_enabled -c security_group_ids -f yaml fixed_ips: - ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 port_security_enabled: true security_group_ids: []
Verify that I’m definitely not a admin user: ❯ openstack server list --all Policy doesn't allow os_compute_api:servers:detail:get_all_tenants to be performed. (HTTP 403) (Request-ID: req-75c19210-ad91-471f-b500-e1f3482825f8)
I don’t think this user should be allowed to do that via the CLI either. So that could be a bug there. The request in the Neutron server.log when I do it via the CLI: 2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None req-f99c4c15-003c-4f7e-9e41-9100daa2a566 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 192.168.1.17,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 len: 1102 time: 0.4449480
VS Horizon: 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None req-4c284690-eb69-43df-b205-4953a88ab87c 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 172.20.10.25,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 len: 386 time: 0.2209103
I have raised a upstream bug for this since I can still reproduce it on the latest version of OpenStack: https://bugs.launchpad.net/neutron/+bug/1989627%EF%BF%BC Bug #1989627 “Policy enforcement variance between openstackcli a...” : Bugs : neutron bugs.launchpad.net
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 15 Sep 2022, at 2:25 am, Albert Braden ozzzo@yahoo.com wrote:
Hi Brendan, thanks for offering to help! I'll contact you privately with info about some languishing cases.
Here's the policy line: "update_port:port_security_enabled": "rule:context_is_advsvc or rule:admin_or_network_owner"
Does this policy only affect Horizon? I'm using the same non-admin user for both CLI and Horizon, on a project where that user is a member. The network was created by the admin user. On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard bshephar@redhat.com wrote:
Hi Albert,
While I may not be the best person to address your Horizon concern. I can probably help you with your Red Hat support concerns. If you had any issues you wanted addressed, or feedback you wanted to provide. Feel free to give me a yell.
Looking at your Horizon issue though. It seems the default policy file is what prevents you from updating that port. We can see the default policy like this for example:
[root@controller-2 ~]# podman exec -it neutron_api oslopolicy-policy-generator --namespace neutron | grep "update_port:port_security_enabled" "update_port:port_security_enabled": "rule:context_is_advsvc or rule:admin_or_network_owner"
When you execute the command via the CLI, which user are you using? Are you just sourcing the overcloudrc file, or using export OS_CLOUD=overcloud. If that’s the case then you would be using the admin user on the CLI, but probably a different user when logging into Horizon.
I too would suggest opening a support case. It sounds like you have previously had a negative experience with that. If you want to open a new one and share the case number with me, I can follow up on that for you. As someone who personally knows a lot of the RHOSP Technical Support team from around the world. I’m confident we can right whatever wrong may have occurred there.
Let me know if I can help in any way.
Regards,
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 14 Sep 2022, at 10:36 pm, Albert Braden ozzzo@yahoo.com wrote:
On CLI I can type "openstack port set --no-security-group <ID>" to remove all security groups. In Horizon, the equivalent operation would be using the - button to remove all groups and then clicking "Update." Using the + button would be the equivalent of typing "openstack port set --security-group <group ID>". There doesn't seem to be a way to remove a single security group via CLI; I think the only way would be to set --no-security-group and then add back the desired groups.
I can successfully add security groups to a port via CLI, or I can remove all security groups. If I go into Horizon and try these operations then I get the error when I click "Update." So it appears that security groups can be added and removed, with port security set, via CLI. We only see the failure when we try to do it via Horizon.
Regarding RHOSP support; I assume that you are joking, or maybe haven't experienced the support that they offer. On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont laurentfdumont@gmail.com wrote:
If you are running RHOSP, you might have a support contract with Red Hat?
Are you trying to remove all the security groups from a port that has port_security enabled?
On Tue, Sep 13, 2022 at 11:53 AM Albert Braden <ozzzo@yahoo.com mailto:ozzzo@yahoo.com> wrote: Unfortunately we are running RHOSP in which Train is the latest and greatest. This is what we see in horizon.log:
[Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid 139683266553600] [remote 10.232.233.11:57498 http://10.232.233.11:57498/] Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau <pierre@stackhpc.com mailto:pierre@stackhpc.com> wrote:
Hello,
This is more likely to be a Horizon bug than an issue with Kolla itself, since Kolla doesn't change much from the default configuration.
You should check Horizon logs in /var/log/kolla/horizon to find the error. I would also encourage you to upgrade to a more recent release, since Train has been marked as End of Life in Kolla recently.
Cheers, Pierre Riteau (priteau)
On Fri, 9 Sept 2022 at 15:41, Albert Braden <ozzzo@yahoo.com mailto:ozzzo@yahoo.com> wrote: We're running kolla train and we're seeing an apparent bug when we try to add or remove security groups on a port. We see error "Failed to update port <ID>". It works fine in CLI; we only see this in Horizon. Is this a known bug, or are we doing something wrong?
On Thu, 2022-09-15 at 08:59 +1000, Brendan Shephard wrote:
Hey Albert,
The policy is the default Neutron policy in OpenStack Train. These can indeed be changed and customised, but my assumption is that you haven’t created any custom policies. Horizon uses the default for each service unless it’s been overwritten.
policy is defiend server side not client side so it applie equially to all users of the api so the behavior will be the same for horizon or the cli if you ever find a delta because horizon say used a differnt token to make the request that is a securty vulnerablity in horizon and should be reported privatly to the horizon core team :)
If I create a non-admin user and try to change security groups I also get the same error: 2022-09-14 22:01:33,370 64 INFO openstack_dashboard.dashboards.project.networks.ports.workflows Failed to update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
And I can reproduce your same scenario ff I try via the CLI using these steps:
- Add entry for new user to clouds.yaml file:
bne-home-test: auth: auth_url: https://openstack.bne-home.net:13000 password: "test" project_domain_name: Default project_name: bne-home user_domain_name: Default username: test cacert: ~/.certs/overcloud-cacert.pem identity_api_version: '3' region_name: regionOne volume_api_version: ‘3'
export OS_CLOUD=bne-home-test
Try to remove security group from port:
❯ openstack server show test-lb-net -c security_groups -c addresses -f yaml addresses: lb-mgmt-net:
- 172.24.0.90
vlan4-infra:
- 172.20.13.175
security_groups:
- name: management-bne
the security group listed in nova is the default security group that will be used by all port create by nova. it only applie to ports created by nova and not ones that are passed in using the uuid of a precreate port.
you shoudl in general not mix managing security groups via nova and neutron. horizon shoudl prefer to manage security groups only via neutron if it can.
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips -c port_security_enabled -c security_group_ids -f yaml fixed_ips:
- ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
port_security_enabled: true security_group_ids:
- a3ae6e20-67df-4a72-9d5b-cc21ad87464f
❯ openstack port unset --security-group a3ae6e20-67df-4a72-9d5b-cc21ad87464f 4df563ce-5464-4f7d-8aaf-c5496cdaefda ❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips -c port_security_enabled -c security_group_ids -f yaml fixed_ips:
- ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
port_security_enabled: true security_group_ids: []
Verify that I’m definitely not a admin user: ❯ openstack server list --all Policy doesn't allow os_compute_api:servers:detail:get_all_tenants to be performed. (HTTP 403) (Request-ID: req-75c19210-ad91-471f-b500-e1f3482825f8)
I don’t think this user should be allowed to do that via the CLI either. So that could be a bug there. The request in the Neutron server.log when I do it via the CLI:
user can add or remove security groups without being and admin including removing all securtiy groups thats intended behavior and should not require admin.
are you implying that horizon is doing "openstack server list --all" --all is short for --all-tenants. outside of the admin tab in horizon horizon would never pass the equivlent of --all to the nova api.
2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None req-f99c4c15-003c-4f7e-9e41-9100daa2a566 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 192.168.1.17,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 len: 1102 time: 0.4449480
VS Horizon: 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None req-4c284690-eb69-43df-b205-4953a88ab87c 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 172.20.10.25,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 len: 386 time: 0.2209103
I have raised a upstream bug for this since I can still reproduce it on the latest version of OpenStack: https://bugs.launchpad.net/neutron/+bug/1989627%EF%BF%BC Bug #1989627 “Policy enforcement variance between openstackcli a...” : Bugs : neutron bugs.launchpad.net
policy is enfoced on the nova/neutron api it cant behave differntly for horizon unless horizon is useing the wrong token. i.e. not he users token.
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 15 Sep 2022, at 2:25 am, Albert Braden ozzzo@yahoo.com wrote:
Hi Brendan, thanks for offering to help! I'll contact you privately with info about some languishing cases.
Here's the policy line: "update_port:port_security_enabled": "rule:context_is_advsvc or rule:admin_or_network_owner"
Does this policy only affect Horizon? I'm using the same non-admin user for both CLI and Horizon, on a project where that user is a member. The network was created by the admin user. On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard bshephar@redhat.com wrote:
Hi Albert,
While I may not be the best person to address your Horizon concern. I can probably help you with your Red Hat support concerns. If you had any issues you wanted addressed, or feedback you wanted to provide. Feel free to give me a yell.
Looking at your Horizon issue though. It seems the default policy file is what prevents you from updating that port. We can see the default policy like this for example:
[root@controller-2 ~]# podman exec -it neutron_api oslopolicy-policy-generator --namespace neutron | grep "update_port:port_security_enabled" "update_port:port_security_enabled": "rule:context_is_advsvc or rule:admin_or_network_owner"
When you execute the command via the CLI, which user are you using? Are you just sourcing the overcloudrc file, or using export OS_CLOUD=overcloud. If that’s the case then you would be using the admin user on the CLI, but probably a different user when logging into Horizon.
I too would suggest opening a support case. It sounds like you have previously had a negative experience with that. If you want to open a new one and share the case number with me, I can follow up on that for you. As someone who personally knows a lot of the RHOSP Technical Support team from around the world. I’m confident we can right whatever wrong may have occurred there.
Let me know if I can help in any way.
Regards,
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 14 Sep 2022, at 10:36 pm, Albert Braden ozzzo@yahoo.com wrote:
On CLI I can type "openstack port set --no-security-group <ID>" to remove all security groups. In Horizon, the equivalent operation would be using the - button to remove all groups and then clicking "Update." Using the + button would be the equivalent of typing "openstack port set --security-group <group ID>". There doesn't seem to be a way to remove a single security group via CLI; I think the only way would be to set --no-security-group and then add back the desired groups.
I can successfully add security groups to a port via CLI, or I can remove all security groups. If I go into Horizon and try these operations then I get the error when I click "Update." So it appears that security groups can be added and removed, with port security set, via CLI. We only see the failure when we try to do it via Horizon.
Regarding RHOSP support; I assume that you are joking, or maybe haven't experienced the support that they offer. On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont laurentfdumont@gmail.com wrote:
If you are running RHOSP, you might have a support contract with Red Hat?
Are you trying to remove all the security groups from a port that has port_security enabled?
On Tue, Sep 13, 2022 at 11:53 AM Albert Braden <ozzzo@yahoo.com mailto:ozzzo@yahoo.com> wrote: Unfortunately we are running RHOSP in which Train is the latest and greatest. This is what we see in horizon.log:
[Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid 139683266553600] [remote 10.232.233.11:57498 http://10.232.233.11:57498/] Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau <pierre@stackhpc.com mailto:pierre@stackhpc.com> wrote:
Hello,
This is more likely to be a Horizon bug than an issue with Kolla itself, since Kolla doesn't change much from the default configuration.
You should check Horizon logs in /var/log/kolla/horizon to find the error. I would also encourage you to upgrade to a more recent release, since Train has been marked as End of Life in Kolla recently.
Cheers, Pierre Riteau (priteau)
On Fri, 9 Sept 2022 at 15:41, Albert Braden <ozzzo@yahoo.com mailto:ozzzo@yahoo.com> wrote: We're running kolla train and we're seeing an apparent bug when we try to add or remove security groups on a port. We see error "Failed to update port <ID>". It works fine in CLI; we only see this in Horizon. Is this a known bug, or are we doing something wrong?
Hey Albert,
The policy is the default Neutron policy in OpenStack Train. These can indeed be changed and customised, but my assumption is that you haven’t created any custom policies. Horizon uses the default for each service unless it’s been overwritten.
If I create a non-admin user and try to change security groups I also get the same error: 2022-09-14 22:01:33,370 64 INFO openstack_dashboard.dashboards.project.networks.ports.workflows Failed to update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
And I can reproduce your same scenario ff I try via the CLI using these steps:
- Add entry for new user to clouds.yaml file:
bne-home-test: auth: auth_url: https://openstack.bne-home.net:13000 password: "test" project_domain_name: Default project_name: bne-home user_domain_name: Default username: test cacert: ~/.certs/overcloud-cacert.pem identity_api_version: '3' region_name: regionOne volume_api_version: ‘3'
export OS_CLOUD=bne-home-test
Try to remove security group from port:
❯ openstack server show test-lb-net -c security_groups -c addresses -f yaml addresses: lb-mgmt-net: - 172.24.0.90 vlan4-infra: - 172.20.13.175 security_groups:
- name: management-bne
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips -c port_security_enabled -c security_group_ids -f yaml fixed_ips:
- ip_address: 172.20.13.175
subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 port_security_enabled: true security_group_ids:
- a3ae6e20-67df-4a72-9d5b-cc21ad87464f
❯ openstack port unset --security-group a3ae6e20-67df-4a72-9d5b-cc21ad87464f 4df563ce-5464-4f7d-8aaf-c5496cdaefda ❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips -c port_security_enabled -c security_group_ids -f yaml fixed_ips:
- ip_address: 172.20.13.175
subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 port_security_enabled: true security_group_ids: []
Verify that I’m definitely not a admin user: ❯ openstack server list --all Policy doesn't allow os_compute_api:servers:detail:get_all_tenants to be performed. (HTTP 403) (Request-ID: req-75c19210-ad91-471f-b500-e1f3482825f8)
I don’t think this user should be allowed to do that via the CLI either. So that could be a bug there. The request in the Neutron server.log when I do it via the CLI: 2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None req-f99c4c15-003c-4f7e-9e41-9100daa2a566 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 192.168.1.17,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 len: 1102 time: 0.4449480
VS Horizon: 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None req-4c284690-eb69-43df-b205-4953a88ab87c 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 172.20.10.25,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 len: 386 time: 0.2209103
I have raised a upstream bug for this since I can still reproduce it on the latest version of OpenStack: launchpad-og-image.pngBug #1989627 “Policy enforcement variance between openstackcli a...” : Bugs : neutron bugs.launchpad.net
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 15 Sep 2022, at 2:25 am, Albert Braden ozzzo@yahoo.com wrote:
Hi Brendan, thanks for offering to help! I'll contact you privately with info about some languishing cases.
Here's the policy line: "update_port:port_security_enabled": "rule:context_is_advsvc or rule:admin_or_network_owner"
Does this policy only affect Horizon? I'm using the same non-admin user for both CLI and Horizon, on a project where that user is a member. The network was created by the admin user. On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard bshephar@redhat.com wrote:
Hi Albert,
While I may not be the best person to address your Horizon concern. I can probably help you with your Red Hat support concerns. If you had any issues you wanted addressed, or feedback you wanted to provide. Feel free to give me a yell.
Looking at your Horizon issue though. It seems the default policy file is what prevents you from updating that port. We can see the default policy like this for example:
[root@controller-2 ~]# podman exec -it neutron_api oslopolicy-policy-generator --namespace neutron | grep "update_port:port_security_enabled" "update_port:port_security_enabled": "rule:context_is_advsvc or rule:admin_or_network_owner"
When you execute the command via the CLI, which user are you using? Are you just sourcing the overcloudrc file, or using export OS_CLOUD=overcloud. If that’s the case then you would be using the admin user on the CLI, but probably a different user when logging into Horizon.
I too would suggest opening a support case. It sounds like you have previously had a negative experience with that. If you want to open a new one and share the case number with me, I can follow up on that for you. As someone who personally knows a lot of the RHOSP Technical Support team from around the world. I’m confident we can right whatever wrong may have occurred there.
Let me know if I can help in any way.
Regards,
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 14 Sep 2022, at 10:36 pm, Albert Braden ozzzo@yahoo.com wrote:
On CLI I can type "openstack port set --no-security-group <ID>" to remove all security groups. In Horizon, the equivalent operation would be using the - button to remove all groups and then clicking "Update." Using the + button would be the equivalent of typing "openstack port set --security-group <group ID>". There doesn't seem to be a way to remove a single security group via CLI; I think the only way would be to set --no-security-group and then add back the desired groups.
I can successfully add security groups to a port via CLI, or I can remove all security groups. If I go into Horizon and try these operations then I get the error when I click "Update." So it appears that security groups can be added and removed, with port security set, via CLI. We only see the failure when we try to do it via Horizon.
Regarding RHOSP support; I assume that you are joking, or maybe haven't experienced the support that they offer. On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont laurentfdumont@gmail.com wrote:
If you are running RHOSP, you might have a support contract with Red Hat?
Are you trying to remove all the security groups from a port that has port_security enabled?
On Tue, Sep 13, 2022 at 11:53 AM Albert Braden ozzzo@yahoo.com wrote:
Unfortunately we are running RHOSP in which Train is the latest and greatest. This is what we see in horizon.log:
[Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid 139683266553600] [remote 10.232.233.11:57498] Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau pierre@stackhpc.com wrote:
Hello,
This is more likely to be a Horizon bug than an issue with Kolla itself, since Kolla doesn't change much from the default configuration.
You should check Horizon logs in /var/log/kolla/horizon to find the error. I would also encourage you to upgrade to a more recent release, since Train has been marked as End of Life in Kolla recently.
Cheers, Pierre Riteau (priteau)
On Fri, 9 Sept 2022 at 15:41, Albert Braden ozzzo@yahoo.com wrote:
We're running kolla train and we're seeing an apparent bug when we try to add or remove security groups on a port. We see error "Failed to update port <ID>". It works fine in CLI; we only see this in Horizon. Is this a known bug, or are we doing something wrong?
Hey Sean,
Thanks for the reply.
For reference, I have all the steps to reproduce along with the relevant debug logs attached to this LP: https://bugs.launchpad.net/neutron/+bug/1989627
But, to summarize. If I go to any random instance in Horizon as a member user - not a admin. Then try to remove any Security Group at all from any of the ports it fails with the policy violation (I attached a screenshot of where I'm making that change in Horizon). But doing it with the same user from the cli works fine. Since I'm editing individual interfaces there, rather than the instance itself. I assumed these would all be API calls to Neutron from Horizon rather than from Horizon to Nova.
I just run server list --all to demonstrate I was indeed using a member user and not a admin since an admin would have seen VM's from all projects.
I agree with you in principle. It should be exactly the same whether it comes from openstackclient or from Horizon. In fact, I was 98% positive I would be able to demonstrate the wrong user was being used in this case. But unfortunately, my efforts to reproduce it demonstrated that the two are indeed handled differently.
I believe anyone should be able to reproduce it using the steps I outlined on the LP.
Brendan Shephard
Senior Software Engineer
Red Hat APAC https://www.redhat.com
193 N Quay
Brisbane City QLD 4000 @RedHat https://twitter.com/redhat Red Hat https://www.linkedin.com/company/red-hat Red Hat https://www.facebook.com/RedHatInc https://red.ht/sig https://redhat.com/summit
On Thu, Sep 15, 2022 at 8:48 PM Sean Mooney smooney@redhat.com wrote:
On Thu, 2022-09-15 at 08:59 +1000, Brendan Shephard wrote:
Hey Albert,
The policy is the default Neutron policy in OpenStack Train. These can
indeed be changed and customised, but my assumption is that you haven’t created any custom policies. Horizon uses the default for each service unless it’s been overwritten. policy is defiend server side not client side so it applie equially to all users of the api so the behavior will be the same for horizon or the cli if you ever find a delta because horizon say used a differnt token to make the request that is a securty vulnerablity in horizon and should be reported privatly to the horizon core team :)
If I create a non-admin user and try to change security groups I also
get the same error:
2022-09-14 22:01:33,370 64 INFO
openstack_dashboard.dashboards.project.networks.ports.workflows Failed to update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
And I can reproduce your same scenario ff I try via the CLI using these
steps:
- Add entry for new user to clouds.yaml file:
bne-home-test: auth: auth_url: https://openstack.bne-home.net:13000 password: "test" project_domain_name: Default project_name: bne-home user_domain_name: Default username: test cacert: ~/.certs/overcloud-cacert.pem identity_api_version: '3' region_name: regionOne volume_api_version: ‘3'
export OS_CLOUD=bne-home-test
Try to remove security group from port:
❯ openstack server show test-lb-net -c security_groups -c addresses -f
yaml
addresses: lb-mgmt-net:
- 172.24.0.90
vlan4-infra:
- 172.20.13.175
security_groups:
- name: management-bne
the security group listed in nova is the default security group that will be used by all port create by nova. it only applie to ports created by nova and not ones that are passed in using the uuid of a precreate port.
you shoudl in general not mix managing security groups via nova and neutron. horizon shoudl prefer to manage security groups only via neutron if it can.
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
port_security_enabled: true security_group_ids:
- a3ae6e20-67df-4a72-9d5b-cc21ad87464f
❯ openstack port unset --security-group
a3ae6e20-67df-4a72-9d5b-cc21ad87464f 4df563ce-5464-4f7d-8aaf-c5496cdaefda
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
port_security_enabled: true security_group_ids: []
Verify that I’m definitely not a admin user: ❯ openstack server list --all Policy doesn't allow os_compute_api:servers:detail:get_all_tenants to be
performed. (HTTP 403) (Request-ID: req-75c19210-ad91-471f-b500-e1f3482825f8)
I don’t think this user should be allowed to do that via the CLI either.
So that could be a bug there. The request in the Neutron server.log when I do it via the CLI:
user can add or remove security groups without being and admin including removing all securtiy groups thats intended behavior and should not require admin.
are you implying that horizon is doing "openstack server list --all" --all is short for --all-tenants. outside of the admin tab in horizon horizon would never pass the equivlent of --all to the nova api.
2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None
req-f99c4c15-003c-4f7e-9e41-9100daa2a566 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 192.168.1.17,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 len: 1102 time: 0.4449480
VS Horizon: 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None
req-4c284690-eb69-43df-b205-4953a88ab87c 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 172.20.10.25,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 len: 386 time: 0.2209103
I have raised a upstream bug for this since I can still reproduce it on
the latest version of OpenStack:
https://bugs.launchpad.net/neutron/+bug/1989627%EF%BF%BC Bug #1989627 “Policy enforcement variance between openstackcli a...” :
Bugs : neutron
bugs.launchpad.net
policy is enfoced on the nova/neutron api it cant behave differntly for horizon unless horizon is useing the wrong token. i.e. not he users token.
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 15 Sep 2022, at 2:25 am, Albert Braden ozzzo@yahoo.com wrote:
Hi Brendan, thanks for offering to help! I'll contact you privately
with info about some languishing cases.
Here's the policy line: "update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
Does this policy only affect Horizon? I'm using the same non-admin
user for both CLI and Horizon, on a project where that user is a member. The network was created by the admin user.
On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard <
bshephar@redhat.com> wrote:
Hi Albert,
While I may not be the best person to address your Horizon concern. I
can probably help you with your Red Hat support concerns. If you had any issues you wanted addressed, or feedback you wanted to provide. Feel free to give me a yell.
Looking at your Horizon issue though. It seems the default policy file
is what prevents you from updating that port. We can see the default policy like this for example:
[root@controller-2 ~]# podman exec -it neutron_api
oslopolicy-policy-generator --namespace neutron | grep "update_port:port_security_enabled"
"update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
When you execute the command via the CLI, which user are you using?
Are you just sourcing the overcloudrc file, or using export OS_CLOUD=overcloud. If that’s the case then you would be using the admin user on the CLI, but probably a different user when logging into Horizon.
I too would suggest opening a support case. It sounds like you have
previously had a negative experience with that. If you want to open a new one and share the case number with me, I can follow up on that for you. As someone who personally knows a lot of the RHOSP Technical Support team from around the world. I’m confident we can right whatever wrong may have occurred there.
Let me know if I can help in any way.
Regards,
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 14 Sep 2022, at 10:36 pm, Albert Braden ozzzo@yahoo.com wrote:
On CLI I can type "openstack port set --no-security-group <ID>" to
remove all security groups. In Horizon, the equivalent operation would be using the - button to remove all groups and then clicking "Update." Using the + button would be the equivalent of typing "openstack port set --security-group <group ID>". There doesn't seem to be a way to remove a single security group via CLI; I think the only way would be to set --no-security-group and then add back the desired groups.
I can successfully add security groups to a port via CLI, or I can
remove all security groups. If I go into Horizon and try these operations then I get the error when I click "Update." So it appears that security groups can be added and removed, with port security set, via CLI. We only see the failure when we try to do it via Horizon.
Regarding RHOSP support; I assume that you are joking, or maybe
haven't experienced the support that they offer.
On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont <
laurentfdumont@gmail.com> wrote:
If you are running RHOSP, you might have a support contract with Red
Hat?
Are you trying to remove all the security groups from a port that
has port_security enabled?
On Tue, Sep 13, 2022 at 11:53 AM Albert Braden <ozzzo@yahoo.com
mailto:ozzzo@yahoo.com> wrote:
Unfortunately we are running RHOSP in which Train is the latest and
greatest. This is what we see in horizon.log:
[Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid
139683266553600] [remote 10.232.233.11:57498 http://10.232.233.11:57498/] Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau <
pierre@stackhpc.com mailto:pierre@stackhpc.com> wrote:
Hello,
This is more likely to be a Horizon bug than an issue with Kolla
itself, since Kolla doesn't change much from the default configuration.
You should check Horizon logs in /var/log/kolla/horizon to find the
error. I would also encourage you to upgrade to a more recent release, since Train has been marked as End of Life in Kolla recently.
Cheers, Pierre Riteau (priteau)
On Fri, 9 Sept 2022 at 15:41, Albert Braden <ozzzo@yahoo.com
mailto:ozzzo@yahoo.com> wrote:
We're running kolla train and we're seeing an apparent bug when we
try to add or remove security groups on a port. We see error "Failed to update port <ID>". It works fine in CLI; we only see this in Horizon. Is this a known bug, or are we doing something wrong?
Hey Albert,
The policy is the default Neutron policy in OpenStack Train. These can
indeed be changed and customised, but my assumption is that you haven’t created any custom policies. Horizon uses the default for each service unless it’s been overwritten.
If I create a non-admin user and try to change security groups I also
get the same error:
2022-09-14 22:01:33,370 64 INFO
openstack_dashboard.dashboards.project.networks.ports.workflows Failed to update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
And I can reproduce your same scenario ff I try via the CLI using these
steps:
- Add entry for new user to clouds.yaml file:
bne-home-test: auth: auth_url: https://openstack.bne-home.net:13000 password: "test" project_domain_name: Default project_name: bne-home user_domain_name: Default username: test cacert: ~/.certs/overcloud-cacert.pem identity_api_version: '3' region_name: regionOne volume_api_version: ‘3'
export OS_CLOUD=bne-home-test
Try to remove security group from port:
❯ openstack server show test-lb-net -c security_groups -c addresses -f
yaml
addresses: lb-mgmt-net:
- 172.24.0.90
vlan4-infra:
- 172.20.13.175
security_groups:
- name: management-bne
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
port_security_enabled: true security_group_ids:
- a3ae6e20-67df-4a72-9d5b-cc21ad87464f
❯ openstack port unset --security-group
a3ae6e20-67df-4a72-9d5b-cc21ad87464f 4df563ce-5464-4f7d-8aaf-c5496cdaefda
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
port_security_enabled: true security_group_ids: []
Verify that I’m definitely not a admin user: ❯ openstack server list --all Policy doesn't allow os_compute_api:servers:detail:get_all_tenants to be
performed. (HTTP 403) (Request-ID: req-75c19210-ad91-471f-b500-e1f3482825f8)
I don’t think this user should be allowed to do that via the CLI either.
So that could be a bug there. The request in the Neutron server.log when I do it via the CLI:
2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None
req-f99c4c15-003c-4f7e-9e41-9100daa2a566 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 192.168.1.17,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 len: 1102 time: 0.4449480
VS Horizon: 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None
req-4c284690-eb69-43df-b205-4953a88ab87c 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 172.20.10.25,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 len: 386 time: 0.2209103
I have raised a upstream bug for this since I can still reproduce it on
the latest version of OpenStack:
launchpad-og-image.pngBug #1989627 “Policy enforcement variance between
openstackcli a...” : Bugs : neutron
bugs.launchpad.net
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 15 Sep 2022, at 2:25 am, Albert Braden ozzzo@yahoo.com wrote:
Hi Brendan, thanks for offering to help! I'll contact you privately
with info about some languishing cases.
Here's the policy line: "update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
Does this policy only affect Horizon? I'm using the same non-admin
user for both CLI and Horizon, on a project where that user is a member. The network was created by the admin user.
On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard <
bshephar@redhat.com> wrote:
Hi Albert,
While I may not be the best person to address your Horizon concern. I
can probably help you with your Red Hat support concerns. If you had any issues you wanted addressed, or feedback you wanted to provide. Feel free to give me a yell.
Looking at your Horizon issue though. It seems the default policy file
is what prevents you from updating that port. We can see the default policy like this for example:
[root@controller-2 ~]# podman exec -it neutron_api
oslopolicy-policy-generator --namespace neutron | grep "update_port:port_security_enabled"
"update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
When you execute the command via the CLI, which user are you using?
Are you just sourcing the overcloudrc file, or using export OS_CLOUD=overcloud. If that’s the case then you would be using the admin user on the CLI, but probably a different user when logging into Horizon.
I too would suggest opening a support case. It sounds like you have
previously had a negative experience with that. If you want to open a new one and share the case number with me, I can follow up on that for you. As someone who personally knows a lot of the RHOSP Technical Support team from around the world. I’m confident we can right whatever wrong may have occurred there.
Let me know if I can help in any way.
Regards,
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 14 Sep 2022, at 10:36 pm, Albert Braden ozzzo@yahoo.com wrote:
On CLI I can type "openstack port set --no-security-group <ID>" to
remove all security groups. In Horizon, the equivalent operation would be using the - button to remove all groups and then clicking "Update." Using the + button would be the equivalent of typing "openstack port set --security-group <group ID>". There doesn't seem to be a way to remove a single security group via CLI; I think the only way would be to set --no-security-group and then add back the desired groups.
I can successfully add security groups to a port via CLI, or I can
remove all security groups. If I go into Horizon and try these operations then I get the error when I click "Update." So it appears that security groups can be added and removed, with port security set, via CLI. We only see the failure when we try to do it via Horizon.
Regarding RHOSP support; I assume that you are joking, or maybe
haven't experienced the support that they offer.
On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont <
laurentfdumont@gmail.com> wrote:
If you are running RHOSP, you might have a support contract with Red
Hat?
Are you trying to remove all the security groups from a port that
has port_security enabled?
On Tue, Sep 13, 2022 at 11:53 AM Albert Braden ozzzo@yahoo.com
wrote:
Unfortunately we are running RHOSP in which Train is the latest
and greatest. This is what we see in horizon.log:
[Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid
139683266553600] [remote 10.232.233.11:57498] Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau <
pierre@stackhpc.com> wrote:
Hello,
This is more likely to be a Horizon bug than an issue with Kolla
itself, since Kolla doesn't change much from the default configuration.
You should check Horizon logs in /var/log/kolla/horizon to find
the error. I would also encourage you to upgrade to a more recent release, since Train has been marked as End of Life in Kolla recently.
Cheers, Pierre Riteau (priteau)
On Fri, 9 Sept 2022 at 15:41, Albert Braden ozzzo@yahoo.com
wrote:
We're running kolla train and we're seeing an apparent bug when
we try to add or remove security groups on a port. We see error "Failed to update port <ID>". It works fine in CLI; we only see this in Horizon. Is this a known bug, or are we doing something wrong?
On Thu, 2022-09-15 at 21:33 +1000, Brendan Shephard wrote:
Hey Sean,
Thanks for the reply.
For reference, I have all the steps to reproduce along with the relevant debug logs attached to this LP: https://bugs.launchpad.net/neutron/+bug/1989627
But, to summarize. If I go to any random instance in Horizon as a member user - not a admin. Then try to remove any Security Group at all from any of the ports it fails with the policy violation (I attached a screenshot of where I'm making that change in Horizon). But doing it with the same user from the cli works fine. Since I'm editing individual interfaces there, rather than the instance itself. I assumed these would all be API calls to Neutron from Horizon rather than from Horizon to Nova.
updating the instance securty group will not affect any exsitng ports when you want to add or remvoe security groups form a port in horizont you do not do that via the instace secutity group you do it via the port edit dialog in the port detail view under the network
https://<your cloud goes here>/dashboard/project/networks/ports/<port uuid>/detail
i just did that now on a train cloud we have internally and was able to add and remove a security group on a port.
I just run server list --all to demonstrate I was indeed using a member user and not a admin since an admin would have seen VM's from all projects.
I agree with you in principle. It should be exactly the same whether it comes from openstackclient or from Horizon. In fact, I was 98% positive I would be able to demonstrate the wrong user was being used in this case. But unfortunately, my efforts to reproduce it demonstrated that the two are indeed handled differently.
what page in horizon are you editing it form if i try and add/remove the secirty group via the interfaces tabe at https://<cloud>/dashboard/project/instances/<instance uuid>/ it also work for me inlcuding removing all secuity groups and i am not an admin on this cloud.
specificly this is the redhat internal shared cloud i was testing on.
I believe anyone should be able to reproduce it using the steps I outlined on the LP.
Brendan Shephard
Senior Software Engineer
Red Hat APAC https://www.redhat.com
193 N Quay
Brisbane City QLD 4000 @RedHat https://twitter.com/redhat Red Hat https://www.linkedin.com/company/red-hat Red Hat https://www.facebook.com/RedHatInc https://red.ht/sig https://redhat.com/summit
On Thu, Sep 15, 2022 at 8:48 PM Sean Mooney smooney@redhat.com wrote:
On Thu, 2022-09-15 at 08:59 +1000, Brendan Shephard wrote:
Hey Albert,
The policy is the default Neutron policy in OpenStack Train. These can
indeed be changed and customised, but my assumption is that you haven’t created any custom policies. Horizon uses the default for each service unless it’s been overwritten. policy is defiend server side not client side so it applie equially to all users of the api so the behavior will be the same for horizon or the cli if you ever find a delta because horizon say used a differnt token to make the request that is a securty vulnerablity in horizon and should be reported privatly to the horizon core team :)
If I create a non-admin user and try to change security groups I also
get the same error:
2022-09-14 22:01:33,370 64 INFO
openstack_dashboard.dashboards.project.networks.ports.workflows Failed to update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
And I can reproduce your same scenario ff I try via the CLI using these
steps:
- Add entry for new user to clouds.yaml file:
bne-home-test: auth: auth_url: https://openstack.bne-home.net:13000 password: "test" project_domain_name: Default project_name: bne-home user_domain_name: Default username: test cacert: ~/.certs/overcloud-cacert.pem identity_api_version: '3' region_name: regionOne volume_api_version: ‘3'
export OS_CLOUD=bne-home-test
Try to remove security group from port:
❯ openstack server show test-lb-net -c security_groups -c addresses -f
yaml
addresses: lb-mgmt-net:
- 172.24.0.90
vlan4-infra:
- 172.20.13.175
security_groups:
- name: management-bne
the security group listed in nova is the default security group that will be used by all port create by nova. it only applie to ports created by nova and not ones that are passed in using the uuid of a precreate port.
you shoudl in general not mix managing security groups via nova and neutron. horizon shoudl prefer to manage security groups only via neutron if it can.
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
port_security_enabled: true security_group_ids:
- a3ae6e20-67df-4a72-9d5b-cc21ad87464f
❯ openstack port unset --security-group
a3ae6e20-67df-4a72-9d5b-cc21ad87464f 4df563ce-5464-4f7d-8aaf-c5496cdaefda
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
port_security_enabled: true security_group_ids: []
Verify that I’m definitely not a admin user: ❯ openstack server list --all Policy doesn't allow os_compute_api:servers:detail:get_all_tenants to be
performed. (HTTP 403) (Request-ID: req-75c19210-ad91-471f-b500-e1f3482825f8)
I don’t think this user should be allowed to do that via the CLI either.
So that could be a bug there. The request in the Neutron server.log when I do it via the CLI:
user can add or remove security groups without being and admin including removing all securtiy groups thats intended behavior and should not require admin.
are you implying that horizon is doing "openstack server list --all" --all is short for --all-tenants. outside of the admin tab in horizon horizon would never pass the equivlent of --all to the nova api.
2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None
req-f99c4c15-003c-4f7e-9e41-9100daa2a566 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 192.168.1.17,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 len: 1102 time: 0.4449480
VS Horizon: 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None
req-4c284690-eb69-43df-b205-4953a88ab87c 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 172.20.10.25,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 len: 386 time: 0.2209103
I have raised a upstream bug for this since I can still reproduce it on
the latest version of OpenStack:
https://bugs.launchpad.net/neutron/+bug/1989627%EF%BF%BC Bug #1989627 “Policy enforcement variance between openstackcli a...” :
Bugs : neutron
bugs.launchpad.net
policy is enfoced on the nova/neutron api it cant behave differntly for horizon unless horizon is useing the wrong token. i.e. not he users token.
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 15 Sep 2022, at 2:25 am, Albert Braden ozzzo@yahoo.com wrote:
Hi Brendan, thanks for offering to help! I'll contact you privately
with info about some languishing cases.
Here's the policy line: "update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
Does this policy only affect Horizon? I'm using the same non-admin
user for both CLI and Horizon, on a project where that user is a member. The network was created by the admin user.
On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard <
bshephar@redhat.com> wrote:
Hi Albert,
While I may not be the best person to address your Horizon concern. I
can probably help you with your Red Hat support concerns. If you had any issues you wanted addressed, or feedback you wanted to provide. Feel free to give me a yell.
Looking at your Horizon issue though. It seems the default policy file
is what prevents you from updating that port. We can see the default policy like this for example:
[root@controller-2 ~]# podman exec -it neutron_api
oslopolicy-policy-generator --namespace neutron | grep "update_port:port_security_enabled"
"update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
When you execute the command via the CLI, which user are you using?
Are you just sourcing the overcloudrc file, or using export OS_CLOUD=overcloud. If that’s the case then you would be using the admin user on the CLI, but probably a different user when logging into Horizon.
I too would suggest opening a support case. It sounds like you have
previously had a negative experience with that. If you want to open a new one and share the case number with me, I can follow up on that for you. As someone who personally knows a lot of the RHOSP Technical Support team from around the world. I’m confident we can right whatever wrong may have occurred there.
Let me know if I can help in any way.
Regards,
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 14 Sep 2022, at 10:36 pm, Albert Braden ozzzo@yahoo.com wrote:
On CLI I can type "openstack port set --no-security-group <ID>" to
remove all security groups. In Horizon, the equivalent operation would be using the - button to remove all groups and then clicking "Update." Using the + button would be the equivalent of typing "openstack port set --security-group <group ID>". There doesn't seem to be a way to remove a single security group via CLI; I think the only way would be to set --no-security-group and then add back the desired groups.
I can successfully add security groups to a port via CLI, or I can
remove all security groups. If I go into Horizon and try these operations then I get the error when I click "Update." So it appears that security groups can be added and removed, with port security set, via CLI. We only see the failure when we try to do it via Horizon.
Regarding RHOSP support; I assume that you are joking, or maybe
haven't experienced the support that they offer.
On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont <
laurentfdumont@gmail.com> wrote:
If you are running RHOSP, you might have a support contract with Red
Hat?
Are you trying to remove all the security groups from a port that
has port_security enabled?
On Tue, Sep 13, 2022 at 11:53 AM Albert Braden <ozzzo@yahoo.com
mailto:ozzzo@yahoo.com> wrote:
Unfortunately we are running RHOSP in which Train is the latest and
greatest. This is what we see in horizon.log:
[Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid
139683266553600] [remote 10.232.233.11:57498 http://10.232.233.11:57498/] Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau <
pierre@stackhpc.com mailto:pierre@stackhpc.com> wrote:
Hello,
This is more likely to be a Horizon bug than an issue with Kolla
itself, since Kolla doesn't change much from the default configuration.
You should check Horizon logs in /var/log/kolla/horizon to find the
error. I would also encourage you to upgrade to a more recent release, since Train has been marked as End of Life in Kolla recently.
Cheers, Pierre Riteau (priteau)
On Fri, 9 Sept 2022 at 15:41, Albert Braden <ozzzo@yahoo.com
mailto:ozzzo@yahoo.com> wrote:
We're running kolla train and we're seeing an apparent bug when we
try to add or remove security groups on a port. We see error "Failed to update port <ID>". It works fine in CLI; we only see this in Horizon. Is this a known bug, or are we doing something wrong?
Hey Albert,
The policy is the default Neutron policy in OpenStack Train. These can
indeed be changed and customised, but my assumption is that you haven’t created any custom policies. Horizon uses the default for each service unless it’s been overwritten.
If I create a non-admin user and try to change security groups I also
get the same error:
2022-09-14 22:01:33,370 64 INFO
openstack_dashboard.dashboards.project.networks.ports.workflows Failed to update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
And I can reproduce your same scenario ff I try via the CLI using these
steps:
- Add entry for new user to clouds.yaml file:
bne-home-test: auth: auth_url: https://openstack.bne-home.net:13000 password: "test" project_domain_name: Default project_name: bne-home user_domain_name: Default username: test cacert: ~/.certs/overcloud-cacert.pem identity_api_version: '3' region_name: regionOne volume_api_version: ‘3'
export OS_CLOUD=bne-home-test
Try to remove security group from port:
❯ openstack server show test-lb-net -c security_groups -c addresses -f
yaml
addresses: lb-mgmt-net:
- 172.24.0.90
vlan4-infra:
- 172.20.13.175
security_groups:
- name: management-bne
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
port_security_enabled: true security_group_ids:
- a3ae6e20-67df-4a72-9d5b-cc21ad87464f
❯ openstack port unset --security-group
a3ae6e20-67df-4a72-9d5b-cc21ad87464f 4df563ce-5464-4f7d-8aaf-c5496cdaefda
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
port_security_enabled: true security_group_ids: []
Verify that I’m definitely not a admin user: ❯ openstack server list --all Policy doesn't allow os_compute_api:servers:detail:get_all_tenants to be
performed. (HTTP 403) (Request-ID: req-75c19210-ad91-471f-b500-e1f3482825f8)
I don’t think this user should be allowed to do that via the CLI either.
So that could be a bug there. The request in the Neutron server.log when I do it via the CLI:
2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None
req-f99c4c15-003c-4f7e-9e41-9100daa2a566 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 192.168.1.17,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 len: 1102 time: 0.4449480
VS Horizon: 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None
req-4c284690-eb69-43df-b205-4953a88ab87c 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 172.20.10.25,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 len: 386 time: 0.2209103
I have raised a upstream bug for this since I can still reproduce it on
the latest version of OpenStack:
launchpad-og-image.pngBug #1989627 “Policy enforcement variance between
openstackcli a...” : Bugs : neutron
bugs.launchpad.net
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 15 Sep 2022, at 2:25 am, Albert Braden ozzzo@yahoo.com wrote:
Hi Brendan, thanks for offering to help! I'll contact you privately
with info about some languishing cases.
Here's the policy line: "update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
Does this policy only affect Horizon? I'm using the same non-admin
user for both CLI and Horizon, on a project where that user is a member. The network was created by the admin user.
On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard <
bshephar@redhat.com> wrote:
Hi Albert,
While I may not be the best person to address your Horizon concern. I
can probably help you with your Red Hat support concerns. If you had any issues you wanted addressed, or feedback you wanted to provide. Feel free to give me a yell.
Looking at your Horizon issue though. It seems the default policy file
is what prevents you from updating that port. We can see the default policy like this for example:
[root@controller-2 ~]# podman exec -it neutron_api
oslopolicy-policy-generator --namespace neutron | grep "update_port:port_security_enabled"
"update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
When you execute the command via the CLI, which user are you using?
Are you just sourcing the overcloudrc file, or using export OS_CLOUD=overcloud. If that’s the case then you would be using the admin user on the CLI, but probably a different user when logging into Horizon.
I too would suggest opening a support case. It sounds like you have
previously had a negative experience with that. If you want to open a new one and share the case number with me, I can follow up on that for you. As someone who personally knows a lot of the RHOSP Technical Support team from around the world. I’m confident we can right whatever wrong may have occurred there.
Let me know if I can help in any way.
Regards,
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 14 Sep 2022, at 10:36 pm, Albert Braden ozzzo@yahoo.com wrote:
On CLI I can type "openstack port set --no-security-group <ID>" to
remove all security groups. In Horizon, the equivalent operation would be using the - button to remove all groups and then clicking "Update." Using the + button would be the equivalent of typing "openstack port set --security-group <group ID>". There doesn't seem to be a way to remove a single security group via CLI; I think the only way would be to set --no-security-group and then add back the desired groups.
I can successfully add security groups to a port via CLI, or I can
remove all security groups. If I go into Horizon and try these operations then I get the error when I click "Update." So it appears that security groups can be added and removed, with port security set, via CLI. We only see the failure when we try to do it via Horizon.
Regarding RHOSP support; I assume that you are joking, or maybe
haven't experienced the support that they offer.
On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont <
laurentfdumont@gmail.com> wrote:
If you are running RHOSP, you might have a support contract with Red
Hat?
Are you trying to remove all the security groups from a port that
has port_security enabled?
On Tue, Sep 13, 2022 at 11:53 AM Albert Braden ozzzo@yahoo.com
wrote:
Unfortunately we are running RHOSP in which Train is the latest
and greatest. This is what we see in horizon.log:
[Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid
139683266553600] [remote 10.232.233.11:57498] Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau <
pierre@stackhpc.com> wrote:
Hello,
This is more likely to be a Horizon bug than an issue with Kolla
itself, since Kolla doesn't change much from the default configuration.
You should check Horizon logs in /var/log/kolla/horizon to find
the error. I would also encourage you to upgrade to a more recent release, since Train has been marked as End of Life in Kolla recently.
Cheers, Pierre Riteau (priteau)
On Fri, 9 Sept 2022 at 15:41, Albert Braden ozzzo@yahoo.com
wrote:
> We're running kolla train and we're seeing an apparent bug when
we try to add or remove security groups on a port. We see error "Failed to update port <ID>". It works fine in CLI; we only see this in Horizon. Is this a known bug, or are we doing something wrong?
>
Hey,
I'm doing it from the instances one: https://openstack.bne-home.net/dashboard/project/instances/ccb72b14-3694-40f...
But for what it's worth. I get the same error if I do it from: https://openstack.bne-home.net/dashboard/project/networks/acefae53-b4d5-422f...
Interesting that it worked for you there. Be good to confirm with @ozzzo@yahoo.com ozzzo@yahoo.com as well as to exactly where in Horizon he is trying to modify the security groups. Just so we're all trying to do the exact same thing.
My environment is also deployed from the latest tripleo packages, so I'll also test on that internal lab you referenced Sean. That would be more representative of Alberts issue since he is using RHOSP.
Brendan Shephard
Senior Software Engineer
Red Hat APAC https://www.redhat.com
193 N Quay
Brisbane City QLD 4000 @RedHat https://twitter.com/redhat Red Hat https://www.linkedin.com/company/red-hat Red Hat https://www.facebook.com/RedHatInc https://red.ht/sig https://redhat.com/summit
On Thu, Sep 15, 2022 at 10:12 PM Sean Mooney smooney@redhat.com wrote:
On Thu, 2022-09-15 at 21:33 +1000, Brendan Shephard wrote:
Hey Sean,
Thanks for the reply.
For reference, I have all the steps to reproduce along with the relevant debug logs attached to this LP: https://bugs.launchpad.net/neutron/+bug/1989627
But, to summarize. If I go to any random instance in Horizon as a member user - not a admin. Then try to remove any Security Group at all from any of the ports it fails with the policy violation (I attached a screenshot
of
where I'm making that change in Horizon). But doing it with the same user from the cli works fine. Since I'm editing individual interfaces there, rather than the instance itself. I assumed these would all be API calls
to
Neutron from Horizon rather than from Horizon to Nova.
updating the instance securty group will not affect any exsitng ports when you want to add or remvoe security groups form a port in horizont you do not do that via the instace secutity group you do it via the port edit dialog in the port detail view under the network
https://<your cloud goes here>/dashboard/project/networks/ports/<port uuid>/detail
i just did that now on a train cloud we have internally and was able to add and remove a security group on a port.
I just run server list --all to demonstrate I was indeed using a member user and not a admin since an admin would have seen VM's from all
projects.
I agree with you in principle. It should be exactly the same whether it comes from openstackclient or from Horizon. In fact, I was 98% positive I would be able to demonstrate the wrong user was being used in this case. But unfortunately, my efforts to reproduce it demonstrated that the two
are
indeed handled differently.
what page in horizon are you editing it form if i try and add/remove the secirty group via the interfaces tabe at https://<cloud>/dashboard/project/instances/<instance uuid>/ it also work for me inlcuding removing all secuity groups and i am not an admin on this cloud.
specificly this is the redhat internal shared cloud i was testing on.
I believe anyone should be able to reproduce it using the steps I
outlined
on the LP.
Brendan Shephard
Senior Software Engineer
Red Hat APAC https://www.redhat.com
193 N Quay
Brisbane City QLD 4000 @RedHat https://twitter.com/redhat Red Hat https://www.linkedin.com/company/red-hat Red Hat https://www.facebook.com/RedHatInc https://red.ht/sig https://redhat.com/summit
On Thu, Sep 15, 2022 at 8:48 PM Sean Mooney smooney@redhat.com wrote:
On Thu, 2022-09-15 at 08:59 +1000, Brendan Shephard wrote:
Hey Albert,
The policy is the default Neutron policy in OpenStack Train. These
can
indeed be changed and customised, but my assumption is that you haven’t created any custom policies. Horizon uses the default for each service unless it’s been overwritten. policy is defiend server side not client side so it applie equially to
all
users of the api so the behavior will be the same for horizon or the cli if you ever find a delta because horizon say used a differnt token to
make
the request that is a securty vulnerablity in horizon and should be reported privatly to the horizon core team :)
If I create a non-admin user and try to change security groups I also
get the same error:
2022-09-14 22:01:33,370 64 INFO
openstack_dashboard.dashboards.project.networks.ports.workflows Failed
to
update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port
and
rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
And I can reproduce your same scenario ff I try via the CLI using
these
steps:
- Add entry for new user to clouds.yaml file:
bne-home-test: auth: auth_url: https://openstack.bne-home.net:13000 password: "test" project_domain_name: Default project_name: bne-home user_domain_name: Default username: test cacert: ~/.certs/overcloud-cacert.pem identity_api_version: '3' region_name: regionOne volume_api_version: ‘3'
export OS_CLOUD=bne-home-test
Try to remove security group from port:
❯ openstack server show test-lb-net -c security_groups -c addresses
-f
yaml
addresses: lb-mgmt-net:
- 172.24.0.90
vlan4-infra:
- 172.20.13.175
security_groups:
- name: management-bne
the security group listed in nova is the default security group that
will
be used by all port create by nova. it only applie to ports created by nova and not ones that are passed in using the uuid of a precreate port.
you shoudl in general not mix managing security groups via nova and neutron. horizon shoudl prefer to manage security groups only via neutron if it
can.
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c
fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
port_security_enabled: true security_group_ids:
- a3ae6e20-67df-4a72-9d5b-cc21ad87464f
❯ openstack port unset --security-group
a3ae6e20-67df-4a72-9d5b-cc21ad87464f
4df563ce-5464-4f7d-8aaf-c5496cdaefda
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c
fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
port_security_enabled: true security_group_ids: []
Verify that I’m definitely not a admin user: ❯ openstack server list --all Policy doesn't allow os_compute_api:servers:detail:get_all_tenants
to be
performed. (HTTP 403) (Request-ID:
req-75c19210-ad91-471f-b500-e1f3482825f8)
I don’t think this user should be allowed to do that via the CLI
either.
So that could be a bug there. The request in the Neutron server.log
when I
do it via the CLI:
user can add or remove security groups without being and admin
including
removing all securtiy groups thats intended behavior and should not
require
admin.
are you implying that horizon is doing "openstack server list --all"
--all
is short for --all-tenants. outside of the admin tab in horizon horizon would never pass the
equivlent
of --all to the nova api.
2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None
req-f99c4c15-003c-4f7e-9e41-9100daa2a566
781362d053ee4708a21430d3a825795a
3ff28fc7abf742a6b7a0d016771dee49 - - default default] 192.168.1.17,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 len: 1102 time: 0.4449480
VS Horizon: 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None
req-4c284690-eb69-43df-b205-4953a88ab87c
781362d053ee4708a21430d3a825795a
3ff28fc7abf742a6b7a0d016771dee49 - - default default] 172.20.10.25,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 len: 386 time: 0.2209103
I have raised a upstream bug for this since I can still reproduce it
on
the latest version of OpenStack:
https://bugs.launchpad.net/neutron/+bug/1989627%EF%BF%BC Bug #1989627 “Policy enforcement variance between openstackcli a...”
:
Bugs : neutron
bugs.launchpad.net
policy is enfoced on the nova/neutron api it cant behave differntly for horizon unless horizon is useing the wrong token. i.e. not he users token.
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 15 Sep 2022, at 2:25 am, Albert Braden ozzzo@yahoo.com wrote:
Hi Brendan, thanks for offering to help! I'll contact you privately
with info about some languishing cases.
Here's the policy line: "update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
Does this policy only affect Horizon? I'm using the same non-admin
user for both CLI and Horizon, on a project where that user is a
member.
The network was created by the admin user.
On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan
Shephard <
bshephar@redhat.com> wrote:
Hi Albert,
While I may not be the best person to address your Horizon
concern. I
can probably help you with your Red Hat support concerns. If you had
any
issues you wanted addressed, or feedback you wanted to provide. Feel
free
to give me a yell.
Looking at your Horizon issue though. It seems the default policy
file
is what prevents you from updating that port. We can see the default
policy
like this for example:
[root@controller-2 ~]# podman exec -it neutron_api
oslopolicy-policy-generator --namespace neutron | grep "update_port:port_security_enabled"
"update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
When you execute the command via the CLI, which user are you using?
Are you just sourcing the overcloudrc file, or using export OS_CLOUD=overcloud. If that’s the case then you would be using the
admin
user on the CLI, but probably a different user when logging into
Horizon.
I too would suggest opening a support case. It sounds like you have
previously had a negative experience with that. If you want to open a
new
one and share the case number with me, I can follow up on that for
you. As
someone who personally knows a lot of the RHOSP Technical Support team
from
around the world. I’m confident we can right whatever wrong may have occurred there.
Let me know if I can help in any way.
Regards,
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 14 Sep 2022, at 10:36 pm, Albert Braden ozzzo@yahoo.com
wrote:
On CLI I can type "openstack port set --no-security-group <ID>"
to
remove all security groups. In Horizon, the equivalent operation would
be
using the - button to remove all groups and then clicking "Update."
Using
the + button would be the equivalent of typing "openstack port set --security-group <group ID>". There doesn't seem to be a way to remove
a
single security group via CLI; I think the only way would be to set --no-security-group and then add back the desired groups.
I can successfully add security groups to a port via CLI, or I
can
remove all security groups. If I go into Horizon and try these
operations
then I get the error when I click "Update." So it appears that security groups can be added and removed, with port security set, via CLI. We
only
see the failure when we try to do it via Horizon.
Regarding RHOSP support; I assume that you are joking, or maybe
haven't experienced the support that they offer.
On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont <
laurentfdumont@gmail.com> wrote:
If you are running RHOSP, you might have a support contract with
Red
Hat?
Are you trying to remove all the security groups from a port that
has port_security enabled?
On Tue, Sep 13, 2022 at 11:53 AM Albert Braden <ozzzo@yahoo.com
mailto:ozzzo@yahoo.com> wrote:
Unfortunately we are running RHOSP in which Train is the latest
and
greatest. This is what we see in horizon.log:
[Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid
139683266553600] [remote 10.232.233.11:57498 <
http://10.232.233.11:57498/%3E]
Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau <
pierre@stackhpc.com mailto:pierre@stackhpc.com> wrote:
Hello,
This is more likely to be a Horizon bug than an issue with Kolla
itself, since Kolla doesn't change much from the default configuration.
You should check Horizon logs in /var/log/kolla/horizon to find
the
error. I would also encourage you to upgrade to a more recent release, since Train has been marked as End of Life in Kolla recently.
Cheers, Pierre Riteau (priteau)
On Fri, 9 Sept 2022 at 15:41, Albert Braden <ozzzo@yahoo.com
mailto:ozzzo@yahoo.com> wrote:
We're running kolla train and we're seeing an apparent bug when
we
try to add or remove security groups on a port. We see error "Failed to update port <ID>". It works fine in CLI; we only see this in Horizon.
Is
this a known bug, or are we doing something wrong?
Hey Albert,
The policy is the default Neutron policy in OpenStack Train. These
can
indeed be changed and customised, but my assumption is that you haven’t created any custom policies. Horizon uses the default for each service unless it’s been overwritten.
If I create a non-admin user and try to change security groups I also
get the same error:
2022-09-14 22:01:33,370 64 INFO
openstack_dashboard.dashboards.project.networks.ports.workflows Failed
to
update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port
and
rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
And I can reproduce your same scenario ff I try via the CLI using
these
steps:
- Add entry for new user to clouds.yaml file:
bne-home-test: auth: auth_url: https://openstack.bne-home.net:13000 password: "test" project_domain_name: Default project_name: bne-home user_domain_name: Default username: test cacert: ~/.certs/overcloud-cacert.pem identity_api_version: '3' region_name: regionOne volume_api_version: ‘3'
export OS_CLOUD=bne-home-test
Try to remove security group from port:
❯ openstack server show test-lb-net -c security_groups -c addresses
-f
yaml
addresses: lb-mgmt-net:
- 172.24.0.90
vlan4-infra:
- 172.20.13.175
security_groups:
- name: management-bne
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c
fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
port_security_enabled: true security_group_ids:
- a3ae6e20-67df-4a72-9d5b-cc21ad87464f
❯ openstack port unset --security-group
a3ae6e20-67df-4a72-9d5b-cc21ad87464f
4df563ce-5464-4f7d-8aaf-c5496cdaefda
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c
fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
port_security_enabled: true security_group_ids: []
Verify that I’m definitely not a admin user: ❯ openstack server list --all Policy doesn't allow os_compute_api:servers:detail:get_all_tenants
to be
performed. (HTTP 403) (Request-ID:
req-75c19210-ad91-471f-b500-e1f3482825f8)
I don’t think this user should be allowed to do that via the CLI
either.
So that could be a bug there. The request in the Neutron server.log
when I
do it via the CLI:
2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None
req-f99c4c15-003c-4f7e-9e41-9100daa2a566
781362d053ee4708a21430d3a825795a
3ff28fc7abf742a6b7a0d016771dee49 - - default default] 192.168.1.17,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 len: 1102 time: 0.4449480
VS Horizon: 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None
req-4c284690-eb69-43df-b205-4953a88ab87c
781362d053ee4708a21430d3a825795a
3ff28fc7abf742a6b7a0d016771dee49 - - default default] 172.20.10.25,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 len: 386 time: 0.2209103
I have raised a upstream bug for this since I can still reproduce it
on
the latest version of OpenStack:
launchpad-og-image.pngBug #1989627 “Policy enforcement variance
between
openstackcli a...” : Bugs : neutron
bugs.launchpad.net
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 15 Sep 2022, at 2:25 am, Albert Braden ozzzo@yahoo.com wrote:
Hi Brendan, thanks for offering to help! I'll contact you
privately
with info about some languishing cases.
Here's the policy line: "update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
Does this policy only affect Horizon? I'm using the same non-admin
user for both CLI and Horizon, on a project where that user is a
member.
The network was created by the admin user.
On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan
Shephard <
bshephar@redhat.com> wrote:
Hi Albert,
While I may not be the best person to address your Horizon
concern. I
can probably help you with your Red Hat support concerns. If you had
any
issues you wanted addressed, or feedback you wanted to provide. Feel
free
to give me a yell.
Looking at your Horizon issue though. It seems the default policy
file
is what prevents you from updating that port. We can see the default
policy
like this for example:
[root@controller-2 ~]# podman exec -it neutron_api
oslopolicy-policy-generator --namespace neutron | grep "update_port:port_security_enabled"
"update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
When you execute the command via the CLI, which user are you using?
Are you just sourcing the overcloudrc file, or using export OS_CLOUD=overcloud. If that’s the case then you would be using the
admin
user on the CLI, but probably a different user when logging into
Horizon.
I too would suggest opening a support case. It sounds like you have
previously had a negative experience with that. If you want to open a
new
one and share the case number with me, I can follow up on that for
you. As
someone who personally knows a lot of the RHOSP Technical Support team
from
around the world. I’m confident we can right whatever wrong may have occurred there.
Let me know if I can help in any way.
Regards,
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 14 Sep 2022, at 10:36 pm, Albert Braden ozzzo@yahoo.com
wrote:
On CLI I can type "openstack port set --no-security-group <ID>"
to
remove all security groups. In Horizon, the equivalent operation would
be
using the - button to remove all groups and then clicking "Update."
Using
the + button would be the equivalent of typing "openstack port set --security-group <group ID>". There doesn't seem to be a way to remove
a
single security group via CLI; I think the only way would be to set --no-security-group and then add back the desired groups.
I can successfully add security groups to a port via CLI, or I
can
remove all security groups. If I go into Horizon and try these
operations
then I get the error when I click "Update." So it appears that security groups can be added and removed, with port security set, via CLI. We
only
see the failure when we try to do it via Horizon.
Regarding RHOSP support; I assume that you are joking, or maybe
haven't experienced the support that they offer.
On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont
<
laurentfdumont@gmail.com> wrote:
If you are running RHOSP, you might have a support contract with
Red
Hat?
Are you trying to remove all the security groups from a port that
has port_security enabled?
On Tue, Sep 13, 2022 at 11:53 AM Albert Braden ozzzo@yahoo.com
wrote:
> Unfortunately we are running RHOSP in which Train is the
latest
and greatest. This is what we see in horizon.log:
> > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid
139683266553600] [remote 10.232.233.11:57498] Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
> On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau <
pierre@stackhpc.com> wrote:
> > > Hello, > > This is more likely to be a Horizon bug than an issue with
Kolla
itself, since Kolla doesn't change much from the default configuration.
> > You should check Horizon logs in /var/log/kolla/horizon to find
the error. I would also encourage you to upgrade to a more recent
release,
since Train has been marked as End of Life in Kolla recently.
> > Cheers, > Pierre Riteau (priteau) > > On Fri, 9 Sept 2022 at 15:41, Albert Braden ozzzo@yahoo.com
wrote:
> > We're running kolla train and we're seeing an apparent bug
when
we try to add or remove security groups on a port. We see error
"Failed to
update port <ID>". It works fine in CLI; we only see this in Horizon.
Is
this a known bug, or are we doing something wrong?
> >
If I add/remove security groups from an instance in Horizon, it works. It's when I add/remove security groups from a port that the error occurs. One way to reproduce is to click on the instance and then go to the "Interfaces" tab, and click "Update Security Groups" on the right. On Thursday, September 15, 2022, 08:21:17 AM EDT, Brendan Shephard bshephar@redhat.com wrote:
Hey, I'm doing it from the instances one:https://openstack.bne-home.net/dashboard/project/instances/ccb72b14-3694-40f...
But for what it's worth. I get the same error if I do it from:https://openstack.bne-home.net/dashboard/project/networks/acefae53-b4d5-422f...
Interesting that it worked for you there. Be good to confirm with @ozzzo@yahoo.com as well as to exactly where in Horizon he is trying to modify the security groups. Just so we're all trying to do the exact same thing. My environment is also deployed from the latest tripleo packages, so I'll also test on that internal lab you referenced Sean. That would be more representative of Alberts issue since he is using RHOSP.
Brendan Shephard
Senior Software Engineer
Red Hat APAC
193 N Quay
Brisbane City QLD 4000 @RedHat Red Hat Red Hat | | |
On Thu, Sep 15, 2022 at 10:12 PM Sean Mooney smooney@redhat.com wrote:
On Thu, 2022-09-15 at 21:33 +1000, Brendan Shephard wrote:
Hey Sean,
Thanks for the reply.
For reference, I have all the steps to reproduce along with the relevant debug logs attached to this LP: https://bugs.launchpad.net/neutron/+bug/1989627
But, to summarize. If I go to any random instance in Horizon as a member user - not a admin. Then try to remove any Security Group at all from any of the ports it fails with the policy violation (I attached a screenshot of where I'm making that change in Horizon). But doing it with the same user from the cli works fine. Since I'm editing individual interfaces there, rather than the instance itself. I assumed these would all be API calls to Neutron from Horizon rather than from Horizon to Nova.
updating the instance securty group will not affect any exsitng ports when you want to add or remvoe security groups form a port in horizont you do not do that via the instace secutity group you do it via the port edit dialog in the port detail view under the network
https://<your cloud goes here>/dashboard/project/networks/ports/<port uuid>/detail
i just did that now on a train cloud we have internally and was able to add and remove a security group on a port.
I just run server list --all to demonstrate I was indeed using a member user and not a admin since an admin would have seen VM's from all projects.
I agree with you in principle. It should be exactly the same whether it comes from openstackclient or from Horizon. In fact, I was 98% positive I would be able to demonstrate the wrong user was being used in this case. But unfortunately, my efforts to reproduce it demonstrated that the two are indeed handled differently.
what page in horizon are you editing it form if i try and add/remove the secirty group via the interfaces tabe at https://<cloud>/dashboard/project/instances/<instance uuid>/ it also work for me inlcuding removing all secuity groups and i am not an admin on this cloud.
specificly this is the redhat internal shared cloud i was testing on.
I believe anyone should be able to reproduce it using the steps I outlined on the LP.
Brendan Shephard
Senior Software Engineer
Red Hat APAC https://www.redhat.com
193 N Quay
Brisbane City QLD 4000 @RedHat https://twitter.com/redhat Red Hat https://www.linkedin.com/company/red-hat Red Hat https://www.facebook.com/RedHatInc https://red.ht/sig https://redhat.com/summit
On Thu, Sep 15, 2022 at 8:48 PM Sean Mooney smooney@redhat.com wrote:
On Thu, 2022-09-15 at 08:59 +1000, Brendan Shephard wrote:
Hey Albert,
The policy is the default Neutron policy in OpenStack Train. These can
indeed be changed and customised, but my assumption is that you haven’t created any custom policies. Horizon uses the default for each service unless it’s been overwritten. policy is defiend server side not client side so it applie equially to all users of the api so the behavior will be the same for horizon or the cli if you ever find a delta because horizon say used a differnt token to make the request that is a securty vulnerablity in horizon and should be reported privatly to the horizon core team :)
If I create a non-admin user and try to change security groups I also
get the same error:
2022-09-14 22:01:33,370 64 INFO
openstack_dashboard.dashboards.project.networks.ports.workflows Failed to update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
And I can reproduce your same scenario ff I try via the CLI using these
steps:
- Add entry for new user to clouds.yaml file:
bne-home-test: auth: auth_url: https://openstack.bne-home.net:13000 password: "test" project_domain_name: Default project_name: bne-home user_domain_name: Default username: test cacert: ~/.certs/overcloud-cacert.pem identity_api_version: '3' region_name: regionOne volume_api_version: ‘3'
export OS_CLOUD=bne-home-test
Try to remove security group from port:
❯ openstack server show test-lb-net -c security_groups -c addresses -f
yaml
addresses: lb-mgmt-net: - 172.24.0.90 vlan4-infra: - 172.20.13.175 security_groups:
- name: management-bne
the security group listed in nova is the default security group that will be used by all port create by nova. it only applie to ports created by nova and not ones that are passed in using the uuid of a precreate port.
you shoudl in general not mix managing security groups via nova and neutron. horizon shoudl prefer to manage security groups only via neutron if it can.
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175
subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 port_security_enabled: true security_group_ids:
- a3ae6e20-67df-4a72-9d5b-cc21ad87464f
❯ openstack port unset --security-group
a3ae6e20-67df-4a72-9d5b-cc21ad87464f 4df563ce-5464-4f7d-8aaf-c5496cdaefda
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175
subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 port_security_enabled: true security_group_ids: []
Verify that I’m definitely not a admin user: ❯ openstack server list --all Policy doesn't allow os_compute_api:servers:detail:get_all_tenants to be
performed. (HTTP 403) (Request-ID: req-75c19210-ad91-471f-b500-e1f3482825f8)
I don’t think this user should be allowed to do that via the CLI either.
So that could be a bug there. The request in the Neutron server.log when I do it via the CLI:
user can add or remove security groups without being and admin including removing all securtiy groups thats intended behavior and should not require admin.
are you implying that horizon is doing "openstack server list --all" --all is short for --all-tenants. outside of the admin tab in horizon horizon would never pass the equivlent of --all to the nova api.
2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None
req-f99c4c15-003c-4f7e-9e41-9100daa2a566 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 192.168.1.17,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 len: 1102 time: 0.4449480
VS Horizon: 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None
req-4c284690-eb69-43df-b205-4953a88ab87c 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 172.20.10.25,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 len: 386 time: 0.2209103
I have raised a upstream bug for this since I can still reproduce it on
the latest version of OpenStack:
https://bugs.launchpad.net/neutron/+bug/1989627%EF%BF%BC Bug #1989627 “Policy enforcement variance between openstackcli a...” :
Bugs : neutron
bugs.launchpad.net
policy is enfoced on the nova/neutron api it cant behave differntly for horizon unless horizon is useing the wrong token. i.e. not he users token.
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 15 Sep 2022, at 2:25 am, Albert Braden ozzzo@yahoo.com wrote:
Hi Brendan, thanks for offering to help! I'll contact you privately
with info about some languishing cases.
Here's the policy line: "update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
Does this policy only affect Horizon? I'm using the same non-admin
user for both CLI and Horizon, on a project where that user is a member. The network was created by the admin user.
On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard <
bshephar@redhat.com> wrote:
Hi Albert,
While I may not be the best person to address your Horizon concern. I
can probably help you with your Red Hat support concerns. If you had any issues you wanted addressed, or feedback you wanted to provide. Feel free to give me a yell.
Looking at your Horizon issue though. It seems the default policy file
is what prevents you from updating that port. We can see the default policy like this for example:
[root@controller-2 ~]# podman exec -it neutron_api
oslopolicy-policy-generator --namespace neutron | grep "update_port:port_security_enabled"
"update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
When you execute the command via the CLI, which user are you using?
Are you just sourcing the overcloudrc file, or using export OS_CLOUD=overcloud. If that’s the case then you would be using the admin user on the CLI, but probably a different user when logging into Horizon.
I too would suggest opening a support case. It sounds like you have
previously had a negative experience with that. If you want to open a new one and share the case number with me, I can follow up on that for you. As someone who personally knows a lot of the RHOSP Technical Support team from around the world. I’m confident we can right whatever wrong may have occurred there.
Let me know if I can help in any way.
Regards,
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 14 Sep 2022, at 10:36 pm, Albert Braden ozzzo@yahoo.com wrote:
On CLI I can type "openstack port set --no-security-group <ID>" to
remove all security groups. In Horizon, the equivalent operation would be using the - button to remove all groups and then clicking "Update." Using the + button would be the equivalent of typing "openstack port set --security-group <group ID>". There doesn't seem to be a way to remove a single security group via CLI; I think the only way would be to set --no-security-group and then add back the desired groups.
I can successfully add security groups to a port via CLI, or I can
remove all security groups. If I go into Horizon and try these operations then I get the error when I click "Update." So it appears that security groups can be added and removed, with port security set, via CLI. We only see the failure when we try to do it via Horizon.
Regarding RHOSP support; I assume that you are joking, or maybe
haven't experienced the support that they offer.
On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont <
laurentfdumont@gmail.com> wrote:
If you are running RHOSP, you might have a support contract with Red
Hat?
Are you trying to remove all the security groups from a port that
has port_security enabled?
On Tue, Sep 13, 2022 at 11:53 AM Albert Braden <ozzzo@yahoo.com
mailto:ozzzo@yahoo.com> wrote:
Unfortunately we are running RHOSP in which Train is the latest and
greatest. This is what we see in horizon.log:
[Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid
139683266553600] [remote 10.232.233.11:57498 http://10.232.233.11:57498/] Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau <
pierre@stackhpc.com mailto:pierre@stackhpc.com> wrote:
Hello,
This is more likely to be a Horizon bug than an issue with Kolla
itself, since Kolla doesn't change much from the default configuration.
You should check Horizon logs in /var/log/kolla/horizon to find the
error. I would also encourage you to upgrade to a more recent release, since Train has been marked as End of Life in Kolla recently.
Cheers, Pierre Riteau (priteau)
On Fri, 9 Sept 2022 at 15:41, Albert Braden <ozzzo@yahoo.com
mailto:ozzzo@yahoo.com> wrote:
We're running kolla train and we're seeing an apparent bug when we
try to add or remove security groups on a port. We see error "Failed to update port <ID>". It works fine in CLI; we only see this in Horizon. Is this a known bug, or are we doing something wrong?
Hey Albert,
The policy is the default Neutron policy in OpenStack Train. These can
indeed be changed and customised, but my assumption is that you haven’t created any custom policies. Horizon uses the default for each service unless it’s been overwritten.
If I create a non-admin user and try to change security groups I also
get the same error:
2022-09-14 22:01:33,370 64 INFO
openstack_dashboard.dashboards.project.networks.ports.workflows Failed to update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
And I can reproduce your same scenario ff I try via the CLI using these
steps:
- Add entry for new user to clouds.yaml file:
bne-home-test: auth: auth_url: https://openstack.bne-home.net:13000 password: "test" project_domain_name: Default project_name: bne-home user_domain_name: Default username: test cacert: ~/.certs/overcloud-cacert.pem identity_api_version: '3' region_name: regionOne volume_api_version: ‘3'
export OS_CLOUD=bne-home-test
Try to remove security group from port:
❯ openstack server show test-lb-net -c security_groups -c addresses -f
yaml
addresses: lb-mgmt-net: - 172.24.0.90 vlan4-infra: - 172.20.13.175 security_groups:
- name: management-bne
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175
subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 port_security_enabled: true security_group_ids:
- a3ae6e20-67df-4a72-9d5b-cc21ad87464f
❯ openstack port unset --security-group
a3ae6e20-67df-4a72-9d5b-cc21ad87464f 4df563ce-5464-4f7d-8aaf-c5496cdaefda
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175
subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 port_security_enabled: true security_group_ids: []
Verify that I’m definitely not a admin user: ❯ openstack server list --all Policy doesn't allow os_compute_api:servers:detail:get_all_tenants to be
performed. (HTTP 403) (Request-ID: req-75c19210-ad91-471f-b500-e1f3482825f8)
I don’t think this user should be allowed to do that via the CLI either.
So that could be a bug there. The request in the Neutron server.log when I do it via the CLI:
2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None
req-f99c4c15-003c-4f7e-9e41-9100daa2a566 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 192.168.1.17,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 len: 1102 time: 0.4449480
VS Horizon: 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None
req-4c284690-eb69-43df-b205-4953a88ab87c 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 172.20.10.25,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 len: 386 time: 0.2209103
I have raised a upstream bug for this since I can still reproduce it on
the latest version of OpenStack:
launchpad-og-image.pngBug #1989627 “Policy enforcement variance between
openstackcli a...” : Bugs : neutron
bugs.launchpad.net
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 15 Sep 2022, at 2:25 am, Albert Braden ozzzo@yahoo.com wrote:
Hi Brendan, thanks for offering to help! I'll contact you privately
with info about some languishing cases.
Here's the policy line: "update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
Does this policy only affect Horizon? I'm using the same non-admin
user for both CLI and Horizon, on a project where that user is a member. The network was created by the admin user.
On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard <
bshephar@redhat.com> wrote:
Hi Albert,
While I may not be the best person to address your Horizon concern. I
can probably help you with your Red Hat support concerns. If you had any issues you wanted addressed, or feedback you wanted to provide. Feel free to give me a yell.
Looking at your Horizon issue though. It seems the default policy file
is what prevents you from updating that port. We can see the default policy like this for example:
[root@controller-2 ~]# podman exec -it neutron_api
oslopolicy-policy-generator --namespace neutron | grep "update_port:port_security_enabled"
"update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
When you execute the command via the CLI, which user are you using?
Are you just sourcing the overcloudrc file, or using export OS_CLOUD=overcloud. If that’s the case then you would be using the admin user on the CLI, but probably a different user when logging into Horizon.
I too would suggest opening a support case. It sounds like you have
previously had a negative experience with that. If you want to open a new one and share the case number with me, I can follow up on that for you. As someone who personally knows a lot of the RHOSP Technical Support team from around the world. I’m confident we can right whatever wrong may have occurred there.
Let me know if I can help in any way.
Regards,
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 14 Sep 2022, at 10:36 pm, Albert Braden ozzzo@yahoo.com wrote:
On CLI I can type "openstack port set --no-security-group <ID>" to
remove all security groups. In Horizon, the equivalent operation would be using the - button to remove all groups and then clicking "Update." Using the + button would be the equivalent of typing "openstack port set --security-group <group ID>". There doesn't seem to be a way to remove a single security group via CLI; I think the only way would be to set --no-security-group and then add back the desired groups.
I can successfully add security groups to a port via CLI, or I can
remove all security groups. If I go into Horizon and try these operations then I get the error when I click "Update." So it appears that security groups can be added and removed, with port security set, via CLI. We only see the failure when we try to do it via Horizon.
Regarding RHOSP support; I assume that you are joking, or maybe
haven't experienced the support that they offer.
On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont <
laurentfdumont@gmail.com> wrote:
If you are running RHOSP, you might have a support contract with Red
Hat?
Are you trying to remove all the security groups from a port that
has port_security enabled?
On Tue, Sep 13, 2022 at 11:53 AM Albert Braden ozzzo@yahoo.com
wrote:
Unfortunately we are running RHOSP in which Train is the latest
and greatest. This is what we see in horizon.log:
[Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid
139683266553600] [remote 10.232.233.11:57498] Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau <
pierre@stackhpc.com> wrote:
Hello,
This is more likely to be a Horizon bug than an issue with Kolla
itself, since Kolla doesn't change much from the default configuration.
You should check Horizon logs in /var/log/kolla/horizon to find
the error. I would also encourage you to upgrade to a more recent release, since Train has been marked as End of Life in Kolla recently.
Cheers, Pierre Riteau (priteau)
On Fri, 9 Sept 2022 at 15:41, Albert Braden ozzzo@yahoo.com
wrote:
> We're running kolla train and we're seeing an apparent bug when
we try to add or remove security groups on a port. We see error "Failed to update port <ID>". It works fine in CLI; we only see this in Horizon. Is this a known bug, or are we doing something wrong?
>
Hey all,
I think we might be onto something here. With the help of @Sean Mooney smooney@redhat.com ++ and @Takashi Kajinami tkajinam@redhat.com ++. It appears the API request when sent from Horizon contains additional fields that don't require update. But when the request comes from openstackcli, it is just updating the security group field only.
openstackcli: REQ: curl -g -i --cacert "/Users/shep/.certs/overcloud-cacert.pem" -X PUT https://openstack.bne-home.net:13696/v2.0/ports/4df563ce-5464-4f7d-8aaf-c549... -H "Content-Type: application/json" -H "User-Agent: openstacksdk/0.100.0 keystoneauth1/5.0.0 python-requests/2.28.1 CPython/3.10.6" -H "X-Auth-Token: {SHA256}3ec8b1d0b17434ec67c2960486ec19f17dfb2884fb47c5b54e1cec2beceb1a87" -d '{"port": {"security_groups": ["a3ae6e20-67df-4a72-9d5b-cc21ad87464f", "a31b9954-b7e6-4d4e-887c-e21a59c052ea"]}}' https://openstack.bne-home.net:13696 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" 200 1002
Horizon API call to Neutron: 2022-09-15 00:02:46,820 33 DEBUG neutronclient.client REQ: b'curl -i https://openstack.bne-home.net:13696/v2.0/ports/4df563ce-5464-4f7d-8aaf-c549... -X PUT -H "X-Auth-Token: {SHA256}52f077cf0115286c45f1e212cbec4ecdfc56ae41704c869aeb35cea41fdbfde1" -H "User-Agent: python-neutronclient" -d '{"port": {"name": "", "admin_state_up": true, "port_security_enabled": true, "security_groups": [], "binding:vnic_type": "normal"}}''
So when Neutron receives that request from Horizon, we get blocked because we (as members) are not permitted to update the port_security_enabled field. Even though it's already set to true in this case.
Given that information, the bug is probably back on Horizon here to not include fields that don't require update.
Brendan Shephard
Senior Software Engineer
Red Hat APAC https://www.redhat.com
193 N Quay
Brisbane City QLD 4000 @RedHat https://twitter.com/redhat Red Hat https://www.linkedin.com/company/red-hat Red Hat https://www.facebook.com/RedHatInc https://red.ht/sig https://redhat.com/summit
On Thu, Sep 15, 2022 at 10:46 PM Albert Braden ozzzo@yahoo.com wrote:
If I add/remove security groups from an instance in Horizon, it works. It's when I add/remove security groups from a port that the error occurs. One way to reproduce is to click on the instance and then go to the "Interfaces" tab, and click "Update Security Groups" on the right. On Thursday, September 15, 2022, 08:21:17 AM EDT, Brendan Shephard < bshephar@redhat.com> wrote:
Hey,
I'm doing it from the instances one:
https://openstack.bne-home.net/dashboard/project/instances/ccb72b14-3694-40f...
But for what it's worth. I get the same error if I do it from:
https://openstack.bne-home.net/dashboard/project/networks/acefae53-b4d5-422f...
Interesting that it worked for you there. Be good to confirm with @ozzzo@yahoo.com ozzzo@yahoo.com as well as to exactly where in Horizon he is trying to modify the security groups. Just so we're all trying to do the exact same thing.
My environment is also deployed from the latest tripleo packages, so I'll also test on that internal lab you referenced Sean. That would be more representative of Alberts issue since he is using RHOSP.
Brendan Shephard
Senior Software Engineer
Red Hat APAC https://www.redhat.com
193 N Quay
Brisbane City QLD 4000 @RedHat https://twitter.com/redhat Red Hat https://www.linkedin.com/company/red-hat Red Hat https://www.facebook.com/RedHatInc https://red.ht/sig https://redhat.com/summit
On Thu, Sep 15, 2022 at 10:12 PM Sean Mooney smooney@redhat.com wrote:
On Thu, 2022-09-15 at 21:33 +1000, Brendan Shephard wrote:
Hey Sean,
Thanks for the reply.
For reference, I have all the steps to reproduce along with the relevant debug logs attached to this LP: https://bugs.launchpad.net/neutron/+bug/1989627
But, to summarize. If I go to any random instance in Horizon as a member user - not a admin. Then try to remove any Security Group at all from any of the ports it fails with the policy violation (I attached a screenshot
of
where I'm making that change in Horizon). But doing it with the same user from the cli works fine. Since I'm editing individual interfaces there, rather than the instance itself. I assumed these would all be API calls
to
Neutron from Horizon rather than from Horizon to Nova.
updating the instance securty group will not affect any exsitng ports when you want to add or remvoe security groups form a port in horizont you do not do that via the instace secutity group you do it via the port edit dialog in the port detail view under the network
https://<your cloud goes here>/dashboard/project/networks/ports/<port uuid>/detail
i just did that now on a train cloud we have internally and was able to add and remove a security group on a port.
I just run server list --all to demonstrate I was indeed using a member user and not a admin since an admin would have seen VM's from all
projects.
I agree with you in principle. It should be exactly the same whether it comes from openstackclient or from Horizon. In fact, I was 98% positive I would be able to demonstrate the wrong user was being used in this case. But unfortunately, my efforts to reproduce it demonstrated that the two
are
indeed handled differently.
what page in horizon are you editing it form if i try and add/remove the secirty group via the interfaces tabe at https://<cloud>/dashboard/project/instances/<instance uuid>/ it also work for me inlcuding removing all secuity groups and i am not an admin on this cloud.
specificly this is the redhat internal shared cloud i was testing on.
I believe anyone should be able to reproduce it using the steps I
outlined
on the LP.
Brendan Shephard
Senior Software Engineer
Red Hat APAC https://www.redhat.com
193 N Quay
Brisbane City QLD 4000 @RedHat https://twitter.com/redhat Red Hat https://www.linkedin.com/company/red-hat Red Hat https://www.facebook.com/RedHatInc https://red.ht/sig https://redhat.com/summit
On Thu, Sep 15, 2022 at 8:48 PM Sean Mooney smooney@redhat.com wrote:
On Thu, 2022-09-15 at 08:59 +1000, Brendan Shephard wrote:
Hey Albert,
The policy is the default Neutron policy in OpenStack Train. These
can
indeed be changed and customised, but my assumption is that you haven’t created any custom policies. Horizon uses the default for each service unless it’s been overwritten. policy is defiend server side not client side so it applie equially to
all
users of the api so the behavior will be the same for horizon or the cli if you ever find a delta because horizon say used a differnt token to
make
the request that is a securty vulnerablity in horizon and should be reported privatly to the horizon core team :)
If I create a non-admin user and try to change security groups I also
get the same error:
2022-09-14 22:01:33,370 64 INFO
openstack_dashboard.dashboards.project.networks.ports.workflows Failed
to
update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port
and
rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
And I can reproduce your same scenario ff I try via the CLI using
these
steps:
- Add entry for new user to clouds.yaml file:
bne-home-test: auth: auth_url: https://openstack.bne-home.net:13000 password: "test" project_domain_name: Default project_name: bne-home user_domain_name: Default username: test cacert: ~/.certs/overcloud-cacert.pem identity_api_version: '3' region_name: regionOne volume_api_version: ‘3'
export OS_CLOUD=bne-home-test
Try to remove security group from port:
❯ openstack server show test-lb-net -c security_groups -c addresses
-f
yaml
addresses: lb-mgmt-net:
- 172.24.0.90
vlan4-infra:
- 172.20.13.175
security_groups:
- name: management-bne
the security group listed in nova is the default security group that
will
be used by all port create by nova. it only applie to ports created by nova and not ones that are passed in using the uuid of a precreate port.
you shoudl in general not mix managing security groups via nova and neutron. horizon shoudl prefer to manage security groups only via neutron if it
can.
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c
fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
port_security_enabled: true security_group_ids:
- a3ae6e20-67df-4a72-9d5b-cc21ad87464f
❯ openstack port unset --security-group
a3ae6e20-67df-4a72-9d5b-cc21ad87464f
4df563ce-5464-4f7d-8aaf-c5496cdaefda
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c
fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
port_security_enabled: true security_group_ids: []
Verify that I’m definitely not a admin user: ❯ openstack server list --all Policy doesn't allow os_compute_api:servers:detail:get_all_tenants
to be
performed. (HTTP 403) (Request-ID:
req-75c19210-ad91-471f-b500-e1f3482825f8)
I don’t think this user should be allowed to do that via the CLI
either.
So that could be a bug there. The request in the Neutron server.log
when I
do it via the CLI:
user can add or remove security groups without being and admin
including
removing all securtiy groups thats intended behavior and should not
require
admin.
are you implying that horizon is doing "openstack server list --all"
--all
is short for --all-tenants. outside of the admin tab in horizon horizon would never pass the
equivlent
of --all to the nova api.
2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None
req-f99c4c15-003c-4f7e-9e41-9100daa2a566
781362d053ee4708a21430d3a825795a
3ff28fc7abf742a6b7a0d016771dee49 - - default default] 192.168.1.17,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 len: 1102 time: 0.4449480
VS Horizon: 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None
req-4c284690-eb69-43df-b205-4953a88ab87c
781362d053ee4708a21430d3a825795a
3ff28fc7abf742a6b7a0d016771dee49 - - default default] 172.20.10.25,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 len: 386 time: 0.2209103
I have raised a upstream bug for this since I can still reproduce it
on
the latest version of OpenStack:
https://bugs.launchpad.net/neutron/+bug/1989627%EF%BF%BC Bug #1989627 “Policy enforcement variance between openstackcli a...”
:
Bugs : neutron
bugs.launchpad.net
policy is enfoced on the nova/neutron api it cant behave differntly for horizon unless horizon is useing the wrong token. i.e. not he users token.
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 15 Sep 2022, at 2:25 am, Albert Braden ozzzo@yahoo.com wrote:
Hi Brendan, thanks for offering to help! I'll contact you privately
with info about some languishing cases.
Here's the policy line: "update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
Does this policy only affect Horizon? I'm using the same non-admin
user for both CLI and Horizon, on a project where that user is a
member.
The network was created by the admin user.
On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan
Shephard <
bshephar@redhat.com> wrote:
Hi Albert,
While I may not be the best person to address your Horizon
concern. I
can probably help you with your Red Hat support concerns. If you had
any
issues you wanted addressed, or feedback you wanted to provide. Feel
free
to give me a yell.
Looking at your Horizon issue though. It seems the default policy
file
is what prevents you from updating that port. We can see the default
policy
like this for example:
[root@controller-2 ~]# podman exec -it neutron_api
oslopolicy-policy-generator --namespace neutron | grep "update_port:port_security_enabled"
"update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
When you execute the command via the CLI, which user are you using?
Are you just sourcing the overcloudrc file, or using export OS_CLOUD=overcloud. If that’s the case then you would be using the
admin
user on the CLI, but probably a different user when logging into
Horizon.
I too would suggest opening a support case. It sounds like you have
previously had a negative experience with that. If you want to open a
new
one and share the case number with me, I can follow up on that for
you. As
someone who personally knows a lot of the RHOSP Technical Support team
from
around the world. I’m confident we can right whatever wrong may have occurred there.
Let me know if I can help in any way.
Regards,
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 14 Sep 2022, at 10:36 pm, Albert Braden ozzzo@yahoo.com
wrote:
On CLI I can type "openstack port set --no-security-group <ID>"
to
remove all security groups. In Horizon, the equivalent operation would
be
using the - button to remove all groups and then clicking "Update."
Using
the + button would be the equivalent of typing "openstack port set --security-group <group ID>". There doesn't seem to be a way to remove
a
single security group via CLI; I think the only way would be to set --no-security-group and then add back the desired groups.
I can successfully add security groups to a port via CLI, or I
can
remove all security groups. If I go into Horizon and try these
operations
then I get the error when I click "Update." So it appears that security groups can be added and removed, with port security set, via CLI. We
only
see the failure when we try to do it via Horizon.
Regarding RHOSP support; I assume that you are joking, or maybe
haven't experienced the support that they offer.
On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont <
laurentfdumont@gmail.com> wrote:
If you are running RHOSP, you might have a support contract with
Red
Hat?
Are you trying to remove all the security groups from a port that
has port_security enabled?
On Tue, Sep 13, 2022 at 11:53 AM Albert Braden <ozzzo@yahoo.com
mailto:ozzzo@yahoo.com> wrote:
Unfortunately we are running RHOSP in which Train is the latest
and
greatest. This is what we see in horizon.log:
[Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid
139683266553600] [remote 10.232.233.11:57498 <
http://10.232.233.11:57498/%3E]
Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau <
pierre@stackhpc.com mailto:pierre@stackhpc.com> wrote:
Hello,
This is more likely to be a Horizon bug than an issue with Kolla
itself, since Kolla doesn't change much from the default configuration.
You should check Horizon logs in /var/log/kolla/horizon to find
the
error. I would also encourage you to upgrade to a more recent release, since Train has been marked as End of Life in Kolla recently.
Cheers, Pierre Riteau (priteau)
On Fri, 9 Sept 2022 at 15:41, Albert Braden <ozzzo@yahoo.com
mailto:ozzzo@yahoo.com> wrote:
We're running kolla train and we're seeing an apparent bug when
we
try to add or remove security groups on a port. We see error "Failed to update port <ID>". It works fine in CLI; we only see this in Horizon.
Is
this a known bug, or are we doing something wrong?
Hey Albert,
The policy is the default Neutron policy in OpenStack Train. These
can
indeed be changed and customised, but my assumption is that you haven’t created any custom policies. Horizon uses the default for each service unless it’s been overwritten.
If I create a non-admin user and try to change security groups I also
get the same error:
2022-09-14 22:01:33,370 64 INFO
openstack_dashboard.dashboards.project.networks.ports.workflows Failed
to
update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port
and
rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
And I can reproduce your same scenario ff I try via the CLI using
these
steps:
- Add entry for new user to clouds.yaml file:
bne-home-test: auth: auth_url: https://openstack.bne-home.net:13000 password: "test" project_domain_name: Default project_name: bne-home user_domain_name: Default username: test cacert: ~/.certs/overcloud-cacert.pem identity_api_version: '3' region_name: regionOne volume_api_version: ‘3'
export OS_CLOUD=bne-home-test
Try to remove security group from port:
❯ openstack server show test-lb-net -c security_groups -c addresses
-f
yaml
addresses: lb-mgmt-net:
- 172.24.0.90
vlan4-infra:
- 172.20.13.175
security_groups:
- name: management-bne
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c
fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
port_security_enabled: true security_group_ids:
- a3ae6e20-67df-4a72-9d5b-cc21ad87464f
❯ openstack port unset --security-group
a3ae6e20-67df-4a72-9d5b-cc21ad87464f
4df563ce-5464-4f7d-8aaf-c5496cdaefda
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c
fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
port_security_enabled: true security_group_ids: []
Verify that I’m definitely not a admin user: ❯ openstack server list --all Policy doesn't allow os_compute_api:servers:detail:get_all_tenants
to be
performed. (HTTP 403) (Request-ID:
req-75c19210-ad91-471f-b500-e1f3482825f8)
I don’t think this user should be allowed to do that via the CLI
either.
So that could be a bug there. The request in the Neutron server.log
when I
do it via the CLI:
2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None
req-f99c4c15-003c-4f7e-9e41-9100daa2a566
781362d053ee4708a21430d3a825795a
3ff28fc7abf742a6b7a0d016771dee49 - - default default] 192.168.1.17,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 len: 1102 time: 0.4449480
VS Horizon: 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None
req-4c284690-eb69-43df-b205-4953a88ab87c
781362d053ee4708a21430d3a825795a
3ff28fc7abf742a6b7a0d016771dee49 - - default default] 172.20.10.25,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 len: 386 time: 0.2209103
I have raised a upstream bug for this since I can still reproduce it
on
the latest version of OpenStack:
launchpad-og-image.pngBug #1989627 “Policy enforcement variance
between
openstackcli a...” : Bugs : neutron
bugs.launchpad.net
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 15 Sep 2022, at 2:25 am, Albert Braden ozzzo@yahoo.com wrote:
Hi Brendan, thanks for offering to help! I'll contact you
privately
with info about some languishing cases.
Here's the policy line: "update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
Does this policy only affect Horizon? I'm using the same non-admin
user for both CLI and Horizon, on a project where that user is a
member.
The network was created by the admin user.
On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan
Shephard <
bshephar@redhat.com> wrote:
Hi Albert,
While I may not be the best person to address your Horizon
concern. I
can probably help you with your Red Hat support concerns. If you had
any
issues you wanted addressed, or feedback you wanted to provide. Feel
free
to give me a yell.
Looking at your Horizon issue though. It seems the default policy
file
is what prevents you from updating that port. We can see the default
policy
like this for example:
[root@controller-2 ~]# podman exec -it neutron_api
oslopolicy-policy-generator --namespace neutron | grep "update_port:port_security_enabled"
"update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
When you execute the command via the CLI, which user are you using?
Are you just sourcing the overcloudrc file, or using export OS_CLOUD=overcloud. If that’s the case then you would be using the
admin
user on the CLI, but probably a different user when logging into
Horizon.
I too would suggest opening a support case. It sounds like you have
previously had a negative experience with that. If you want to open a
new
one and share the case number with me, I can follow up on that for
you. As
someone who personally knows a lot of the RHOSP Technical Support team
from
around the world. I’m confident we can right whatever wrong may have occurred there.
Let me know if I can help in any way.
Regards,
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 14 Sep 2022, at 10:36 pm, Albert Braden ozzzo@yahoo.com
wrote:
On CLI I can type "openstack port set --no-security-group <ID>"
to
remove all security groups. In Horizon, the equivalent operation would
be
using the - button to remove all groups and then clicking "Update."
Using
the + button would be the equivalent of typing "openstack port set --security-group <group ID>". There doesn't seem to be a way to remove
a
single security group via CLI; I think the only way would be to set --no-security-group and then add back the desired groups.
I can successfully add security groups to a port via CLI, or I
can
remove all security groups. If I go into Horizon and try these
operations
then I get the error when I click "Update." So it appears that security groups can be added and removed, with port security set, via CLI. We
only
see the failure when we try to do it via Horizon.
Regarding RHOSP support; I assume that you are joking, or maybe
haven't experienced the support that they offer.
On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont
<
laurentfdumont@gmail.com> wrote:
If you are running RHOSP, you might have a support contract with
Red
Hat?
Are you trying to remove all the security groups from a port that
has port_security enabled?
On Tue, Sep 13, 2022 at 11:53 AM Albert Braden ozzzo@yahoo.com
wrote:
> Unfortunately we are running RHOSP in which Train is the
latest
and greatest. This is what we see in horizon.log:
> > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid
139683266553600] [remote 10.232.233.11:57498] Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
> On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau <
pierre@stackhpc.com> wrote:
> > > Hello, > > This is more likely to be a Horizon bug than an issue with
Kolla
itself, since Kolla doesn't change much from the default configuration.
> > You should check Horizon logs in /var/log/kolla/horizon to find
the error. I would also encourage you to upgrade to a more recent
release,
since Train has been marked as End of Life in Kolla recently.
> > Cheers, > Pierre Riteau (priteau) > > On Fri, 9 Sept 2022 at 15:41, Albert Braden ozzzo@yahoo.com
wrote:
> > We're running kolla train and we're seeing an apparent bug
when
we try to add or remove security groups on a port. We see error
"Failed to
update port <ID>". It works fine in CLI; we only see this in Horizon.
Is
this a known bug, or are we doing something wrong?
> >
It's a known problem and there is a patch for it in review for quite some time: https://review.opendev.org/c/openstack/horizon/+/810224
On Thu, Sep 15, 2022 at 3:36 PM Brendan Shephard bshephar@redhat.com wrote:
Hey all,
I think we might be onto something here. With the help of @Sean Mooney smooney@redhat.com ++ and @Takashi Kajinami tkajinam@redhat.com ++. It appears the API request when sent from Horizon contains additional fields that don't require update. But when the request comes from openstackcli, it is just updating the security group field only.
openstackcli: REQ: curl -g -i --cacert "/Users/shep/.certs/overcloud-cacert.pem" -X PUT https://openstack.bne-home.net:13696/v2.0/ports/4df563ce-5464-4f7d-8aaf-c549... -H "Content-Type: application/json" -H "User-Agent: openstacksdk/0.100.0 keystoneauth1/5.0.0 python-requests/2.28.1 CPython/3.10.6" -H "X-Auth-Token: {SHA256}3ec8b1d0b17434ec67c2960486ec19f17dfb2884fb47c5b54e1cec2beceb1a87" -d '{"port": {"security_groups": ["a3ae6e20-67df-4a72-9d5b-cc21ad87464f", "a31b9954-b7e6-4d4e-887c-e21a59c052ea"]}}' https://openstack.bne-home.net:13696 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" 200 1002
Horizon API call to Neutron: 2022-09-15 00:02:46,820 33 DEBUG neutronclient.client REQ: b'curl -i https://openstack.bne-home.net:13696/v2.0/ports/4df563ce-5464-4f7d-8aaf-c549... -X PUT -H "X-Auth-Token: {SHA256}52f077cf0115286c45f1e212cbec4ecdfc56ae41704c869aeb35cea41fdbfde1" -H "User-Agent: python-neutronclient" -d '{"port": {"name": "", "admin_state_up": true, "port_security_enabled": true, "security_groups": [], "binding:vnic_type": "normal"}}''
So when Neutron receives that request from Horizon, we get blocked because we (as members) are not permitted to update the port_security_enabled field. Even though it's already set to true in this case.
Given that information, the bug is probably back on Horizon here to not include fields that don't require update.
Brendan Shephard
Senior Software Engineer
Red Hat APAC https://www.redhat.com
193 N Quay
Brisbane City QLD 4000 @RedHat https://twitter.com/redhat Red Hat https://www.linkedin.com/company/red-hat Red Hat https://www.facebook.com/RedHatInc https://red.ht/sig https://redhat.com/summit
On Thu, Sep 15, 2022 at 10:46 PM Albert Braden ozzzo@yahoo.com wrote:
If I add/remove security groups from an instance in Horizon, it works. It's when I add/remove security groups from a port that the error occurs. One way to reproduce is to click on the instance and then go to the "Interfaces" tab, and click "Update Security Groups" on the right. On Thursday, September 15, 2022, 08:21:17 AM EDT, Brendan Shephard < bshephar@redhat.com> wrote:
Hey,
I'm doing it from the instances one:
https://openstack.bne-home.net/dashboard/project/instances/ccb72b14-3694-40f...
But for what it's worth. I get the same error if I do it from:
https://openstack.bne-home.net/dashboard/project/networks/acefae53-b4d5-422f...
Interesting that it worked for you there. Be good to confirm with @ozzzo@yahoo.com ozzzo@yahoo.com as well as to exactly where in Horizon he is trying to modify the security groups. Just so we're all trying to do the exact same thing.
My environment is also deployed from the latest tripleo packages, so I'll also test on that internal lab you referenced Sean. That would be more representative of Alberts issue since he is using RHOSP.
Brendan Shephard
Senior Software Engineer
Red Hat APAC https://www.redhat.com
193 N Quay
Brisbane City QLD 4000 @RedHat https://twitter.com/redhat Red Hat https://www.linkedin.com/company/red-hat Red Hat https://www.facebook.com/RedHatInc https://red.ht/sig https://redhat.com/summit
On Thu, Sep 15, 2022 at 10:12 PM Sean Mooney smooney@redhat.com wrote:
On Thu, 2022-09-15 at 21:33 +1000, Brendan Shephard wrote:
Hey Sean,
Thanks for the reply.
For reference, I have all the steps to reproduce along with the relevant debug logs attached to this LP: https://bugs.launchpad.net/neutron/+bug/1989627
But, to summarize. If I go to any random instance in Horizon as a member user - not a admin. Then try to remove any Security Group at all from
any
of the ports it fails with the policy violation (I attached a
screenshot of
where I'm making that change in Horizon). But doing it with the same
user
from the cli works fine. Since I'm editing individual interfaces there, rather than the instance itself. I assumed these would all be API calls
to
Neutron from Horizon rather than from Horizon to Nova.
updating the instance securty group will not affect any exsitng ports when you want to add or remvoe security groups form a port in horizont you do not do that via the instace secutity group you do it via the port edit dialog in the port detail view under the network
https://<your cloud goes here>/dashboard/project/networks/ports/<port uuid>/detail
i just did that now on a train cloud we have internally and was able to add and remove a security group on a port.
I just run server list --all to demonstrate I was indeed using a member user and not a admin since an admin would have seen VM's from all
projects.
I agree with you in principle. It should be exactly the same whether it comes from openstackclient or from Horizon. In fact, I was 98% positive
I
would be able to demonstrate the wrong user was being used in this case. But unfortunately, my efforts to reproduce it demonstrated that the two
are
indeed handled differently.
what page in horizon are you editing it form if i try and add/remove the secirty group via the interfaces tabe at https://<cloud>/dashboard/project/instances/<instance uuid>/ it also work for me inlcuding removing all secuity groups and i am not an admin on this cloud.
specificly this is the redhat internal shared cloud i was testing on.
I believe anyone should be able to reproduce it using the steps I
outlined
on the LP.
Brendan Shephard
Senior Software Engineer
Red Hat APAC https://www.redhat.com
193 N Quay
Brisbane City QLD 4000 @RedHat https://twitter.com/redhat Red Hat https://www.linkedin.com/company/red-hat Red Hat https://www.facebook.com/RedHatInc https://red.ht/sig https://redhat.com/summit
On Thu, Sep 15, 2022 at 8:48 PM Sean Mooney smooney@redhat.com wrote:
On Thu, 2022-09-15 at 08:59 +1000, Brendan Shephard wrote:
Hey Albert,
The policy is the default Neutron policy in OpenStack Train. These
can
indeed be changed and customised, but my assumption is that you
haven’t
created any custom policies. Horizon uses the default for each service unless it’s been overwritten. policy is defiend server side not client side so it applie equially
to all
users of the api so the behavior will be the same for horizon or the cli if you ever find a delta because horizon say used a differnt token to
make
the request that is a securty vulnerablity in horizon and should be reported privatly to the horizon core team :)
If I create a non-admin user and try to change security groups I
also
get the same error:
2022-09-14 22:01:33,370 64 INFO
openstack_dashboard.dashboards.project.networks.ports.workflows
Failed to
update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port
and
rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
And I can reproduce your same scenario ff I try via the CLI using
these
steps:
- Add entry for new user to clouds.yaml file:
bne-home-test: auth: auth_url: https://openstack.bne-home.net:13000 password: "test" project_domain_name: Default project_name: bne-home user_domain_name: Default username: test cacert: ~/.certs/overcloud-cacert.pem identity_api_version: '3' region_name: regionOne volume_api_version: ‘3'
export OS_CLOUD=bne-home-test
Try to remove security group from port:
❯ openstack server show test-lb-net -c security_groups -c addresses
-f
yaml
addresses: lb-mgmt-net:
- 172.24.0.90
vlan4-infra:
- 172.20.13.175
security_groups:
- name: management-bne
the security group listed in nova is the default security group that
will
be used by all port create by nova. it only applie to ports created by nova and not ones that are passed
in
using the uuid of a precreate port.
you shoudl in general not mix managing security groups via nova and neutron. horizon shoudl prefer to manage security groups only via neutron if
it can.
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c
fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
port_security_enabled: true security_group_ids:
- a3ae6e20-67df-4a72-9d5b-cc21ad87464f
❯ openstack port unset --security-group
a3ae6e20-67df-4a72-9d5b-cc21ad87464f
4df563ce-5464-4f7d-8aaf-c5496cdaefda
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c
fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
port_security_enabled: true security_group_ids: []
Verify that I’m definitely not a admin user: ❯ openstack server list --all Policy doesn't allow os_compute_api:servers:detail:get_all_tenants
to be
performed. (HTTP 403) (Request-ID:
req-75c19210-ad91-471f-b500-e1f3482825f8)
I don’t think this user should be allowed to do that via the CLI
either.
So that could be a bug there. The request in the Neutron server.log
when I
do it via the CLI:
user can add or remove security groups without being and admin
including
removing all securtiy groups thats intended behavior and should not
require
admin.
are you implying that horizon is doing "openstack server list --all"
--all
is short for --all-tenants. outside of the admin tab in horizon horizon would never pass the
equivlent
of --all to the nova api.
2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None
req-f99c4c15-003c-4f7e-9e41-9100daa2a566
781362d053ee4708a21430d3a825795a
3ff28fc7abf742a6b7a0d016771dee49 - - default default] 192.168.1.17,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 len: 1102 time: 0.4449480
VS Horizon: 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None
req-4c284690-eb69-43df-b205-4953a88ab87c
781362d053ee4708a21430d3a825795a
3ff28fc7abf742a6b7a0d016771dee49 - - default default] 172.20.10.25,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 len: 386 time: 0.2209103
I have raised a upstream bug for this since I can still reproduce
it on
the latest version of OpenStack:
https://bugs.launchpad.net/neutron/+bug/1989627%EF%BF%BC Bug #1989627 “Policy enforcement variance between openstackcli
a...” :
Bugs : neutron
bugs.launchpad.net
policy is enfoced on the nova/neutron api it cant behave differntly
for
horizon unless horizon is useing the wrong token. i.e. not he users token.
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 15 Sep 2022, at 2:25 am, Albert Braden ozzzo@yahoo.com
wrote:
Hi Brendan, thanks for offering to help! I'll contact you
privately
with info about some languishing cases.
Here's the policy line: "update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
Does this policy only affect Horizon? I'm using the same non-admin
user for both CLI and Horizon, on a project where that user is a
member.
The network was created by the admin user.
On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan
Shephard <
bshephar@redhat.com> wrote:
Hi Albert,
While I may not be the best person to address your Horizon
concern. I
can probably help you with your Red Hat support concerns. If you had
any
issues you wanted addressed, or feedback you wanted to provide. Feel
free
to give me a yell.
Looking at your Horizon issue though. It seems the default policy
file
is what prevents you from updating that port. We can see the default
policy
like this for example:
[root@controller-2 ~]# podman exec -it neutron_api
oslopolicy-policy-generator --namespace neutron | grep "update_port:port_security_enabled"
"update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
When you execute the command via the CLI, which user are you
using?
Are you just sourcing the overcloudrc file, or using export OS_CLOUD=overcloud. If that’s the case then you would be using the
admin
user on the CLI, but probably a different user when logging into
Horizon.
I too would suggest opening a support case. It sounds like you
have
previously had a negative experience with that. If you want to open a
new
one and share the case number with me, I can follow up on that for
you. As
someone who personally knows a lot of the RHOSP Technical Support
team from
around the world. I’m confident we can right whatever wrong may have occurred there.
Let me know if I can help in any way.
Regards,
Brendan Shephard Senior Software Engineer Brisbane, Australia
> On 14 Sep 2022, at 10:36 pm, Albert Braden ozzzo@yahoo.com
wrote:
> > On CLI I can type "openstack port set --no-security-group <ID>"
to
remove all security groups. In Horizon, the equivalent operation
would be
using the - button to remove all groups and then clicking "Update."
Using
the + button would be the equivalent of typing "openstack port set --security-group <group ID>". There doesn't seem to be a way to
remove a
single security group via CLI; I think the only way would be to set --no-security-group and then add back the desired groups.
> > I can successfully add security groups to a port via CLI, or I
can
remove all security groups. If I go into Horizon and try these
operations
then I get the error when I click "Update." So it appears that
security
groups can be added and removed, with port security set, via CLI. We
only
see the failure when we try to do it via Horizon.
> > Regarding RHOSP support; I assume that you are joking, or maybe
haven't experienced the support that they offer.
> On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont
<
laurentfdumont@gmail.com> wrote:
> > > If you are running RHOSP, you might have a support contract
with Red
Hat?
> > Are you trying to remove all the security groups from a port
that
has port_security enabled?
> > On Tue, Sep 13, 2022 at 11:53 AM Albert Braden <ozzzo@yahoo.com
mailto:ozzzo@yahoo.com> wrote:
> Unfortunately we are running RHOSP in which Train is the latest
and
greatest. This is what we see in horizon.log:
> > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid
139683266553600] [remote 10.232.233.11:57498 <
http://10.232.233.11:57498/%3E]
Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
> On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau <
pierre@stackhpc.com mailto:pierre@stackhpc.com> wrote:
> > > Hello, > > This is more likely to be a Horizon bug than an issue with Kolla
itself, since Kolla doesn't change much from the default
configuration.
> > You should check Horizon logs in /var/log/kolla/horizon to find
the
error. I would also encourage you to upgrade to a more recent release, since Train has been marked as End of Life in Kolla recently.
> > Cheers, > Pierre Riteau (priteau) > > On Fri, 9 Sept 2022 at 15:41, Albert Braden <ozzzo@yahoo.com
mailto:ozzzo@yahoo.com> wrote:
> We're running kolla train and we're seeing an apparent bug when
we
try to add or remove security groups on a port. We see error "Failed
to
update port <ID>". It works fine in CLI; we only see this in Horizon.
Is
this a known bug, or are we doing something wrong?
>
Hey Albert,
The policy is the default Neutron policy in OpenStack Train. These
can
indeed be changed and customised, but my assumption is that you
haven’t
created any custom policies. Horizon uses the default for each service unless it’s been overwritten.
If I create a non-admin user and try to change security groups I
also
get the same error:
2022-09-14 22:01:33,370 64 INFO
openstack_dashboard.dashboards.project.networks.ports.workflows
Failed to
update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port
and
rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
And I can reproduce your same scenario ff I try via the CLI using
these
steps:
- Add entry for new user to clouds.yaml file:
bne-home-test: auth: auth_url: https://openstack.bne-home.net:13000 password: "test" project_domain_name: Default project_name: bne-home user_domain_name: Default username: test cacert: ~/.certs/overcloud-cacert.pem identity_api_version: '3' region_name: regionOne volume_api_version: ‘3'
export OS_CLOUD=bne-home-test
Try to remove security group from port:
❯ openstack server show test-lb-net -c security_groups -c addresses
-f
yaml
addresses: lb-mgmt-net:
- 172.24.0.90
vlan4-infra:
- 172.20.13.175
security_groups:
- name: management-bne
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c
fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
port_security_enabled: true security_group_ids:
- a3ae6e20-67df-4a72-9d5b-cc21ad87464f
❯ openstack port unset --security-group
a3ae6e20-67df-4a72-9d5b-cc21ad87464f
4df563ce-5464-4f7d-8aaf-c5496cdaefda
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c
fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
port_security_enabled: true security_group_ids: []
Verify that I’m definitely not a admin user: ❯ openstack server list --all Policy doesn't allow os_compute_api:servers:detail:get_all_tenants
to be
performed. (HTTP 403) (Request-ID:
req-75c19210-ad91-471f-b500-e1f3482825f8)
I don’t think this user should be allowed to do that via the CLI
either.
So that could be a bug there. The request in the Neutron server.log
when I
do it via the CLI:
2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None
req-f99c4c15-003c-4f7e-9e41-9100daa2a566
781362d053ee4708a21430d3a825795a
3ff28fc7abf742a6b7a0d016771dee49 - - default default] 192.168.1.17,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 len: 1102 time: 0.4449480
VS Horizon: 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None
req-4c284690-eb69-43df-b205-4953a88ab87c
781362d053ee4708a21430d3a825795a
3ff28fc7abf742a6b7a0d016771dee49 - - default default] 172.20.10.25,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 len: 386 time: 0.2209103
I have raised a upstream bug for this since I can still reproduce
it on
the latest version of OpenStack:
launchpad-og-image.pngBug #1989627 “Policy enforcement variance
between
openstackcli a...” : Bugs : neutron
bugs.launchpad.net
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 15 Sep 2022, at 2:25 am, Albert Braden ozzzo@yahoo.com
wrote:
Hi Brendan, thanks for offering to help! I'll contact you
privately
with info about some languishing cases.
Here's the policy line: "update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
Does this policy only affect Horizon? I'm using the same non-admin
user for both CLI and Horizon, on a project where that user is a
member.
The network was created by the admin user.
On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan
Shephard <
bshephar@redhat.com> wrote:
Hi Albert,
While I may not be the best person to address your Horizon
concern. I
can probably help you with your Red Hat support concerns. If you had
any
issues you wanted addressed, or feedback you wanted to provide. Feel
free
to give me a yell.
Looking at your Horizon issue though. It seems the default policy
file
is what prevents you from updating that port. We can see the default
policy
like this for example:
[root@controller-2 ~]# podman exec -it neutron_api
oslopolicy-policy-generator --namespace neutron | grep "update_port:port_security_enabled"
"update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
When you execute the command via the CLI, which user are you
using?
Are you just sourcing the overcloudrc file, or using export OS_CLOUD=overcloud. If that’s the case then you would be using the
admin
user on the CLI, but probably a different user when logging into
Horizon.
I too would suggest opening a support case. It sounds like you
have
previously had a negative experience with that. If you want to open a
new
one and share the case number with me, I can follow up on that for
you. As
someone who personally knows a lot of the RHOSP Technical Support
team from
around the world. I’m confident we can right whatever wrong may have occurred there.
Let me know if I can help in any way.
Regards,
Brendan Shephard Senior Software Engineer Brisbane, Australia
> On 14 Sep 2022, at 10:36 pm, Albert Braden ozzzo@yahoo.com
wrote:
> > On CLI I can type "openstack port set --no-security-group
<ID>" to
remove all security groups. In Horizon, the equivalent operation
would be
using the - button to remove all groups and then clicking "Update."
Using
the + button would be the equivalent of typing "openstack port set --security-group <group ID>". There doesn't seem to be a way to
remove a
single security group via CLI; I think the only way would be to set --no-security-group and then add back the desired groups.
> > I can successfully add security groups to a port via CLI, or I
can
remove all security groups. If I go into Horizon and try these
operations
then I get the error when I click "Update." So it appears that
security
groups can be added and removed, with port security set, via CLI. We
only
see the failure when we try to do it via Horizon.
> > Regarding RHOSP support; I assume that you are joking, or maybe
haven't experienced the support that they offer.
> On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent
Dumont <
laurentfdumont@gmail.com> wrote:
> > > If you are running RHOSP, you might have a support contract
with Red
Hat?
> > Are you trying to remove all the security groups from a port
that
has port_security enabled?
> > On Tue, Sep 13, 2022 at 11:53 AM Albert Braden <ozzzo@yahoo.com
wrote:
> > Unfortunately we are running RHOSP in which Train is the
latest
and greatest. This is what we see in horizon.log:
> > > > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid
139683266553600] [remote 10.232.233.11:57498] Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
> > On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau
<
pierre@stackhpc.com> wrote:
> > > > > > Hello, > > > > This is more likely to be a Horizon bug than an issue with
Kolla
itself, since Kolla doesn't change much from the default
configuration.
> > > > You should check Horizon logs in /var/log/kolla/horizon to
find
the error. I would also encourage you to upgrade to a more recent
release,
since Train has been marked as End of Life in Kolla recently.
> > > > Cheers, > > Pierre Riteau (priteau) > > > > On Fri, 9 Sept 2022 at 15:41, Albert Braden ozzzo@yahoo.com
wrote:
> > > We're running kolla train and we're seeing an apparent bug
when
we try to add or remove security groups on a port. We see error
"Failed to
update port <ID>". It works fine in CLI; we only see this in Horizon.
Is
this a known bug, or are we doing something wrong?
> > >
Also I see this one that failed to pass Zuul.
https://review.opendev.org/c/openstack/horizon/+/819027/1/openstack_dashboar...
On Thursday, September 15, 2022, 10:34:50 AM EDT, Radomir Dopieralski rdopiera@redhat.com wrote:
It's a known problem and there is a patch for it in review for quite some time: https://review.opendev.org/c/openstack/horizon/+/810224 On Thu, Sep 15, 2022 at 3:36 PM Brendan Shephard bshephar@redhat.com wrote:
Hey all, I think we might be onto something here. With the help of @Sean Mooney ++ and @Takashi Kajinami ++. It appears the API request when sent from Horizon contains additional fields that don't require update. But when the request comes from openstackcli, it is just updating the security group field only. openstackcli:REQ: curl -g -i --cacert "/Users/shep/.certs/overcloud-cacert.pem" -X PUT https://openstack.bne-home.net:13696/v2.0/ports/4df563ce-5464-4f7d-8aaf-c549... -H "Content-Type: application/json" -H "User-Agent: openstacksdk/0.100.0 keystoneauth1/5.0.0 python-requests/2.28.1 CPython/3.10.6" -H "X-Auth-Token: {SHA256}3ec8b1d0b17434ec67c2960486ec19f17dfb2884fb47c5b54e1cec2beceb1a87" -d '{"port": {"security_groups": ["a3ae6e20-67df-4a72-9d5b-cc21ad87464f", "a31b9954-b7e6-4d4e-887c-e21a59c052ea"]}}' https://openstack.bne-home.net:13696 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" 200 1002
Horizon API call to Neutron:2022-09-15 00:02:46,820 33 DEBUG neutronclient.client REQ: b'curl -i https://openstack.bne-home.net:13696/v2.0/ports/4df563ce-5464-4f7d-8aaf-c549... -X PUT -H "X-Auth-Token: {SHA256}52f077cf0115286c45f1e212cbec4ecdfc56ae41704c869aeb35cea41fdbfde1" -H "User-Agent: python-neutronclient" -d '{"port": {"name": "", "admin_state_up": true, "port_security_enabled": true, "security_groups": [], "binding:vnic_type": "normal"}}''
So when Neutron receives that request from Horizon, we get blocked because we (as members) are not permitted to update the port_security_enabled field. Even though it's already set to true in this case. Given that information, the bug is probably back on Horizon here to not include fields that don't require update.
Brendan Shephard
Senior Software Engineer
Red Hat APAC
193 N Quay
Brisbane City QLD 4000 @RedHat Red Hat Red Hat | | |
On Thu, Sep 15, 2022 at 10:46 PM Albert Braden ozzzo@yahoo.com wrote:
If I add/remove security groups from an instance in Horizon, it works. It's when I add/remove security groups from a port that the error occurs. One way to reproduce is to click on the instance and then go to the "Interfaces" tab, and click "Update Security Groups" on the right. On Thursday, September 15, 2022, 08:21:17 AM EDT, Brendan Shephard bshephar@redhat.com wrote:
Hey, I'm doing it from the instances one:https://openstack.bne-home.net/dashboard/project/instances/ccb72b14-3694-40f...
But for what it's worth. I get the same error if I do it from:https://openstack.bne-home.net/dashboard/project/networks/acefae53-b4d5-422f...
Interesting that it worked for you there. Be good to confirm with @ozzzo@yahoo.com as well as to exactly where in Horizon he is trying to modify the security groups. Just so we're all trying to do the exact same thing. My environment is also deployed from the latest tripleo packages, so I'll also test on that internal lab you referenced Sean. That would be more representative of Alberts issue since he is using RHOSP.
Brendan Shephard
Senior Software Engineer
Red Hat APAC
193 N Quay
Brisbane City QLD 4000 @RedHat Red Hat Red Hat | | |
On Thu, Sep 15, 2022 at 10:12 PM Sean Mooney smooney@redhat.com wrote:
On Thu, 2022-09-15 at 21:33 +1000, Brendan Shephard wrote:
Hey Sean,
Thanks for the reply.
For reference, I have all the steps to reproduce along with the relevant debug logs attached to this LP: https://bugs.launchpad.net/neutron/+bug/1989627
But, to summarize. If I go to any random instance in Horizon as a member user - not a admin. Then try to remove any Security Group at all from any of the ports it fails with the policy violation (I attached a screenshot of where I'm making that change in Horizon). But doing it with the same user from the cli works fine. Since I'm editing individual interfaces there, rather than the instance itself. I assumed these would all be API calls to Neutron from Horizon rather than from Horizon to Nova.
updating the instance securty group will not affect any exsitng ports when you want to add or remvoe security groups form a port in horizont you do not do that via the instace secutity group you do it via the port edit dialog in the port detail view under the network
https://<your cloud goes here>/dashboard/project/networks/ports/<port uuid>/detail
i just did that now on a train cloud we have internally and was able to add and remove a security group on a port.
I just run server list --all to demonstrate I was indeed using a member user and not a admin since an admin would have seen VM's from all projects.
I agree with you in principle. It should be exactly the same whether it comes from openstackclient or from Horizon. In fact, I was 98% positive I would be able to demonstrate the wrong user was being used in this case. But unfortunately, my efforts to reproduce it demonstrated that the two are indeed handled differently.
what page in horizon are you editing it form if i try and add/remove the secirty group via the interfaces tabe at https://<cloud>/dashboard/project/instances/<instance uuid>/ it also work for me inlcuding removing all secuity groups and i am not an admin on this cloud.
specificly this is the redhat internal shared cloud i was testing on.
I believe anyone should be able to reproduce it using the steps I outlined on the LP.
Brendan Shephard
Senior Software Engineer
Red Hat APAC https://www.redhat.com
193 N Quay
Brisbane City QLD 4000 @RedHat https://twitter.com/redhat Red Hat https://www.linkedin.com/company/red-hat Red Hat https://www.facebook.com/RedHatInc https://red.ht/sig https://redhat.com/summit
On Thu, Sep 15, 2022 at 8:48 PM Sean Mooney smooney@redhat.com wrote:
On Thu, 2022-09-15 at 08:59 +1000, Brendan Shephard wrote:
Hey Albert,
The policy is the default Neutron policy in OpenStack Train. These can
indeed be changed and customised, but my assumption is that you haven’t created any custom policies. Horizon uses the default for each service unless it’s been overwritten. policy is defiend server side not client side so it applie equially to all users of the api so the behavior will be the same for horizon or the cli if you ever find a delta because horizon say used a differnt token to make the request that is a securty vulnerablity in horizon and should be reported privatly to the horizon core team :)
If I create a non-admin user and try to change security groups I also
get the same error:
2022-09-14 22:01:33,370 64 INFO
openstack_dashboard.dashboards.project.networks.ports.workflows Failed to update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
And I can reproduce your same scenario ff I try via the CLI using these
steps:
- Add entry for new user to clouds.yaml file:
bne-home-test: auth: auth_url: https://openstack.bne-home.net:13000 password: "test" project_domain_name: Default project_name: bne-home user_domain_name: Default username: test cacert: ~/.certs/overcloud-cacert.pem identity_api_version: '3' region_name: regionOne volume_api_version: ‘3'
export OS_CLOUD=bne-home-test
Try to remove security group from port:
❯ openstack server show test-lb-net -c security_groups -c addresses -f
yaml
addresses: lb-mgmt-net: - 172.24.0.90 vlan4-infra: - 172.20.13.175 security_groups:
- name: management-bne
the security group listed in nova is the default security group that will be used by all port create by nova. it only applie to ports created by nova and not ones that are passed in using the uuid of a precreate port.
you shoudl in general not mix managing security groups via nova and neutron. horizon shoudl prefer to manage security groups only via neutron if it can.
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175
subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 port_security_enabled: true security_group_ids:
- a3ae6e20-67df-4a72-9d5b-cc21ad87464f
❯ openstack port unset --security-group
a3ae6e20-67df-4a72-9d5b-cc21ad87464f 4df563ce-5464-4f7d-8aaf-c5496cdaefda
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175
subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 port_security_enabled: true security_group_ids: []
Verify that I’m definitely not a admin user: ❯ openstack server list --all Policy doesn't allow os_compute_api:servers:detail:get_all_tenants to be
performed. (HTTP 403) (Request-ID: req-75c19210-ad91-471f-b500-e1f3482825f8)
I don’t think this user should be allowed to do that via the CLI either.
So that could be a bug there. The request in the Neutron server.log when I do it via the CLI:
user can add or remove security groups without being and admin including removing all securtiy groups thats intended behavior and should not require admin.
are you implying that horizon is doing "openstack server list --all" --all is short for --all-tenants. outside of the admin tab in horizon horizon would never pass the equivlent of --all to the nova api.
2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None
req-f99c4c15-003c-4f7e-9e41-9100daa2a566 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 192.168.1.17,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 len: 1102 time: 0.4449480
VS Horizon: 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None
req-4c284690-eb69-43df-b205-4953a88ab87c 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 172.20.10.25,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 len: 386 time: 0.2209103
I have raised a upstream bug for this since I can still reproduce it on
the latest version of OpenStack:
https://bugs.launchpad.net/neutron/+bug/1989627%EF%BF%BC Bug #1989627 “Policy enforcement variance between openstackcli a...” :
Bugs : neutron
bugs.launchpad.net
policy is enfoced on the nova/neutron api it cant behave differntly for horizon unless horizon is useing the wrong token. i.e. not he users token.
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 15 Sep 2022, at 2:25 am, Albert Braden ozzzo@yahoo.com wrote:
Hi Brendan, thanks for offering to help! I'll contact you privately
with info about some languishing cases.
Here's the policy line: "update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
Does this policy only affect Horizon? I'm using the same non-admin
user for both CLI and Horizon, on a project where that user is a member. The network was created by the admin user.
On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard <
bshephar@redhat.com> wrote:
Hi Albert,
While I may not be the best person to address your Horizon concern. I
can probably help you with your Red Hat support concerns. If you had any issues you wanted addressed, or feedback you wanted to provide. Feel free to give me a yell.
Looking at your Horizon issue though. It seems the default policy file
is what prevents you from updating that port. We can see the default policy like this for example:
[root@controller-2 ~]# podman exec -it neutron_api
oslopolicy-policy-generator --namespace neutron | grep "update_port:port_security_enabled"
"update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
When you execute the command via the CLI, which user are you using?
Are you just sourcing the overcloudrc file, or using export OS_CLOUD=overcloud. If that’s the case then you would be using the admin user on the CLI, but probably a different user when logging into Horizon.
I too would suggest opening a support case. It sounds like you have
previously had a negative experience with that. If you want to open a new one and share the case number with me, I can follow up on that for you. As someone who personally knows a lot of the RHOSP Technical Support team from around the world. I’m confident we can right whatever wrong may have occurred there.
Let me know if I can help in any way.
Regards,
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 14 Sep 2022, at 10:36 pm, Albert Braden ozzzo@yahoo.com wrote:
On CLI I can type "openstack port set --no-security-group <ID>" to
remove all security groups. In Horizon, the equivalent operation would be using the - button to remove all groups and then clicking "Update." Using the + button would be the equivalent of typing "openstack port set --security-group <group ID>". There doesn't seem to be a way to remove a single security group via CLI; I think the only way would be to set --no-security-group and then add back the desired groups.
I can successfully add security groups to a port via CLI, or I can
remove all security groups. If I go into Horizon and try these operations then I get the error when I click "Update." So it appears that security groups can be added and removed, with port security set, via CLI. We only see the failure when we try to do it via Horizon.
Regarding RHOSP support; I assume that you are joking, or maybe
haven't experienced the support that they offer.
On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont <
laurentfdumont@gmail.com> wrote:
If you are running RHOSP, you might have a support contract with Red
Hat?
Are you trying to remove all the security groups from a port that
has port_security enabled?
On Tue, Sep 13, 2022 at 11:53 AM Albert Braden <ozzzo@yahoo.com
mailto:ozzzo@yahoo.com> wrote:
Unfortunately we are running RHOSP in which Train is the latest and
greatest. This is what we see in horizon.log:
[Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid
139683266553600] [remote 10.232.233.11:57498 http://10.232.233.11:57498/] Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau <
pierre@stackhpc.com mailto:pierre@stackhpc.com> wrote:
Hello,
This is more likely to be a Horizon bug than an issue with Kolla
itself, since Kolla doesn't change much from the default configuration.
You should check Horizon logs in /var/log/kolla/horizon to find the
error. I would also encourage you to upgrade to a more recent release, since Train has been marked as End of Life in Kolla recently.
Cheers, Pierre Riteau (priteau)
On Fri, 9 Sept 2022 at 15:41, Albert Braden <ozzzo@yahoo.com
mailto:ozzzo@yahoo.com> wrote:
We're running kolla train and we're seeing an apparent bug when we
try to add or remove security groups on a port. We see error "Failed to update port <ID>". It works fine in CLI; we only see this in Horizon. Is this a known bug, or are we doing something wrong?
Hey Albert,
The policy is the default Neutron policy in OpenStack Train. These can
indeed be changed and customised, but my assumption is that you haven’t created any custom policies. Horizon uses the default for each service unless it’s been overwritten.
If I create a non-admin user and try to change security groups I also
get the same error:
2022-09-14 22:01:33,370 64 INFO
openstack_dashboard.dashboards.project.networks.ports.workflows Failed to update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
And I can reproduce your same scenario ff I try via the CLI using these
steps:
- Add entry for new user to clouds.yaml file:
bne-home-test: auth: auth_url: https://openstack.bne-home.net:13000 password: "test" project_domain_name: Default project_name: bne-home user_domain_name: Default username: test cacert: ~/.certs/overcloud-cacert.pem identity_api_version: '3' region_name: regionOne volume_api_version: ‘3'
export OS_CLOUD=bne-home-test
Try to remove security group from port:
❯ openstack server show test-lb-net -c security_groups -c addresses -f
yaml
addresses: lb-mgmt-net: - 172.24.0.90 vlan4-infra: - 172.20.13.175 security_groups:
- name: management-bne
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175
subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 port_security_enabled: true security_group_ids:
- a3ae6e20-67df-4a72-9d5b-cc21ad87464f
❯ openstack port unset --security-group
a3ae6e20-67df-4a72-9d5b-cc21ad87464f 4df563ce-5464-4f7d-8aaf-c5496cdaefda
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175
subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 port_security_enabled: true security_group_ids: []
Verify that I’m definitely not a admin user: ❯ openstack server list --all Policy doesn't allow os_compute_api:servers:detail:get_all_tenants to be
performed. (HTTP 403) (Request-ID: req-75c19210-ad91-471f-b500-e1f3482825f8)
I don’t think this user should be allowed to do that via the CLI either.
So that could be a bug there. The request in the Neutron server.log when I do it via the CLI:
2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None
req-f99c4c15-003c-4f7e-9e41-9100daa2a566 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 192.168.1.17,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 len: 1102 time: 0.4449480
VS Horizon: 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None
req-4c284690-eb69-43df-b205-4953a88ab87c 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 172.20.10.25,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 len: 386 time: 0.2209103
I have raised a upstream bug for this since I can still reproduce it on
the latest version of OpenStack:
launchpad-og-image.pngBug #1989627 “Policy enforcement variance between
openstackcli a...” : Bugs : neutron
bugs.launchpad.net
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 15 Sep 2022, at 2:25 am, Albert Braden ozzzo@yahoo.com wrote:
Hi Brendan, thanks for offering to help! I'll contact you privately
with info about some languishing cases.
Here's the policy line: "update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
Does this policy only affect Horizon? I'm using the same non-admin
user for both CLI and Horizon, on a project where that user is a member. The network was created by the admin user.
On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard <
bshephar@redhat.com> wrote:
Hi Albert,
While I may not be the best person to address your Horizon concern. I
can probably help you with your Red Hat support concerns. If you had any issues you wanted addressed, or feedback you wanted to provide. Feel free to give me a yell.
Looking at your Horizon issue though. It seems the default policy file
is what prevents you from updating that port. We can see the default policy like this for example:
[root@controller-2 ~]# podman exec -it neutron_api
oslopolicy-policy-generator --namespace neutron | grep "update_port:port_security_enabled"
"update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
When you execute the command via the CLI, which user are you using?
Are you just sourcing the overcloudrc file, or using export OS_CLOUD=overcloud. If that’s the case then you would be using the admin user on the CLI, but probably a different user when logging into Horizon.
I too would suggest opening a support case. It sounds like you have
previously had a negative experience with that. If you want to open a new one and share the case number with me, I can follow up on that for you. As someone who personally knows a lot of the RHOSP Technical Support team from around the world. I’m confident we can right whatever wrong may have occurred there.
Let me know if I can help in any way.
Regards,
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 14 Sep 2022, at 10:36 pm, Albert Braden ozzzo@yahoo.com wrote:
On CLI I can type "openstack port set --no-security-group <ID>" to
remove all security groups. In Horizon, the equivalent operation would be using the - button to remove all groups and then clicking "Update." Using the + button would be the equivalent of typing "openstack port set --security-group <group ID>". There doesn't seem to be a way to remove a single security group via CLI; I think the only way would be to set --no-security-group and then add back the desired groups.
I can successfully add security groups to a port via CLI, or I can
remove all security groups. If I go into Horizon and try these operations then I get the error when I click "Update." So it appears that security groups can be added and removed, with port security set, via CLI. We only see the failure when we try to do it via Horizon.
Regarding RHOSP support; I assume that you are joking, or maybe
haven't experienced the support that they offer.
On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont <
laurentfdumont@gmail.com> wrote:
If you are running RHOSP, you might have a support contract with Red
Hat?
Are you trying to remove all the security groups from a port that
has port_security enabled?
On Tue, Sep 13, 2022 at 11:53 AM Albert Braden ozzzo@yahoo.com
wrote:
Unfortunately we are running RHOSP in which Train is the latest
and greatest. This is what we see in horizon.log:
[Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid
139683266553600] [remote 10.232.233.11:57498] Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau <
pierre@stackhpc.com> wrote:
Hello,
This is more likely to be a Horizon bug than an issue with Kolla
itself, since Kolla doesn't change much from the default configuration.
You should check Horizon logs in /var/log/kolla/horizon to find
the error. I would also encourage you to upgrade to a more recent release, since Train has been marked as End of Life in Kolla recently.
Cheers, Pierre Riteau (priteau)
On Fri, 9 Sept 2022 at 15:41, Albert Braden ozzzo@yahoo.com
wrote:
> We're running kolla train and we're seeing an apparent bug when
we try to add or remove security groups on a port. We see error "Failed to update port <ID>". It works fine in CLI; we only see this in Horizon. Is this a known bug, or are we doing something wrong?
>
Hey Radomir,
Thanks for your input. I did indeed find that patch and used it to patch my env. In this case though, it didn’t seem to change the API request sent to Neutron. It seems the issue comes from here:
https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboa... horizon/workflows.py at master · openstack/horizon github.com
If I log the data variable at that point after applying the patch. It contains all of the fields:
2022-09-16 00:01:55,046 35 INFO openstack_dashboard.dashboards.project.networks.ports.workflows bshephar - Data variable = {'port_id': '4df563ce-5464-4f7d-8aaf-c5496cdaefda', 'network_id': 'acefae53-b4d5-422f-bcca-dc32a0785d21', 'name': '', 'admin_state': True, 'target_tenant_id': '3ff28fc7abf742a6b7a0d016771dee49', 'binding__vnic_type': 'normal', 'port_security_enabled': True, 'instance_id': 'ccb72b14-3694-40fa-9b3b-ec1a8d7ef046', 'mac_state': None, 'wanted_groups': ['a3ae6e20-67df-4a72-9d5b-cc21ad87464f']}
So checking if data['port_security_enabled'] is not None: params['port_security_enabled'] = data['port_security_enabled']
This is still True, so we’re setting the param to the data value and using that in our API call to Neutron.
I’m really not familiar at all with the Horizon code base. So let me know if I’m misunderstanding the intention of the patch you referenced. But I think the idea would be to check our `params` against the actual value returned from neutron.port_get() and only have fields that are changed in our params. So when we call the port_update() here: https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboa... horizon/workflows.py at master · openstack/horizon github.com
It would only be the called with params that are different from the current state.
At least in the case we’re discussing here, that resolves the issue. So this is just rudimentary hackery to see what works, but this fixes the issue for me (Ignore the LOG line obviously):
❯ diff horizon/openstack_dashboard/dashboards/project/networks/ports/workflows.py workflows.py 411c411 < params = self._construct_parameters(data) ---
params = self._construct_parameters(request, data)
420c420 < def _construct_parameters(self, data): ---
def _construct_parameters(self, request, data):
424a425,426
LOG.info("bshephar - Data variable = %s", data) initial = api.neutron.port_get(request, self.context['port_id'])
431c433,434 < if data['port_security_enabled'] is not None: ---
if (data['port_security_enabled'] is not None and data['port_security_enabled'] != initial['port_security_enabled']):
The API call after this change looks like this:
2022-09-16 00:17:49,147 31 DEBUG neutronclient.client REQ: b'curl -i https://openstack.bne-home.net:13696/v2.0/ports/4df563ce-5464-4f7d-8aaf-c549... -X PUT -H "X-Auth-Token: {SHA256}65efff6982c871ae21a157ab46e4e2bebf69fc8619e8a1512d7ce0dd96b94369" -H "User-Agent: python-neutronclient" -d '{"port": {"name": "", "admin_state_up": true, "security_groups": ["a3ae6e20-67df-4a72-9d5b-cc21ad87464f"], "binding:vnic_type": "normal"}}''
And subsequently is accepted by Neutron. So I’m not too sure about the approach within your existing framework. But I mean, I’m happy to propose exactly that as a solution and we can debate it further if you like Radomir?
Thanks again,
Brendan Shephard Senior Software Engineer Brisbane, Australia
On 15 Sep 2022, at 11:56 pm, Radomir Dopieralski rdopiera@redhat.com wrote:
It's a known problem and there is a patch for it in review for quite some time: https://review.opendev.org/c/openstack/horizon/+/810224
On Thu, Sep 15, 2022 at 3:36 PM Brendan Shephard <bshephar@redhat.com mailto:bshephar@redhat.com> wrote:
Hey all,
I think we might be onto something here. With the help of @Sean Mooney mailto:smooney@redhat.com ++ and @Takashi Kajinami mailto:tkajinam@redhat.com ++. It appears the API request when sent from Horizon contains additional fields that don't require update. But when the request comes from openstackcli, it is just updating the security group field only.
openstackcli: REQ: curl -g -i --cacert "/Users/shep/.certs/overcloud-cacert.pem" -X PUT https://openstack.bne-home.net:13696/v2.0/ports/4df563ce-5464-4f7d-8aaf-c549... -H "Content-Type: application/json" -H "User-Agent: openstacksdk/0.100.0 keystoneauth1/5.0.0 python-requests/2.28.1 CPython/3.10.6" -H "X-Auth-Token: {SHA256}3ec8b1d0b17434ec67c2960486ec19f17dfb2884fb47c5b54e1cec2beceb1a87" -d '{"port": {"security_groups": ["a3ae6e20-67df-4a72-9d5b-cc21ad87464f", "a31b9954-b7e6-4d4e-887c-e21a59c052ea"]}}' https://openstack.bne-home.net:13696 https://openstack.bne-home.net:13696/ "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" 200 1002
Horizon API call to Neutron: 2022-09-15 00:02:46,820 33 DEBUG neutronclient.client REQ: b'curl -i https://openstack.bne-home.net:13696/v2.0/ports/4df563ce-5464-4f7d-8aaf-c549... -X PUT -H "X-Auth-Token: {SHA256}52f077cf0115286c45f1e212cbec4ecdfc56ae41704c869aeb35cea41fdbfde1" -H "User-Agent: python-neutronclient" -d '{"port": {"name": "", "admin_state_up": true, "port_security_enabled": true, "security_groups": [], "binding:vnic_type": "normal"}}''
So when Neutron receives that request from Horizon, we get blocked because we (as members) are not permitted to update the port_security_enabled field. Even though it's already set to true in this case.
Given that information, the bug is probably back on Horizon here to not include fields that don't require update.
Brendan Shephard Senior Software Engineer Red Hat APAC https://www.redhat.com/ 193 N Quay Brisbane City QLD 4000 @RedHat https://twitter.com/redhat Red Hat https://www.linkedin.com/company/red-hat Red Hat https://www.facebook.com/RedHatInc https://red.ht/sig https://redhat.com/summit
On Thu, Sep 15, 2022 at 10:46 PM Albert Braden <ozzzo@yahoo.com mailto:ozzzo@yahoo.com> wrote:
If I add/remove security groups from an instance in Horizon, it works. It's when I add/remove security groups from a port that the error occurs. One way to reproduce is to click on the instance and then go to the "Interfaces" tab, and click "Update Security Groups" on the right. On Thursday, September 15, 2022, 08:21:17 AM EDT, Brendan Shephard <bshephar@redhat.com mailto:bshephar@redhat.com> wrote:
Hey,
I'm doing it from the instances one: https://openstack.bne-home.net/dashboard/project/instances/ccb72b14-3694-40f...
But for what it's worth. I get the same error if I do it from: https://openstack.bne-home.net/dashboard/project/networks/acefae53-b4d5-422f...
Interesting that it worked for you there. Be good to confirm with @ozzzo@yahoo.com mailto:ozzzo@yahoo.com as well as to exactly where in Horizon he is trying to modify the security groups. Just so we're all trying to do the exact same thing.
My environment is also deployed from the latest tripleo packages, so I'll also test on that internal lab you referenced Sean. That would be more representative of Alberts issue since he is using RHOSP.
Brendan Shephard Senior Software Engineer Red Hat APAC https://www.redhat.com/ 193 N Quay Brisbane City QLD 4000 @RedHat https://twitter.com/redhat Red Hat https://www.linkedin.com/company/red-hat Red Hat https://www.facebook.com/RedHatInc https://red.ht/sig https://redhat.com/summit
On Thu, Sep 15, 2022 at 10:12 PM Sean Mooney <smooney@redhat.com mailto:smooney@redhat.com> wrote: On Thu, 2022-09-15 at 21:33 +1000, Brendan Shephard wrote:
Hey Sean,
Thanks for the reply.
For reference, I have all the steps to reproduce along with the relevant debug logs attached to this LP: https://bugs.launchpad.net/neutron/+bug/1989627
But, to summarize. If I go to any random instance in Horizon as a member user - not a admin. Then try to remove any Security Group at all from any of the ports it fails with the policy violation (I attached a screenshot of where I'm making that change in Horizon). But doing it with the same user from the cli works fine. Since I'm editing individual interfaces there, rather than the instance itself. I assumed these would all be API calls to Neutron from Horizon rather than from Horizon to Nova.
updating the instance securty group will not affect any exsitng ports when you want to add or remvoe security groups form a port in horizont you do not do that via the instace secutity group you do it via the port edit dialog in the port detail view under the network
https://<your cloud goes here>/dashboard/project/networks/ports/<port uuid>/detail
i just did that now on a train cloud we have internally and was able to add and remove a security group on a port.
I just run server list --all to demonstrate I was indeed using a member user and not a admin since an admin would have seen VM's from all projects.
I agree with you in principle. It should be exactly the same whether it comes from openstackclient or from Horizon. In fact, I was 98% positive I would be able to demonstrate the wrong user was being used in this case. But unfortunately, my efforts to reproduce it demonstrated that the two are indeed handled differently.
what page in horizon are you editing it form if i try and add/remove the secirty group via the interfaces tabe at https://<cloud>/dashboard/project/instances/<instance uuid>/ it also work for me inlcuding removing all secuity groups and i am not an admin on this cloud.
specificly this is the redhat internal shared cloud i was testing on.
I believe anyone should be able to reproduce it using the steps I outlined on the LP.
Brendan Shephard
Senior Software Engineer
Red Hat APAC <https://www.redhat.com https://www.redhat.com/>
193 N Quay
Brisbane City QLD 4000 @RedHat https://twitter.com/redhat Red Hat https://www.linkedin.com/company/red-hat Red Hat https://www.facebook.com/RedHatInc https://red.ht/sig https://redhat.com/summit
On Thu, Sep 15, 2022 at 8:48 PM Sean Mooney <smooney@redhat.com mailto:smooney@redhat.com> wrote:
On Thu, 2022-09-15 at 08:59 +1000, Brendan Shephard wrote:
Hey Albert,
The policy is the default Neutron policy in OpenStack Train. These can
indeed be changed and customised, but my assumption is that you haven’t created any custom policies. Horizon uses the default for each service unless it’s been overwritten. policy is defiend server side not client side so it applie equially to all users of the api so the behavior will be the same for horizon or the cli if you ever find a delta because horizon say used a differnt token to make the request that is a securty vulnerablity in horizon and should be reported privatly to the horizon core team :)
If I create a non-admin user and try to change security groups I also
get the same error:
2022-09-14 22:01:33,370 64 INFO
openstack_dashboard.dashboards.project.networks.ports.workflows Failed to update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
And I can reproduce your same scenario ff I try via the CLI using these
steps:
- Add entry for new user to clouds.yaml file:
bne-home-test: auth: auth_url: https://openstack.bne-home.net:13000 https://openstack.bne-home.net:13000/ password: "test" project_domain_name: Default project_name: bne-home user_domain_name: Default username: test cacert: ~/.certs/overcloud-cacert.pem identity_api_version: '3' region_name: regionOne volume_api_version: ‘3'
export OS_CLOUD=bne-home-test
Try to remove security group from port:
❯ openstack server show test-lb-net -c security_groups -c addresses -f
yaml
addresses: lb-mgmt-net:
- 172.24.0.90
vlan4-infra:
- 172.20.13.175
security_groups:
- name: management-bne
the security group listed in nova is the default security group that will be used by all port create by nova. it only applie to ports created by nova and not ones that are passed in using the uuid of a precreate port.
you shoudl in general not mix managing security groups via nova and neutron. horizon shoudl prefer to manage security groups only via neutron if it can.
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
port_security_enabled: true security_group_ids:
- a3ae6e20-67df-4a72-9d5b-cc21ad87464f
❯ openstack port unset --security-group
a3ae6e20-67df-4a72-9d5b-cc21ad87464f 4df563ce-5464-4f7d-8aaf-c5496cdaefda
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
port_security_enabled: true security_group_ids: []
Verify that I’m definitely not a admin user: ❯ openstack server list --all Policy doesn't allow os_compute_api:servers:detail:get_all_tenants to be
performed. (HTTP 403) (Request-ID: req-75c19210-ad91-471f-b500-e1f3482825f8)
I don’t think this user should be allowed to do that via the CLI either.
So that could be a bug there. The request in the Neutron server.log when I do it via the CLI:
user can add or remove security groups without being and admin including removing all securtiy groups thats intended behavior and should not require admin.
are you implying that horizon is doing "openstack server list --all" --all is short for --all-tenants. outside of the admin tab in horizon horizon would never pass the equivlent of --all to the nova api.
2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None
req-f99c4c15-003c-4f7e-9e41-9100daa2a566 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 192.168.1.17,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 len: 1102 time: 0.4449480
VS Horizon: 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None
req-4c284690-eb69-43df-b205-4953a88ab87c 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 172.20.10.25,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 len: 386 time: 0.2209103
I have raised a upstream bug for this since I can still reproduce it on
the latest version of OpenStack:
https://bugs.launchpad.net/neutron/+bug/1989627%EF%BF%BC Bug #1989627 “Policy enforcement variance between openstackcli a...” :
Bugs : neutron
bugs.launchpad.net http://bugs.launchpad.net/
policy is enfoced on the nova/neutron api it cant behave differntly for horizon unless horizon is useing the wrong token. i.e. not he users token.
Brendan Shephard Senior Software Engineer Brisbane, Australia
> On 15 Sep 2022, at 2:25 am, Albert Braden <ozzzo@yahoo.com mailto:ozzzo@yahoo.com> wrote: > > Hi Brendan, thanks for offering to help! I'll contact you privately
with info about some languishing cases.
> > Here's the policy line: > "update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
> > Does this policy only affect Horizon? I'm using the same non-admin
user for both CLI and Horizon, on a project where that user is a member. The network was created by the admin user.
> On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard <
bshephar@redhat.com mailto:bshephar@redhat.com> wrote:
> > > Hi Albert, > > While I may not be the best person to address your Horizon concern. I
can probably help you with your Red Hat support concerns. If you had any issues you wanted addressed, or feedback you wanted to provide. Feel free to give me a yell.
> > Looking at your Horizon issue though. It seems the default policy file
is what prevents you from updating that port. We can see the default policy like this for example:
> > [root@controller-2 ~]# podman exec -it neutron_api
oslopolicy-policy-generator --namespace neutron | grep "update_port:port_security_enabled"
> "update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
> > When you execute the command via the CLI, which user are you using?
Are you just sourcing the overcloudrc file, or using export OS_CLOUD=overcloud. If that’s the case then you would be using the admin user on the CLI, but probably a different user when logging into Horizon.
> > I too would suggest opening a support case. It sounds like you have
previously had a negative experience with that. If you want to open a new one and share the case number with me, I can follow up on that for you. As someone who personally knows a lot of the RHOSP Technical Support team from around the world. I’m confident we can right whatever wrong may have occurred there.
> > Let me know if I can help in any way. > > Regards, > > Brendan Shephard > Senior Software Engineer > Brisbane, Australia > > > > > On 14 Sep 2022, at 10:36 pm, Albert Braden <ozzzo@yahoo.com mailto:ozzzo@yahoo.com> wrote: > > > > On CLI I can type "openstack port set --no-security-group <ID>" to
remove all security groups. In Horizon, the equivalent operation would be using the - button to remove all groups and then clicking "Update." Using the + button would be the equivalent of typing "openstack port set --security-group <group ID>". There doesn't seem to be a way to remove a single security group via CLI; I think the only way would be to set --no-security-group and then add back the desired groups.
> > > > I can successfully add security groups to a port via CLI, or I can
remove all security groups. If I go into Horizon and try these operations then I get the error when I click "Update." So it appears that security groups can be added and removed, with port security set, via CLI. We only see the failure when we try to do it via Horizon.
> > > > Regarding RHOSP support; I assume that you are joking, or maybe
haven't experienced the support that they offer.
> > On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont <
laurentfdumont@gmail.com mailto:laurentfdumont@gmail.com> wrote:
> > > > > > If you are running RHOSP, you might have a support contract with Red
Hat?
> > > > Are you trying to remove all the security groups from a port that
has port_security enabled?
> > > > On Tue, Sep 13, 2022 at 11:53 AM Albert Braden <ozzzo@yahoo.com mailto:ozzzo@yahoo.com
<mailto:ozzzo@yahoo.com mailto:ozzzo@yahoo.com>> wrote:
> > Unfortunately we are running RHOSP in which Train is the latest and
greatest. This is what we see in horizon.log:
> > > > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid
139683266553600] [remote 10.232.233.11:57498 http://10.232.233.11:57498/ http://10.232.233.11:57498/] Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
> > On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau <
pierre@stackhpc.com mailto:pierre@stackhpc.com <mailto:pierre@stackhpc.com mailto:pierre@stackhpc.com>> wrote:
> > > > > > Hello, > > > > This is more likely to be a Horizon bug than an issue with Kolla
itself, since Kolla doesn't change much from the default configuration.
> > > > You should check Horizon logs in /var/log/kolla/horizon to find the
error. I would also encourage you to upgrade to a more recent release, since Train has been marked as End of Life in Kolla recently.
> > > > Cheers, > > Pierre Riteau (priteau) > > > > On Fri, 9 Sept 2022 at 15:41, Albert Braden <ozzzo@yahoo.com mailto:ozzzo@yahoo.com
<mailto:ozzzo@yahoo.com mailto:ozzzo@yahoo.com>> wrote:
> > We're running kolla train and we're seeing an apparent bug when we
try to add or remove security groups on a port. We see error "Failed to update port <ID>". It works fine in CLI; we only see this in Horizon. Is this a known bug, or are we doing something wrong?
> > >
Hey Albert,
The policy is the default Neutron policy in OpenStack Train. These can
indeed be changed and customised, but my assumption is that you haven’t created any custom policies. Horizon uses the default for each service unless it’s been overwritten.
If I create a non-admin user and try to change security groups I also
get the same error:
2022-09-14 22:01:33,370 64 INFO
openstack_dashboard.dashboards.project.networks.ports.workflows Failed to update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
And I can reproduce your same scenario ff I try via the CLI using these
steps:
- Add entry for new user to clouds.yaml file:
bne-home-test: auth: auth_url: https://openstack.bne-home.net:13000 https://openstack.bne-home.net:13000/ password: "test" project_domain_name: Default project_name: bne-home user_domain_name: Default username: test cacert: ~/.certs/overcloud-cacert.pem identity_api_version: '3' region_name: regionOne volume_api_version: ‘3'
export OS_CLOUD=bne-home-test
Try to remove security group from port:
❯ openstack server show test-lb-net -c security_groups -c addresses -f
yaml
addresses: lb-mgmt-net:
- 172.24.0.90
vlan4-infra:
- 172.20.13.175
security_groups:
- name: management-bne
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
port_security_enabled: true security_group_ids:
- a3ae6e20-67df-4a72-9d5b-cc21ad87464f
❯ openstack port unset --security-group
a3ae6e20-67df-4a72-9d5b-cc21ad87464f 4df563ce-5464-4f7d-8aaf-c5496cdaefda
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
port_security_enabled: true security_group_ids: []
Verify that I’m definitely not a admin user: ❯ openstack server list --all Policy doesn't allow os_compute_api:servers:detail:get_all_tenants to be
performed. (HTTP 403) (Request-ID: req-75c19210-ad91-471f-b500-e1f3482825f8)
I don’t think this user should be allowed to do that via the CLI either.
So that could be a bug there. The request in the Neutron server.log when I do it via the CLI:
2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None
req-f99c4c15-003c-4f7e-9e41-9100daa2a566 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 192.168.1.17,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 len: 1102 time: 0.4449480
VS Horizon: 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None
req-4c284690-eb69-43df-b205-4953a88ab87c 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 172.20.10.25,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 len: 386 time: 0.2209103
I have raised a upstream bug for this since I can still reproduce it on
the latest version of OpenStack:
launchpad-og-image.pngBug #1989627 “Policy enforcement variance between
openstackcli a...” : Bugs : neutron
bugs.launchpad.net http://bugs.launchpad.net/
Brendan Shephard Senior Software Engineer Brisbane, Australia
> On 15 Sep 2022, at 2:25 am, Albert Braden <ozzzo@yahoo.com mailto:ozzzo@yahoo.com> wrote: > > Hi Brendan, thanks for offering to help! I'll contact you privately
with info about some languishing cases.
> > Here's the policy line: > "update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
> > Does this policy only affect Horizon? I'm using the same non-admin
user for both CLI and Horizon, on a project where that user is a member. The network was created by the admin user.
> On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard <
bshephar@redhat.com mailto:bshephar@redhat.com> wrote:
> > > Hi Albert, > > While I may not be the best person to address your Horizon concern. I
can probably help you with your Red Hat support concerns. If you had any issues you wanted addressed, or feedback you wanted to provide. Feel free to give me a yell.
> > Looking at your Horizon issue though. It seems the default policy file
is what prevents you from updating that port. We can see the default policy like this for example:
> > [root@controller-2 ~]# podman exec -it neutron_api
oslopolicy-policy-generator --namespace neutron | grep "update_port:port_security_enabled"
> "update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
> > When you execute the command via the CLI, which user are you using?
Are you just sourcing the overcloudrc file, or using export OS_CLOUD=overcloud. If that’s the case then you would be using the admin user on the CLI, but probably a different user when logging into Horizon.
> > I too would suggest opening a support case. It sounds like you have
previously had a negative experience with that. If you want to open a new one and share the case number with me, I can follow up on that for you. As someone who personally knows a lot of the RHOSP Technical Support team from around the world. I’m confident we can right whatever wrong may have occurred there.
> > Let me know if I can help in any way. > > Regards, > > Brendan Shephard > Senior Software Engineer > Brisbane, Australia > > > > > On 14 Sep 2022, at 10:36 pm, Albert Braden <ozzzo@yahoo.com mailto:ozzzo@yahoo.com> wrote: > > > > On CLI I can type "openstack port set --no-security-group <ID>" to
remove all security groups. In Horizon, the equivalent operation would be using the - button to remove all groups and then clicking "Update." Using the + button would be the equivalent of typing "openstack port set --security-group <group ID>". There doesn't seem to be a way to remove a single security group via CLI; I think the only way would be to set --no-security-group and then add back the desired groups.
> > > > I can successfully add security groups to a port via CLI, or I can
remove all security groups. If I go into Horizon and try these operations then I get the error when I click "Update." So it appears that security groups can be added and removed, with port security set, via CLI. We only see the failure when we try to do it via Horizon.
> > > > Regarding RHOSP support; I assume that you are joking, or maybe
haven't experienced the support that they offer.
> > On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont <
laurentfdumont@gmail.com mailto:laurentfdumont@gmail.com> wrote:
> > > > > > If you are running RHOSP, you might have a support contract with Red
Hat?
> > > > Are you trying to remove all the security groups from a port that
has port_security enabled?
> > > > On Tue, Sep 13, 2022 at 11:53 AM Albert Braden <ozzzo@yahoo.com mailto:ozzzo@yahoo.com>
wrote:
> > > Unfortunately we are running RHOSP in which Train is the latest
and greatest. This is what we see in horizon.log:
> > > > > > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid
139683266553600] [remote 10.232.233.11:57498 http://10.232.233.11:57498/] Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
> > > On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau <
pierre@stackhpc.com mailto:pierre@stackhpc.com> wrote:
> > > > > > > > > Hello, > > > > > > This is more likely to be a Horizon bug than an issue with Kolla
itself, since Kolla doesn't change much from the default configuration.
> > > > > > You should check Horizon logs in /var/log/kolla/horizon to find
the error. I would also encourage you to upgrade to a more recent release, since Train has been marked as End of Life in Kolla recently.
> > > > > > Cheers, > > > Pierre Riteau (priteau) > > > > > > On Fri, 9 Sept 2022 at 15:41, Albert Braden <ozzzo@yahoo.com mailto:ozzzo@yahoo.com>
wrote:
> > > > We're running kolla train and we're seeing an apparent bug when
we try to add or remove security groups on a port. We see error "Failed to update port <ID>". It works fine in CLI; we only see this in Horizon. Is this a known bug, or are we doing something wrong?
> > > > >
-- Radomir Dopieralski
Hey Radomir,
Thanks for your input. I did indeed find that patch and used it to patch my env. In this case though, it didn’t seem to change the API request sent to Neutron.
If I log the data variable at this point https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/networks/ports/workflows.py#L431 after applying the patch. It contains all of the fields:
2022-09-16 00:01:55,046 35 INFO openstack_dashboard.dashboards.project.networks.ports.workflows bshephar - Data variable = {'port_id': '4df563ce-5464-4f7d-8aaf-c5496cdaefda', 'network_id': 'acefae53-b4d5-422f-bcca-dc32a0785d21', 'name': '', 'admin_state': True, 'target_tenant_id': '3ff28fc7abf742a6b7a0d016771dee49', 'binding__vnic_type': 'normal', 'port_security_enabled': True, 'instance_id': 'ccb72b14-3694-40fa-9b3b-ec1a8d7ef046', 'mac_state': None, 'wanted_groups': ['a3ae6e20-67df-4a72-9d5b-cc21ad87464f']}
So checking this if data['port_security_enabled'] is not None: params['port_security_enabled'] = data['port_security_enabled']
This is still True, so we’re setting the param to the data value and using that in our API call to Neutron.
I’m really not familiar at all with the Horizon code base. So let me know if I’m misunderstanding the intention of the patch you referenced. But I think the idea would be to check our `params` against the actual value returned from neutron.port_get() and only have fields that are changed in our params. So when we call the port_update() here:
At least in the case we’re discussing here, that resolves the issue. This is just rudimentary hackery to see what works, but this fixes the issue for me (Ignore the LOG line obviously):
❯ diff horizon/openstack_dashboard/dashboards/project/networks/ports/workflows.py workflows.py 411c411 < params = self._construct_parameters(data) ---
params = self._construct_parameters(request, data)
420c420 < def _construct_parameters(self, data): ---
def _construct_parameters(self, request, data):
424a425,426
LOG.info("bshephar - Data variable = %s", data) initial = api.neutron.port_get(request, self.context['port_id'])
431c433,434 < if data['port_security_enabled'] is not None: ---
if (data['port_security_enabled'] is not None and
data['port_security_enabled']
!= initial['port_security_enabled']):
The API call after this change looks like this:
2022-09-16 00:17:49,147 31 DEBUG neutronclient.client REQ: b'curl -i https://openstack.bne-home.net:13696/v2.0/ports/4df563ce-5464-4f7d-8aaf-c549... -X PUT -H "X-Auth-Token: {SHA256}65efff6982c871ae21a157ab46e4e2bebf69fc8619e8a1512d7ce0dd96b94369" -H "User-Agent: python-neutronclient" -d '{"port": {"name": "", "admin_state_up": true, "security_groups": ["a3ae6e20-67df-4a72-9d5b-cc21ad87464f"], "binding:vnic_type": "normal"}}''
And subsequently is accepted by Neutron. So I’m not too sure about the approach within your existing framework. But I mean, I’m happy to propose exactly that as a solution and we can debate it further if you like Radomir?
Thanks again,
Brendan Shephard Senior Software Engineer Brisbane, Australia
Brendan Shephard
Senior Software Engineer
Red Hat APAC https://www.redhat.com
193 N Quay
Brisbane City QLD 4000 @RedHat https://twitter.com/redhat Red Hat https://www.linkedin.com/company/red-hat Red Hat https://www.facebook.com/RedHatInc https://red.ht/sig https://redhat.com/summit
On Thu, Sep 15, 2022 at 11:57 PM Radomir Dopieralski rdopiera@redhat.com wrote:
It's a known problem and there is a patch for it in review for quite some time: https://review.opendev.org/c/openstack/horizon/+/810224
On Thu, Sep 15, 2022 at 3:36 PM Brendan Shephard bshephar@redhat.com wrote:
Hey all,
I think we might be onto something here. With the help of @Sean Mooney smooney@redhat.com ++ and @Takashi Kajinami tkajinam@redhat.com ++. It appears the API request when sent from Horizon contains additional fields that don't require update. But when the request comes from openstackcli, it is just updating the security group field only.
openstackcli: REQ: curl -g -i --cacert "/Users/shep/.certs/overcloud-cacert.pem" -X PUT https://openstack.bne-home.net:13696/v2.0/ports/4df563ce-5464-4f7d-8aaf-c549... -H "Content-Type: application/json" -H "User-Agent: openstacksdk/0.100.0 keystoneauth1/5.0.0 python-requests/2.28.1 CPython/3.10.6" -H "X-Auth-Token: {SHA256}3ec8b1d0b17434ec67c2960486ec19f17dfb2884fb47c5b54e1cec2beceb1a87" -d '{"port": {"security_groups": ["a3ae6e20-67df-4a72-9d5b-cc21ad87464f", "a31b9954-b7e6-4d4e-887c-e21a59c052ea"]}}' https://openstack.bne-home.net:13696 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" 200 1002
Horizon API call to Neutron: 2022-09-15 00:02:46,820 33 DEBUG neutronclient.client REQ: b'curl -i https://openstack.bne-home.net:13696/v2.0/ports/4df563ce-5464-4f7d-8aaf-c549... -X PUT -H "X-Auth-Token: {SHA256}52f077cf0115286c45f1e212cbec4ecdfc56ae41704c869aeb35cea41fdbfde1" -H "User-Agent: python-neutronclient" -d '{"port": {"name": "", "admin_state_up": true, "port_security_enabled": true, "security_groups": [], "binding:vnic_type": "normal"}}''
So when Neutron receives that request from Horizon, we get blocked because we (as members) are not permitted to update the port_security_enabled field. Even though it's already set to true in this case.
Given that information, the bug is probably back on Horizon here to not include fields that don't require update.
Brendan Shephard
Senior Software Engineer
Red Hat APAC https://www.redhat.com
193 N Quay
Brisbane City QLD 4000 @RedHat https://twitter.com/redhat Red Hat https://www.linkedin.com/company/red-hat Red Hat https://www.facebook.com/RedHatInc https://red.ht/sig https://redhat.com/summit
On Thu, Sep 15, 2022 at 10:46 PM Albert Braden ozzzo@yahoo.com wrote:
If I add/remove security groups from an instance in Horizon, it works. It's when I add/remove security groups from a port that the error occurs. One way to reproduce is to click on the instance and then go to the "Interfaces" tab, and click "Update Security Groups" on the right. On Thursday, September 15, 2022, 08:21:17 AM EDT, Brendan Shephard < bshephar@redhat.com> wrote:
Hey,
I'm doing it from the instances one:
https://openstack.bne-home.net/dashboard/project/instances/ccb72b14-3694-40f...
But for what it's worth. I get the same error if I do it from:
https://openstack.bne-home.net/dashboard/project/networks/acefae53-b4d5-422f...
Interesting that it worked for you there. Be good to confirm with @ozzzo@yahoo.com ozzzo@yahoo.com as well as to exactly where in Horizon he is trying to modify the security groups. Just so we're all trying to do the exact same thing.
My environment is also deployed from the latest tripleo packages, so I'll also test on that internal lab you referenced Sean. That would be more representative of Alberts issue since he is using RHOSP.
Brendan Shephard
Senior Software Engineer
Red Hat APAC https://www.redhat.com
193 N Quay
Brisbane City QLD 4000 @RedHat https://twitter.com/redhat Red Hat https://www.linkedin.com/company/red-hat Red Hat https://www.facebook.com/RedHatInc https://red.ht/sig https://redhat.com/summit
On Thu, Sep 15, 2022 at 10:12 PM Sean Mooney smooney@redhat.com wrote:
On Thu, 2022-09-15 at 21:33 +1000, Brendan Shephard wrote:
Hey Sean,
Thanks for the reply.
For reference, I have all the steps to reproduce along with the
relevant
debug logs attached to this LP: https://bugs.launchpad.net/neutron/+bug/1989627
But, to summarize. If I go to any random instance in Horizon as a
member
user - not a admin. Then try to remove any Security Group at all from
any
of the ports it fails with the policy violation (I attached a
screenshot of
where I'm making that change in Horizon). But doing it with the same
user
from the cli works fine. Since I'm editing individual interfaces there, rather than the instance itself. I assumed these would all be API
calls to
Neutron from Horizon rather than from Horizon to Nova.
updating the instance securty group will not affect any exsitng ports when you want to add or remvoe security groups form a port in horizont you do not do that via the instace secutity group you do it via the port edit dialog in the port detail view under the network
https://<your cloud goes here>/dashboard/project/networks/ports/<port uuid>/detail
i just did that now on a train cloud we have internally and was able to add and remove a security group on a port.
I just run server list --all to demonstrate I was indeed using a member user and not a admin since an admin would have seen VM's from all
projects.
I agree with you in principle. It should be exactly the same whether it comes from openstackclient or from Horizon. In fact, I was 98%
positive I
would be able to demonstrate the wrong user was being used in this
case.
But unfortunately, my efforts to reproduce it demonstrated that the
two are
indeed handled differently.
what page in horizon are you editing it form if i try and add/remove the secirty group via the interfaces tabe at https://<cloud>/dashboard/project/instances/<instance uuid>/ it also work for me inlcuding removing all secuity groups and i am not an admin on this cloud.
specificly this is the redhat internal shared cloud i was testing on.
I believe anyone should be able to reproduce it using the steps I
outlined
on the LP.
Brendan Shephard
Senior Software Engineer
Red Hat APAC https://www.redhat.com
193 N Quay
Brisbane City QLD 4000 @RedHat https://twitter.com/redhat Red Hat https://www.linkedin.com/company/red-hat Red Hat https://www.facebook.com/RedHatInc https://red.ht/sig https://redhat.com/summit
On Thu, Sep 15, 2022 at 8:48 PM Sean Mooney smooney@redhat.com
wrote:
On Thu, 2022-09-15 at 08:59 +1000, Brendan Shephard wrote:
Hey Albert,
The policy is the default Neutron policy in OpenStack Train. These
can
indeed be changed and customised, but my assumption is that you
haven’t
created any custom policies. Horizon uses the default for each
service
unless it’s been overwritten. policy is defiend server side not client side so it applie equially
to all
users of the api so the behavior will be the same for horizon or the cli if you ever find a delta because horizon say used a differnt token
to make
the request that is a securty vulnerablity in horizon and should be reported privatly to the horizon core team :)
If I create a non-admin user and try to change security groups I
also
get the same error:
2022-09-14 22:01:33,370 64 INFO
openstack_dashboard.dashboards.project.networks.ports.workflows
Failed to
update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port
and
rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
And I can reproduce your same scenario ff I try via the CLI using
these
steps:
- Add entry for new user to clouds.yaml file:
bne-home-test: auth: auth_url: https://openstack.bne-home.net:13000 password: "test" project_domain_name: Default project_name: bne-home user_domain_name: Default username: test cacert: ~/.certs/overcloud-cacert.pem identity_api_version: '3' region_name: regionOne volume_api_version: ‘3'
export OS_CLOUD=bne-home-test
Try to remove security group from port:
❯ openstack server show test-lb-net -c security_groups -c
addresses -f
yaml
addresses: lb-mgmt-net:
- 172.24.0.90
vlan4-infra:
- 172.20.13.175
security_groups:
- name: management-bne
the security group listed in nova is the default security group that
will
be used by all port create by nova. it only applie to ports created by nova and not ones that are passed
in
using the uuid of a precreate port.
you shoudl in general not mix managing security groups via nova and neutron. horizon shoudl prefer to manage security groups only via neutron if
it can.
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c
fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
port_security_enabled: true security_group_ids:
- a3ae6e20-67df-4a72-9d5b-cc21ad87464f
❯ openstack port unset --security-group
a3ae6e20-67df-4a72-9d5b-cc21ad87464f
4df563ce-5464-4f7d-8aaf-c5496cdaefda
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c
fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
port_security_enabled: true security_group_ids: []
Verify that I’m definitely not a admin user: ❯ openstack server list --all Policy doesn't allow os_compute_api:servers:detail:get_all_tenants
to be
performed. (HTTP 403) (Request-ID:
req-75c19210-ad91-471f-b500-e1f3482825f8)
I don’t think this user should be allowed to do that via the CLI
either.
So that could be a bug there. The request in the Neutron server.log
when I
do it via the CLI:
user can add or remove security groups without being and admin
including
removing all securtiy groups thats intended behavior and should not
require
admin.
are you implying that horizon is doing "openstack server list --all"
--all
is short for --all-tenants. outside of the admin tab in horizon horizon would never pass the
equivlent
of --all to the nova api.
2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None
req-f99c4c15-003c-4f7e-9e41-9100daa2a566
781362d053ee4708a21430d3a825795a
3ff28fc7abf742a6b7a0d016771dee49 - - default default] 192.168.1.17,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status:
200
len: 1102 time: 0.4449480
VS Horizon: 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None
req-4c284690-eb69-43df-b205-4953a88ab87c
781362d053ee4708a21430d3a825795a
3ff28fc7abf742a6b7a0d016771dee49 - - default default] 172.20.10.25,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status:
403
len: 386 time: 0.2209103
I have raised a upstream bug for this since I can still reproduce
it on
the latest version of OpenStack:
https://bugs.launchpad.net/neutron/+bug/1989627%EF%BF%BC Bug #1989627 “Policy enforcement variance between openstackcli
a...” :
Bugs : neutron
bugs.launchpad.net
policy is enfoced on the nova/neutron api it cant behave differntly
for
horizon unless horizon is useing the wrong token. i.e. not he users token.
Brendan Shephard Senior Software Engineer Brisbane, Australia
> On 15 Sep 2022, at 2:25 am, Albert Braden ozzzo@yahoo.com
wrote:
> > Hi Brendan, thanks for offering to help! I'll contact you
privately
with info about some languishing cases.
> > Here's the policy line: > "update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
> > Does this policy only affect Horizon? I'm using the same
non-admin
user for both CLI and Horizon, on a project where that user is a
member.
The network was created by the admin user.
> On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan
Shephard <
bshephar@redhat.com> wrote:
> > > Hi Albert, > > While I may not be the best person to address your Horizon
concern. I
can probably help you with your Red Hat support concerns. If you had
any
issues you wanted addressed, or feedback you wanted to provide. Feel
free
to give me a yell.
> > Looking at your Horizon issue though. It seems the default
policy file
is what prevents you from updating that port. We can see the default
policy
like this for example:
> > [root@controller-2 ~]# podman exec -it neutron_api
oslopolicy-policy-generator --namespace neutron | grep "update_port:port_security_enabled"
> "update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
> > When you execute the command via the CLI, which user are you
using?
Are you just sourcing the overcloudrc file, or using export OS_CLOUD=overcloud. If that’s the case then you would be using the
admin
user on the CLI, but probably a different user when logging into
Horizon.
> > I too would suggest opening a support case. It sounds like you
have
previously had a negative experience with that. If you want to open
a new
one and share the case number with me, I can follow up on that for
you. As
someone who personally knows a lot of the RHOSP Technical Support
team from
around the world. I’m confident we can right whatever wrong may have occurred there.
> > Let me know if I can help in any way. > > Regards, > > Brendan Shephard > Senior Software Engineer > Brisbane, Australia > > > > > On 14 Sep 2022, at 10:36 pm, Albert Braden ozzzo@yahoo.com
wrote:
> > > > On CLI I can type "openstack port set --no-security-group
<ID>" to
remove all security groups. In Horizon, the equivalent operation
would be
using the - button to remove all groups and then clicking "Update."
Using
the + button would be the equivalent of typing "openstack port set --security-group <group ID>". There doesn't seem to be a way to
remove a
single security group via CLI; I think the only way would be to set --no-security-group and then add back the desired groups.
> > > > I can successfully add security groups to a port via CLI, or I
can
remove all security groups. If I go into Horizon and try these
operations
then I get the error when I click "Update." So it appears that
security
groups can be added and removed, with port security set, via CLI. We
only
see the failure when we try to do it via Horizon.
> > > > Regarding RHOSP support; I assume that you are joking, or maybe
haven't experienced the support that they offer.
> > On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent
Dumont <
laurentfdumont@gmail.com> wrote:
> > > > > > If you are running RHOSP, you might have a support contract
with Red
Hat?
> > > > Are you trying to remove all the security groups from a port
that
has port_security enabled?
> > > > On Tue, Sep 13, 2022 at 11:53 AM Albert Braden <
ozzzo@yahoo.com
mailto:ozzzo@yahoo.com> wrote:
> > Unfortunately we are running RHOSP in which Train is the
latest and
greatest. This is what we see in horizon.log:
> > > > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid
139683266553600] [remote 10.232.233.11:57498 <
http://10.232.233.11:57498/%3E]
Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
> > On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau <
pierre@stackhpc.com mailto:pierre@stackhpc.com> wrote:
> > > > > > Hello, > > > > This is more likely to be a Horizon bug than an issue with
Kolla
itself, since Kolla doesn't change much from the default
configuration.
> > > > You should check Horizon logs in /var/log/kolla/horizon to
find the
error. I would also encourage you to upgrade to a more recent
release,
since Train has been marked as End of Life in Kolla recently.
> > > > Cheers, > > Pierre Riteau (priteau) > > > > On Fri, 9 Sept 2022 at 15:41, Albert Braden <ozzzo@yahoo.com
mailto:ozzzo@yahoo.com> wrote:
> > We're running kolla train and we're seeing an apparent bug
when we
try to add or remove security groups on a port. We see error "Failed
to
update port <ID>". It works fine in CLI; we only see this in
Horizon. Is
this a known bug, or are we doing something wrong?
> > >
Hey Albert,
The policy is the default Neutron policy in OpenStack Train. These
can
indeed be changed and customised, but my assumption is that you
haven’t
created any custom policies. Horizon uses the default for each
service
unless it’s been overwritten.
If I create a non-admin user and try to change security groups I
also
get the same error:
2022-09-14 22:01:33,370 64 INFO
openstack_dashboard.dashboards.project.networks.ports.workflows
Failed to
update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port
and
rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
And I can reproduce your same scenario ff I try via the CLI using
these
steps:
- Add entry for new user to clouds.yaml file:
bne-home-test: auth: auth_url: https://openstack.bne-home.net:13000 password: "test" project_domain_name: Default project_name: bne-home user_domain_name: Default username: test cacert: ~/.certs/overcloud-cacert.pem identity_api_version: '3' region_name: regionOne volume_api_version: ‘3'
export OS_CLOUD=bne-home-test
Try to remove security group from port:
❯ openstack server show test-lb-net -c security_groups -c
addresses -f
yaml
addresses: lb-mgmt-net:
- 172.24.0.90
vlan4-infra:
- 172.20.13.175
security_groups:
- name: management-bne
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c
fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
port_security_enabled: true security_group_ids:
- a3ae6e20-67df-4a72-9d5b-cc21ad87464f
❯ openstack port unset --security-group
a3ae6e20-67df-4a72-9d5b-cc21ad87464f
4df563ce-5464-4f7d-8aaf-c5496cdaefda
❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c
fixed_ips
-c port_security_enabled -c security_group_ids -f yaml
fixed_ips:
- ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
port_security_enabled: true security_group_ids: []
Verify that I’m definitely not a admin user: ❯ openstack server list --all Policy doesn't allow os_compute_api:servers:detail:get_all_tenants
to be
performed. (HTTP 403) (Request-ID:
req-75c19210-ad91-471f-b500-e1f3482825f8)
I don’t think this user should be allowed to do that via the CLI
either.
So that could be a bug there. The request in the Neutron server.log
when I
do it via the CLI:
2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None
req-f99c4c15-003c-4f7e-9e41-9100daa2a566
781362d053ee4708a21430d3a825795a
3ff28fc7abf742a6b7a0d016771dee49 - - default default] 192.168.1.17,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status:
200
len: 1102 time: 0.4449480
VS Horizon: 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None
req-4c284690-eb69-43df-b205-4953a88ab87c
781362d053ee4708a21430d3a825795a
3ff28fc7abf742a6b7a0d016771dee49 - - default default] 172.20.10.25,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status:
403
len: 386 time: 0.2209103
I have raised a upstream bug for this since I can still reproduce
it on
the latest version of OpenStack:
launchpad-og-image.pngBug #1989627 “Policy enforcement variance
between
openstackcli a...” : Bugs : neutron
bugs.launchpad.net
Brendan Shephard Senior Software Engineer Brisbane, Australia
> On 15 Sep 2022, at 2:25 am, Albert Braden ozzzo@yahoo.com
wrote:
> > Hi Brendan, thanks for offering to help! I'll contact you
privately
with info about some languishing cases.
> > Here's the policy line: > "update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
> > Does this policy only affect Horizon? I'm using the same
non-admin
user for both CLI and Horizon, on a project where that user is a
member.
The network was created by the admin user.
> On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan
Shephard <
bshephar@redhat.com> wrote:
> > > Hi Albert, > > While I may not be the best person to address your Horizon
concern. I
can probably help you with your Red Hat support concerns. If you had
any
issues you wanted addressed, or feedback you wanted to provide. Feel
free
to give me a yell.
> > Looking at your Horizon issue though. It seems the default
policy file
is what prevents you from updating that port. We can see the default
policy
like this for example:
> > [root@controller-2 ~]# podman exec -it neutron_api
oslopolicy-policy-generator --namespace neutron | grep "update_port:port_security_enabled"
> "update_port:port_security_enabled": "rule:context_is_advsvc or
rule:admin_or_network_owner"
> > When you execute the command via the CLI, which user are you
using?
Are you just sourcing the overcloudrc file, or using export OS_CLOUD=overcloud. If that’s the case then you would be using the
admin
user on the CLI, but probably a different user when logging into
Horizon.
> > I too would suggest opening a support case. It sounds like you
have
previously had a negative experience with that. If you want to open
a new
one and share the case number with me, I can follow up on that for
you. As
someone who personally knows a lot of the RHOSP Technical Support
team from
around the world. I’m confident we can right whatever wrong may have occurred there.
> > Let me know if I can help in any way. > > Regards, > > Brendan Shephard > Senior Software Engineer > Brisbane, Australia > > > > > On 14 Sep 2022, at 10:36 pm, Albert Braden ozzzo@yahoo.com
wrote:
> > > > On CLI I can type "openstack port set --no-security-group
<ID>" to
remove all security groups. In Horizon, the equivalent operation
would be
using the - button to remove all groups and then clicking "Update."
Using
the + button would be the equivalent of typing "openstack port set --security-group <group ID>". There doesn't seem to be a way to
remove a
single security group via CLI; I think the only way would be to set --no-security-group and then add back the desired groups.
> > > > I can successfully add security groups to a port via CLI, or I
can
remove all security groups. If I go into Horizon and try these
operations
then I get the error when I click "Update." So it appears that
security
groups can be added and removed, with port security set, via CLI. We
only
see the failure when we try to do it via Horizon.
> > > > Regarding RHOSP support; I assume that you are joking, or maybe
haven't experienced the support that they offer.
> > On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent
Dumont <
laurentfdumont@gmail.com> wrote:
> > > > > > If you are running RHOSP, you might have a support contract
with Red
Hat?
> > > > Are you trying to remove all the security groups from a port
that
has port_security enabled?
> > > > On Tue, Sep 13, 2022 at 11:53 AM Albert Braden <
ozzzo@yahoo.com>
wrote:
> > > Unfortunately we are running RHOSP in which Train is the
latest
and greatest. This is what we see in horizon.log:
> > > > > > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid
139683266553600] [remote 10.232.233.11:57498] Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy
> > > On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre
Riteau <
pierre@stackhpc.com> wrote:
> > > > > > > > > Hello, > > > > > > This is more likely to be a Horizon bug than an issue with
Kolla
itself, since Kolla doesn't change much from the default
configuration.
> > > > > > You should check Horizon logs in /var/log/kolla/horizon to
find
the error. I would also encourage you to upgrade to a more recent
release,
since Train has been marked as End of Life in Kolla recently.
> > > > > > Cheers, > > > Pierre Riteau (priteau) > > > > > > On Fri, 9 Sept 2022 at 15:41, Albert Braden <ozzzo@yahoo.com
wrote:
> > > > We're running kolla train and we're seeing an apparent bug
when
we try to add or remove security groups on a port. We see error
"Failed to
update port <ID>". It works fine in CLI; we only see this in
Horizon. Is
this a known bug, or are we doing something wrong?
> > > > >
-- Radomir Dopieralski
Hey Radomir
My replies keep getting blocked because they’re too big. I’ll summarise and then you will all get spammed if someone decides to approve my other replies. In our case, I had already tried that patch and it doesn’t resolve this particular issue. The problem I see is that we need to compare the fields in our params with what already exists on the port. Then not send fields that are unchanged. This diff resolved the issue we’re discussing here:
❯ diff horizon/openstack_dashboard/dashboards/project/networks/ports/workflows.py workflows.py 411c411 < params = self._construct_parameters(data) ---
params = self._construct_parameters(request, data)
420c420 < def _construct_parameters(self, data): ---
def _construct_parameters(self, request, data):
424a425,426
LOG.info("bshephar - Data variable = %s", data) initial = api.neutron.port_get(request, self.context['port_id'])
431c433,434 < if data['port_security_enabled'] is not None: ---
if (data['port_security_enabled'] is not None and data['port_security_enabled'] != initial['port_security_enabled']):
This probably isn’t a solution you guys would want to merge. But it demonstrates a working solution to the problem that we’re discussing.
Brendan Shephard Senior Software Engineer Brisbane, Australia
participants (6)
-
Albert Braden
-
Brendan Shephard
-
Laurent Dumont
-
Pierre Riteau
-
Radomir Dopieralski
-
Sean Mooney