[Yahoo-eng-team] [Bug 1865239] [NEW] The virtual machine is saved in the image format (ceph rbd backend) as qcow2 instead of raw
Public bug reported: * OpenStack version:Rocky * The virtual machine is saved in the image format (ceph rbd backend) as qcow2 instead of raw. * Operation process： 1.openstack server image create --name ubuntu-1804-2nics-arm64 ubuntu18.04-arm 2.ubuntu18.04-arm :Virtual machines booted from a volume * openstack image show ubuntu-1804-2nics-arm64 | Field| Value | | checksum | d41d8cd98f00b204e9800998ecf8427e | | container_format | bare | | created_at | 2020-02-18T07:08:56Z
[Yahoo-eng-team] [Bug 1865223] [NEW] [scale issue] regression for security group list between Newton and Rocky+
Public bug reported: We recently upgraded an environment from Newton -> Rocky, and experienced a dramatic increase in the amount of time it takes to return a full security group list. For ~8,000 security groups, it takes nearly 75 seconds. This was not observed in Newton. I was able to replicate this in the following 4 environments: Newton (virtual machine) Rocky (baremetal) Stein (virtual machine) Train (baremetal) Command: openstack security group list > Sec Grps vs. Seconds QtyNewton VM Rocky BM Stein VM Train BM 200 4.1 3.7 5.4 5.2 500 5.3 7119.4 10007.2 12.4 19.2 16 20009.2 24.2 35.3 30.7 300012.136.5 5244 400016.147.2 7358.9 At this time, we do not know if this increase in time extends to other 'list' commands at scale. The 'show' commands appear to be fairly performant. This increase in time does have a negative impact on user perception, scripts, other dependent resources, etc. The Stein VM is slower than Train, but could be due to VM vs BM. The Newton environment is virtual, too, so I would expect even better performance on bare metal. Any assistance or insight into what might have changed between releases to cause this would be helpful. ** Affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1865223 Title: [scale issue] regression for security group list between Newton and Rocky+ Status in neutron: New Bug description: We recently upgraded an environment from Newton -> Rocky, and experienced a dramatic increase in the amount of time it takes to return a full security group list. For ~8,000 security groups, it takes nearly 75 seconds. This was not observed in Newton. I was able to replicate this in the following 4 environments: Newton (virtual machine) Rocky (baremetal) Stein (virtual machine) Train (baremetal) Command: openstack security group list > Sec Grps vs. Seconds QtyNewton VM Rocky BM Stein VM Train BM 200 4.1 3.7 5.4 5.2 500 5.3 7119.4 10007.2 12.4 19.2 16 20009.2 24.2 35.3 30.7 300012.136.5 5244 400016.147.2 7358.9 At this time, we do not know if this increase in time extends to other 'list' commands at scale. The 'show' commands appear to be fairly performant. This increase in time does have a negative impact on user perception, scripts, other dependent resources, etc. The Stein VM is slower than Train, but could be due to VM vs BM. The Newton environment is virtual, too, so I would expect even better performance on bare metal. Any assistance or insight into what might have changed between releases to cause this would be helpful. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1865223/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1865121] Re: 'openstack token issue' command doesn't issue token for MFA enabled user
You were offline when I responded to your query on IRC: http://eavesdrop.openstack.org/irclogs/%23openstack-keystone /%23openstack-keystone.2020-02-27.log.html#t2020-02-27T13:51:49 In short, the support is partially there already in keystoneauth: https://docs.openstack.org/keystoneauth/latest/authentication- plugins.html#multi-factor-with-v3-identity-plugins We just need to close the gap in python-openstackclient, so this bug will need to be filed in storyboard for osc: https://storyboard.openstack.org/#!/project/975 ** Changed in: keystone Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1865121 Title: 'openstack token issue' command doesn't issue token for MFA enabled user Status in OpenStack Identity (keystone): Invalid Bug description: User who has been to configured such that he can only get a token when he presents more than one modes of authentication, say password & totp. In these cases, 'openstack token issue' command gives 401 error as there is no means for providing totp as an argument. Can a option like --totp be added, like 'openstack token issue --totp 123456' so that MFA users can also use this command to generate token? Or is there any other way currently in openstack using which 'openstack token issue' command can be used to generate token for MFA users! like adding some environment variable in openrc & then eexcuting token issue. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1865121/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1865156] Re: If-Match header ignored for routers and floating ip updates
Hmm,
but indeed it don't works for Floating IP:
curl -g -i -X PUT
http://10.120.0.30:9696/v2.0/floatingips/742a4311-99af-4232-a45a-00b7827bd9ba
-H "If-Match: revision_number=3" -H "Accept: application/json" -H
"Content-Type: application/json" -H "User-Agent: python-neutronclient" -H
"X-Auth-Token: $token" -d '{"floatingip": {"description": "Test 5"}}'
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 927
X-Openstack-Request-Id: req-714f5d6e-c672-4f3a-aac8-a21f3bf8ec41
Date: Thu, 27 Feb 2020 15:16:17 GMT
{"floatingip": {"id": "742a4311-99af-4232-a45a-00b7827bd9ba",
"tenant_id": "0c5d93b067784b609fb5d07873e1b80d", "floating_ip_address":
"10.10.0.165", "floating_network_id": "b5623d28-a48e-4fca-a4bc-
8490e35b8b99", "router_id": "9c760b37-3af6-4955-959c-c608f2ef4822",
"port_id": "684bcfaf-ba6d-4c53-9ec9-ae4786e07268", "fixed_ip_address":
"10.100.127.222", "status": "DOWN", "description": "Test 5",
"qos_policy_id": null, "port_details": {"name":
"tobiko.openstack.stacks._cirros.CirrosServerStackFixture-port-
44c77t5zhuq4", "network_id": "e09c14f0-0460-44f2-9629-a3fa876e9c80",
"mac_address": "fa:16:3e:e2:78:cc", "admin_state_up": true, "status":
"ACTIVE", "device_id": "b2d88234-7978-4682-8f6a-a51d25485573",
"device_owner": "compute:nova"}, "port_forwardings": [], "tags": [],
"created_at": "2020-02-26T21:50:51Z", "updated_at":
"2020-02-27T15:16:16Z", "revision_number": 4, "project_id":
"0c5d93b067784b609fb5d07873e1b80d"}}
** Changed in: neutron
Status: Invalid => Confirmed
** Changed in: neutron
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1865156
Title:
If-Match header ignored for routers and floating ip updates
Status in neutron:
Confirmed
Bug description:
According to release note [1], the If-Match conditional updates should
be supported for all resources that have revision_number. Apparently
that doesn't work for routers:
mdulko:openstacksdk/ (neutron-if-match*) $ curl -g -i -X PUT -H
"Content-Type: application/json" -H "User-Agent: openstacksdk/0.41.1
keystoneauth1/3.18.0 python-requests/2.22.0 CPython/3.7.6" -H "X-Auth-Token:
" -H "If-Match: revision_number=" -d '{"router": {"name": "dulek2"}}'
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 475
X-Openstack-Request-Id: req-153fe53e-3b79-4bb8-aebb-4f334c35e449
Date: Fri, 28 Feb 2020 14:07:40 GMT
{"router": {"status": "ACTIVE", "external_gateway_info": null,
"availability_zone_hints": [], "availability_zones": ["nova"],
"description": "", "tags": [], "tenant_id":
"c73b7097d07c46f78eb4b4dcfbac5ca8", "created_at":
"2020-02-28T14:00:43Z", "admin_state_up": true, "updated_at":
"2020-02-28T14:07:40Z", "flavor_id": null, "revision_number": 7,
"routes": [], "project_id": "c73b7097d07c46f78eb4b4dcfbac5ca8", "id":
"b6012d87-886b-4b3b-912b-2eb6ad655514", "name": "dulek2"}}%
Unfortunately I'm not sure what OpenStack version is that.
[1]
https://github.com/openstack/neutron/blob/a388701ddfe628e9a5bd16a78422164799b11ef8/releasenotes/notes
/conditional_updates-10b9aa66fd144217.yaml
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1865156/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1865173] [NEW] Revision number not bumped after update of router's description
Public bug reported:
When router's description is updated, it's revision number isn't bumped:
[16:23:20] vagrant@devstack-ubuntu-ovs:~$ neutron router-show router1-updated
neutron CLI is deprecated and will be removed in the future. Use openstack CLI
instead.
+-+---+
| Field | Value
|
+-+---+
| admin_state_up | False
|
| availability_zone_hints |
|
| availability_zones | nova
|
| created_at | 2020-02-05T11:15:42Z
|
| description | Test 3
|
| distributed | False
|
| external_gateway_info | {"network_id":
"b5623d28-a48e-4fca-a4bc-8490e35b8b99", "external_fixed_ips": [{"subnet_id":
"6e83aac3-3fd1-4b22-bcaf-64a20e047c68", "ip_address": "10.10.0.130"},
{"subnet_id": "19192cb1-ab0a-4b6d-ac69-51cd5f2183d4", "ip_address":
"2001:db8::3cc"}], "enable_snat": true} |
| flavor_id |
|
| ha | False
|
| id | 07ee9def-6cf7-4dce-b898-014924c43c88
|
| name| router1-updated
|
| project_id | 7436d2571300417f97abf1dc232fbf20
|
| revision_number | 9
[Yahoo-eng-team] [Bug 1865156] Re: If-Match header ignored for routers and floating ip updates
Seems like this works on master.
** Changed in: neutron
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1865156
Title:
If-Match header ignored for routers and floating ip updates
Status in neutron:
Confirmed
Bug description:
According to release note [1], the If-Match conditional updates should
be supported for all resources that have revision_number. Apparently
that doesn't work for routers:
mdulko:openstacksdk/ (neutron-if-match*) $ curl -g -i -X PUT -H
"Content-Type: application/json" -H "User-Agent: openstacksdk/0.41.1
keystoneauth1/3.18.0 python-requests/2.22.0 CPython/3.7.6" -H "X-Auth-Token:
" -H "If-Match: revision_number=" -d '{"router": {"name": "dulek2"}}'
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 475
X-Openstack-Request-Id: req-153fe53e-3b79-4bb8-aebb-4f334c35e449
Date: Fri, 28 Feb 2020 14:07:40 GMT
{"router": {"status": "ACTIVE", "external_gateway_info": null,
"availability_zone_hints": [], "availability_zones": ["nova"],
"description": "", "tags": [], "tenant_id":
"c73b7097d07c46f78eb4b4dcfbac5ca8", "created_at":
"2020-02-28T14:00:43Z", "admin_state_up": true, "updated_at":
"2020-02-28T14:07:40Z", "flavor_id": null, "revision_number": 7,
"routes": [], "project_id": "c73b7097d07c46f78eb4b4dcfbac5ca8", "id":
"b6012d87-886b-4b3b-912b-2eb6ad655514", "name": "dulek2"}}%
Unfortunately I'm not sure what OpenStack version is that.
[1]
https://github.com/openstack/neutron/blob/a388701ddfe628e9a5bd16a78422164799b11ef8/releasenotes/notes
/conditional_updates-10b9aa66fd144217.yaml
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1865156/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1861529] Re: [RFE] A port's network should be changable
During our last drivers meeting on 28.02.2020 we were discussing this rfe and we agreed that for now we are not going to accept it as this would require big changes in both: neutron basic concepts and code and it's only to support some very old, legacy guest operating systems. But if You will have better use cases for this RFE, feel free to reopen this RFE and propose spec with detailed use cases and rationale for it. ** Tags removed: rfe-triaged ** Tags added: rfe ** Changed in: neutron Status: New => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1861529 Title: [RFE] A port's network should be changable Status in neutron: Won't Fix Bug description: We want a way to change a VM port’s network when the VM’s operating system does not support online removal and addition of devices. These are the steps to accomplish this: Given a running VM. We want to change the network of . No floating IP is associated with the VM. # openstack port set –no-fixed-ip # openstack port set –network-id # openstack port set –fixed-ip subnet= Neutron-server succeeds with changing the port’s network-id if: 1. The new network belongs to the same project as the original network. 2. The port has no fixed-ip addresses on it. 3. The port’s mac address is unused on the new network. 4. The new network’s MTU is greater than or equal to the old network’s. Some operating systems may be unable to handle online addition and deletion of devices. We want a way of changing a VM’s port’s network that does not rely on the guest operating system supporting these capabilities. The change is done by making the port’s network-id attribute to allow PUT requests. Neutron api server checks whether the 4 criteria are met. Then it will proceed with updating the port. When the new fixed- ip is set, the user will have to login to the VM’s console and manually change the guest OS’s configuration to make use of the new IP address. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1861529/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1865156] [NEW] If-Match header ignored for routers
Public bug reported:
According to release note [1], the If-Match conditional updates should
be supported for all resources that have revision_number. Apparently
that doesn't work for routers:
mdulko:openstacksdk/ (neutron-if-match*) $ curl -g -i -X PUT -H
"Content-Type: application/json" -H "User-Agent: openstacksdk/0.41.1
keystoneauth1/3.18.0 python-requests/2.22.0 CPython/3.7.6" -H "X-Auth-Token:
" -H "If-Match: revision_number=" -d '{"router": {"name": "dulek2"}}'
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 475
X-Openstack-Request-Id: req-153fe53e-3b79-4bb8-aebb-4f334c35e449
Date: Fri, 28 Feb 2020 14:07:40 GMT
{"router": {"status": "ACTIVE", "external_gateway_info": null,
"availability_zone_hints": [], "availability_zones": ["nova"],
"description": "", "tags": [], "tenant_id":
"c73b7097d07c46f78eb4b4dcfbac5ca8", "created_at":
"2020-02-28T14:00:43Z", "admin_state_up": true, "updated_at":
"2020-02-28T14:07:40Z", "flavor_id": null, "revision_number": 7,
"routes": [], "project_id": "c73b7097d07c46f78eb4b4dcfbac5ca8", "id":
"b6012d87-886b-4b3b-912b-2eb6ad655514", "name": "dulek2"}}%
Unfortunately I'm not sure what OpenStack version is that.
[1]
https://github.com/openstack/neutron/blob/a388701ddfe628e9a5bd16a78422164799b11ef8/releasenotes/notes
/conditional_updates-10b9aa66fd144217.yaml
** Affects: neutron
Importance: Undecided
Status: New
** Description changed:
According to release note [1], the If-Match conditional updates should
be supported for all resources that have revision_number. Apparently
that doesn't work for routers:
mdulko:openstacksdk/ (neutron-if-match*) $ curl -g -i -X PUT -H
"Content-Type: application/json" -H "User-Agent: openstacksdk/0.41.1
keystoneauth1/3.18.0 python-requests/2.22.0 CPython/3.7.6" -H "X-Auth-Token:
" -H "If-Match: revision_number=" -d '{"router": {"name": "dulek2"}}'
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 475
X-Openstack-Request-Id: req-153fe53e-3b79-4bb8-aebb-4f334c35e449
Date: Fri, 28 Feb 2020 14:07:40 GMT
{"router": {"status": "ACTIVE", "external_gateway_info": null,
"availability_zone_hints": [], "availability_zones": ["nova"],
"description": "", "tags": [], "tenant_id":
"c73b7097d07c46f78eb4b4dcfbac5ca8", "created_at":
"2020-02-28T14:00:43Z", "admin_state_up": true, "updated_at":
"2020-02-28T14:07:40Z", "flavor_id": null, "revision_number": 7,
"routes": [], "project_id": "c73b7097d07c46f78eb4b4dcfbac5ca8", "id":
"b6012d87-886b-4b3b-912b-2eb6ad655514", "name": "dulek2"}}%
Unfortunately I'm not sure what OpenStack version is that.
+
+ [1]
+
https://github.com/openstack/neutron/blob/a388701ddfe628e9a5bd16a78422164799b11ef8/releasenotes/notes
+ /conditional_updates-10b9aa66fd144217.yaml
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1865156
Title:
If-Match header ignored for routers
Status in neutron:
New
Bug description:
According to release note [1], the If-Match conditional updates should
be supported for all resources that have revision_number. Apparently
that doesn't work for routers:
mdulko:openstacksdk/ (neutron-if-match*) $ curl -g -i -X PUT -H
"Content-Type: application/json" -H "User-Agent: openstacksdk/0.41.1
keystoneauth1/3.18.0 python-requests/2.22.0 CPython/3.7.6" -H "X-Auth-Token:
" -H "If-Match: revision_number=" -d '{"router": {"name": "dulek2"}}'
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 475
X-Openstack-Request-Id: req-153fe53e-3b79-4bb8-aebb-4f334c35e449
Date: Fri, 28 Feb 2020 14:07:40 GMT
{"router": {"status": "ACTIVE", "external_gateway_info": null,
"availability_zone_hints": [], "availability_zones": ["nova"],
"description": "", "tags": [], "tenant_id":
"c73b7097d07c46f78eb4b4dcfbac5ca8", "created_at":
"2020-02-28T14:00:43Z", "admin_state_up": true, "updated_at":
"2020-02-28T14:07:40Z", "flavor_id": null, "revision_number": 7,
"routes": [], "project_id": "c73b7097d07c46f78eb4b4dcfbac5ca8", "id":
"b6012d87-886b-4b3b-912b-2eb6ad655514", "name": "dulek2"}}%
Unfortunately I'm not sure what OpenStack version is that.
[1]
https://github.com/openstack/neutron/blob/a388701ddfe628e9a5bd16a78422164799b11ef8/releasenotes/notes
/conditional_updates-10b9aa66fd144217.yaml
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1865156/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1865036] Re: l3 agent metadata proxy allows access to metadata from any available network
** Description changed: - This issue is being treated as a potential security risk under - embargo. Please do not make any public mention of embargoed - (private) security vulnerabilities before their coordinated - publication by the OpenStack Vulnerability Management Team in the - form of an official OpenStack Security Advisory. This includes - discussion of the bug or associated fixes in public forums such as - mailing lists, code review systems and bug trackers. Please also - avoid private disclosure to other individuals not already approved - for access to this information, and provide this same reminder to - those who are made aware of the issue prior to publication. All - discussion should remain confined to this private bug report, and - any proposed fixes should be added to the bug as attachments. This - embargo shall not extend past 2020-05-27 and will be made - public by or on that date if no fix is identified. - Tested with Train release, by quick code check it affects also at least Rocky, Stein and Ussuri (current master). The security issue is than one can access metadata of an arbitrary other instance if the following conditions are met (let's call the "other instance" a "victim", it can be in any other project not normally available to the attacker): 1) Victim's port fixed IP address is known. 2) Victim's port network ID is known. 3) Attacker can use a network with access to l3 agent metadata proxy (i.e. can use routers) and deploy instances. The scenario is as follows: 1) create a self-service network including the targeted address 2) create an instance with the same fixed IP address 3) create a router and wire it up with that network (other connections irrelevant) 4) boot up the instance (make sure to drop the potential route to dhcp agent metadata proxy if used) 5) run e.g.: curl -H "X-Neutron-Network-ID: $VICTIM_NET_ID" 169.254.169.254/openstack/latest/meta_data.json Observed behaviour: Normally-secret information disclosure. Expected behaviour: Proxy ignores (removes) that extra header and proceeds as if nothing happened (most expected) OR proxy returns an error (and logs it / sends a notification about it) OR proxy blocks the request and calls the police as you are a bad boy :-) (least expected... but nice) Initial code analysis: 1) the haproxy config is inadequate: https://opendev.org/openstack/neutron/src/commit/6b9765c991da8731fe39f7e7eed1ed6e2bca231a/neutron/agent/metadata/driver.py#L68 ^ this should replace all current headers in the current trust model 2) the reason this works with l3 agent (and so far not with dhcp agent unless there is some other general header exploit in the stack) are the following lines: https://opendev.org/openstack/neutron/src/commit/6b9765c991da8731fe39f7e7eed1ed6e2bca231a/neutron/agent/metadata/agent.py#L146-L152 ** Information type changed from Private Security to Public ** Changed in: ossa Status: Incomplete => Won't Fix ** Tags added: security -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1865036 Title: l3 agent metadata proxy allows access to metadata from any available network Status in neutron: Confirmed Status in OpenStack Security Advisory: Won't Fix Bug description: Tested with Train release, by quick code check it affects also at least Rocky, Stein and Ussuri (current master). The security issue is than one can access metadata of an arbitrary other instance if the following conditions are met (let's call the "other instance" a "victim", it can be in any other project not normally available to the attacker): 1) Victim's port fixed IP address is known. 2) Victim's port network ID is known. 3) Attacker can use a network with access to l3 agent metadata proxy (i.e. can use routers) and deploy instances. The scenario is as follows: 1) create a self-service network including the targeted address 2) create an instance with the same fixed IP address 3) create a router and wire it up with that network (other connections irrelevant) 4) boot up the instance (make sure to drop the potential route to dhcp agent metadata proxy if used) 5) run e.g.: curl -H "X-Neutron-Network-ID: $VICTIM_NET_ID" 169.254.169.254/openstack/latest/meta_data.json Observed behaviour: Normally-secret information disclosure. Expected behaviour: Proxy ignores (removes) that extra header and proceeds as if nothing happened (most expected) OR proxy returns an error (and logs it / sends a notification about it) OR proxy blocks the request and calls the police as you are a bad boy :-) (least expected... but nice) Initial code analysis: 1) the haproxy config is inadequate: https://opendev.org/openstack/neutron/src/commit/6b9765c991da8731fe39f7e7eed1ed6e2bca231a/neutron/agent/metadata/driver.py#L68 ^ this should
[Yahoo-eng-team] [Bug 1798351] Re: DNS available externally on provider network
*** This bug is a duplicate of bug 1501206 *** https://bugs.launchpad.net/bugs/1501206 Thanks! I've switched this to public and marked it as a duplicate. ** Description changed: - This issue is being treated as a potential security risk under - embargo. Please do not make any public mention of embargoed - (private) security vulnerabilities before their coordinated - publication by the OpenStack Vulnerability Management Team in the - form of an official OpenStack Security Advisory. This includes - discussion of the bug or associated fixes in public forums such as - mailing lists, code review systems and bug trackers. Please also - avoid private disclosure to other individuals not already approved - for access to this information, and provide this same reminder to - those who are made aware of the issue prior to publication. All - discussion should remain confined to this private bug report, and - any proposed fixes should be added to the bug as attachments. This - embargo shall not extend past 2020-05-27 and will be made - public by or on that date if no fix is identified. - DNS is open for everyone on our external provider network and this can be used to do a amplification attack. Shouldn't this access at least be filtered for external parties? Tested on openstack pike ** Changed in: ossa Status: Incomplete => Won't Fix ** Information type changed from Private Security to Public ** This bug has been marked a duplicate of bug 1501206 router:dhcp ports are open resolvers -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1798351 Title: DNS available externally on provider network Status in neutron: New Status in OpenStack Security Advisory: Won't Fix Bug description: DNS is open for everyone on our external provider network and this can be used to do a amplification attack. Shouldn't this access at least be filtered for external parties? Tested on openstack pike To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1798351/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1082248] Re: Use uuidutils instead of uuid.uuid4()
** No longer affects: rally -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1082248 Title: Use uuidutils instead of uuid.uuid4() Status in Barbican: Fix Released Status in Cinder: Won't Fix Status in OpenStack Dashboard (Horizon): Fix Released Status in Ironic: Fix Released Status in ironic-python-agent: Fix Released Status in Karbor: Fix Released Status in kolla: Fix Released Status in kuryr: Fix Released Status in kuryr-libnetwork: Fix Released Status in Mistral: Fix Released Status in networking-midonet: Fix Released Status in networking-ovn: Fix Released Status in networking-sfc: Fix Released Status in OpenStack Compute (nova): Fix Released Status in osprofiler: Fix Released Status in python-openstackclient: In Progress Status in Sahara: Fix Released Status in senlin: Fix Released Status in OpenStack Object Storage (swift): Won't Fix Status in tacker: Fix Released Status in watcher: Fix Released Bug description: Openstack common has a wrapper for generating uuids. We should only use that function when generating uuids for consistency. To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1082248/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1865138] [NEW] When deleting an stateless subnet port can get allocation on subnet with invalid segment
Public bug reported: A provider network with 3 stateless subnet, on different segments. (NOTE, this output is from a dev environment with WIP fixes for bug/1864333 and bug/1864333) $ for subnet in $(openstack subnet list --network providernet -f value -c ID); do openstack subnet show $subnet -f yaml -c segment_id -c cidr -c id; done cidr: deaf:beef:3::/64 id: 954a1b8c-5fe7-4dcc-84bd-df24c371e651 segment_id: 632b2bab-5402-4a4d-9433-783d7051d8aa cidr: deaf:beef:1::/64 id: ebae0025-a701-4b22-aa66-00ec48025b30 segment_id: d1930254-36c9-4490-94f7-d095a25cf3b0 cidr: deaf:beef:2::/64 id: ec2a9675-a286-4c8b-983d-2f762939cb5b segment_id: 1586a525-e250-4003-bae4-819e18e70c0e $ openstack port list --network providernet -f yaml -c "Fixed IP Addresses" - Fixed IP Addresses: - ip_address: deaf:beef:2:0:f816:3eff:fe03:eb71 subnet_id: ec2a9675-a286-4c8b-983d-2f762939cb5b - Fixed IP Addresses: - ip_address: deaf:beef:3:0:f816:3eff:fe48:bb26 subnet_id: c052289a-f8a0-464b-9413-717628fca4c2 - Fixed IP Addresses: - ip_address: deaf:beef:1:0:f816:3eff:fea1:1aab subnet_id: ebae0025-a701-4b22-aa66-00ec48025b30 - Fixed IP Addresses: [] <-- Deffered allocation $ openstack subnet delete subnet3 After deleting subnet3, the port who was on this subnet get's an allocation on subnet_id: ebae0025-a701-4b22-aa66-00ec48025b30 which is not the correct segment for this host. $ openstack port list --network providernet -f yaml -c "Fixed IP Addresses" - Fixed IP Addresses: - ip_address: deaf:beef:2:0:f816:3eff:fe03:eb71 subnet_id: ec2a9675-a286-4c8b-983d-2f762939cb5b - Fixed IP Addresses: - ip_address: deaf:beef:1:0:f816:3eff:fe48:bb26 <-- Allocation on invalid segment. subnet_id: ebae0025-a701-4b22-aa66-00ec48025b30 - Fixed IP Addresses: - ip_address: deaf:beef:1:0:f816:3eff:fea1:1aab subnet_id: ebae0025-a701-4b22-aa66-00ec48025b30 - Fixed IP Addresses: [] I belive the correct behaviour here would be to remove the allocation from the deleted segment and set allocaton 'deferred' on the port. Or raise SubnetInUse exception on subnet delete because there is no other auto-address subnet that can satisfy the in-use port. ** Affects: neutron Importance: Undecided Status: New ** Tags: ipv6 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1865138 Title: When deleting an stateless subnet port can get allocation on subnet with invalid segment Status in neutron: New Bug description: A provider network with 3 stateless subnet, on different segments. (NOTE, this output is from a dev environment with WIP fixes for bug/1864333 and bug/1864333) $ for subnet in $(openstack subnet list --network providernet -f value -c ID); do openstack subnet show $subnet -f yaml -c segment_id -c cidr -c id; done cidr: deaf:beef:3::/64 id: 954a1b8c-5fe7-4dcc-84bd-df24c371e651 segment_id: 632b2bab-5402-4a4d-9433-783d7051d8aa cidr: deaf:beef:1::/64 id: ebae0025-a701-4b22-aa66-00ec48025b30 segment_id: d1930254-36c9-4490-94f7-d095a25cf3b0 cidr: deaf:beef:2::/64 id: ec2a9675-a286-4c8b-983d-2f762939cb5b segment_id: 1586a525-e250-4003-bae4-819e18e70c0e $ openstack port list --network providernet -f yaml -c "Fixed IP Addresses" - Fixed IP Addresses: - ip_address: deaf:beef:2:0:f816:3eff:fe03:eb71 subnet_id: ec2a9675-a286-4c8b-983d-2f762939cb5b - Fixed IP Addresses: - ip_address: deaf:beef:3:0:f816:3eff:fe48:bb26 subnet_id: c052289a-f8a0-464b-9413-717628fca4c2 - Fixed IP Addresses: - ip_address: deaf:beef:1:0:f816:3eff:fea1:1aab subnet_id: ebae0025-a701-4b22-aa66-00ec48025b30 - Fixed IP Addresses: [] <-- Deffered allocation $ openstack subnet delete subnet3 After deleting subnet3, the port who was on this subnet get's an allocation on subnet_id: ebae0025-a701-4b22-aa66-00ec48025b30 which is not the correct segment for this host. $ openstack port list --network providernet -f yaml -c "Fixed IP Addresses" - Fixed IP Addresses: - ip_address: deaf:beef:2:0:f816:3eff:fe03:eb71 subnet_id: ec2a9675-a286-4c8b-983d-2f762939cb5b - Fixed IP Addresses: - ip_address: deaf:beef:1:0:f816:3eff:fe48:bb26 <-- Allocation on invalid segment. subnet_id: ebae0025-a701-4b22-aa66-00ec48025b30 - Fixed IP Addresses: - ip_address: deaf:beef:1:0:f816:3eff:fea1:1aab subnet_id: ebae0025-a701-4b22-aa66-00ec48025b30 - Fixed IP Addresses: [] I belive the correct behaviour here would be to remove the allocation from the deleted segment and set allocaton 'deferred' on the port. Or raise SubnetInUse exception on subnet delete because there is no other auto-address subnet that can satisfy the in-use port. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1865138/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to :
[Yahoo-eng-team] [Bug 1865125] [NEW] block_device_mapping redundancy data when mq not routed
Public bug reported: The volumes_attached has some repetitive volume id when excuting 'openstack server show ', and there are same redundancy data in block_device_mapping table. In this period, not routed error occurred in MQ, and I failed to resize this server. I don't know whether the MQ cause this redundancy data error. ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1865125 Title: block_device_mapping redundancy data when mq not routed Status in OpenStack Compute (nova): New Bug description: The volumes_attached has some repetitive volume id when excuting 'openstack server show ', and there are same redundancy data in block_device_mapping table. In this period, not routed error occurred in MQ, and I failed to resize this server. I don't know whether the MQ cause this redundancy data error. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1865125/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1865121] [NEW] 'openstack token issue' command doesn't issue token for MFA enabled user
Public bug reported: User who has been to configured such that he can only get a token when he presents more than one modes of authentication, say password & totp. In these cases, 'openstack token issue' command gives 401 error as there is no means for providing totp as an argument. Can a option like --totp be added, like 'openstack token issue --totp 123456' so that MFA users can also use this command to generate token? Or is there any other way currently in openstack using which 'openstack token issue' command can be used to generate token for MFA users! like adding some environment variable in openrc & then eexcuting token issue. ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1865121 Title: 'openstack token issue' command doesn't issue token for MFA enabled user Status in OpenStack Identity (keystone): New Bug description: User who has been to configured such that he can only get a token when he presents more than one modes of authentication, say password & totp. In these cases, 'openstack token issue' command gives 401 error as there is no means for providing totp as an argument. Can a option like --totp be added, like 'openstack token issue --totp 123456' so that MFA users can also use this command to generate token? Or is there any other way currently in openstack using which 'openstack token issue' command can be used to generate token for MFA users! like adding some environment variable in openrc & then eexcuting token issue. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1865121/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1865120] [NEW] arm64 vm boot failed when set num_pcie_ports to 28
Public bug reported: We are testing OpenStack on Phytium,FT2000PLUS root@compute01:~# lscpu Architecture: aarch64 Byte Order:Little Endian CPU(s):64 On-line CPU(s) list: 0-63 Thread(s) per core:1 Core(s) per socket:4 Socket(s): 16 NUMA node(s): 8 Model name:Phytium,FT2000PLUS CPU max MHz: 2200. CPU min MHz: 1000. BogoMIPS: 3600.00 NUMA node0 CPU(s): 0-7 NUMA node1 CPU(s): 8-15 NUMA node2 CPU(s): 16-23 NUMA node3 CPU(s): 24-31 NUMA node4 CPU(s): 32-39 NUMA node5 CPU(s): 40-47 NUMA node6 CPU(s): 48-55 NUMA node7 CPU(s): 56-63 Flags: fp asimd evtstrm crc32 The problem we initially met are we are not able to attach to more than 2 volumes (virtio-blk) if config drive enabled. We somehow work around the problem by using scsi-bus instead. But we are still interesting to make plug more than 2 virtio-blk devices possible, and after some investigation I think `num_pcie_ports` might be too small (looks like it default to 9 if unspecified), and `pcie-root` does not allow hot plugging, and `pcie-root-port` does not allow more than 1 slots, so the only way I am thinking to mitigate the problem is to increase this option to maximum. But the current problem is vms with previously working images failed to boot and when I try to virsh console, I only saw the uefi shell console. Maybe this is not a bug for `code`, but I definitely think it is necessary to improve the doc and make it easier to understand these terms. I am glad to provide to additional details if asked. thanks ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1865120 Title: arm64 vm boot failed when set num_pcie_ports to 28 Status in OpenStack Compute (nova): New Bug description: We are testing OpenStack on Phytium,FT2000PLUS root@compute01:~# lscpu Architecture: aarch64 Byte Order:Little Endian CPU(s):64 On-line CPU(s) list: 0-63 Thread(s) per core:1 Core(s) per socket:4 Socket(s): 16 NUMA node(s): 8 Model name:Phytium,FT2000PLUS CPU max MHz: 2200. CPU min MHz: 1000. BogoMIPS: 3600.00 NUMA node0 CPU(s): 0-7 NUMA node1 CPU(s): 8-15 NUMA node2 CPU(s): 16-23 NUMA node3 CPU(s): 24-31 NUMA node4 CPU(s): 32-39 NUMA node5 CPU(s): 40-47 NUMA node6 CPU(s): 48-55 NUMA node7 CPU(s): 56-63 Flags: fp asimd evtstrm crc32 The problem we initially met are we are not able to attach to more than 2 volumes (virtio-blk) if config drive enabled. We somehow work around the problem by using scsi-bus instead. But we are still interesting to make plug more than 2 virtio-blk devices possible, and after some investigation I think `num_pcie_ports` might be too small (looks like it default to 9 if unspecified), and `pcie-root` does not allow hot plugging, and `pcie- root-port` does not allow more than 1 slots, so the only way I am thinking to mitigate the problem is to increase this option to maximum. But the current problem is vms with previously working images failed to boot and when I try to virsh console, I only saw the uefi shell console. Maybe this is not a bug for `code`, but I definitely think it is necessary to improve the doc and make it easier to understand these terms. I am glad to provide to additional details if asked. thanks To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1865120/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
