[Yahoo-eng-team] [Bug 1801919] Re: brctl is obsolete use ip
Adding nova, nova also using brctl for example in the NeutronLinuxBridgeInterfaceDriver , yes, pyroute2 might be an alternative to the ip commands as well, however the bridge create/enslave is not most documented part. ** Also affects: nova 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/1801919 Title: brctl is obsolete use ip Status in neutron: Confirmed Status in OpenStack Compute (nova): New Bug description: bridge-utils (brctl) is obsolete, no modern software should depend on it. Used in: neutron/agent/linux/bridge_lib.py http://man7.org/linux/man-pages/man8/brctl.8.html Please use `ip` for basic bridge operations, than we can drop one obsolete dependency.. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1801919/+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 1802041] [NEW] Failed to publish message to topic 'nova': 'NoneType' object has no attribute '__getitem__'
Public bug reported: Hello, I am an OpenStack user. I have problem when I launched an instance via horizon, I got a notification: Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. (HTTP 500) (Request-ID: req-d5a176bf-4d55-4b07-b405-c5eeb8080b77) Nova API Log: 2018-11-07 10:33:56.795 10976 ERROR oslo.messaging._drivers.impl_rabbit [req-d5a176bf-4d55-4b07-b405-c5eeb8080b77 5fd9267fddb54b638b2129db881353dc b35ae77fe5724f829dd01e0488ca8bc5 - default default] Failed to publish message to topic 'nova': 'NoneType' object has no attribute '__getitem__' 2018-11-07 10:33:56.796 10976 ERROR oslo.messaging._drivers.impl_rabbit [req-d5a176bf-4d55-4b07-b405-c5eeb8080b77 5fd9267fddb54b638b2129db881353dc b35ae77fe5724f829dd01e0488ca8bc5 - default default] Unable to connect to AMQP server on 172.28.0.12:5672 after None tries: 'NoneType' object has no attribute '__getitem__' 2018-11-07 10:33:56.797 10976 ERROR nova.api.openstack.wsgi [req-d5a176bf-4d55-4b07-b405-c5eeb8080b77 5fd9267fddb54b638b2129db881353dc b35ae77fe5724f829dd01e0488ca8bc5 - default default] Unexpected exception in API method: MessageDeliveryFailure: Unable to connect to AMQP server on 172.28.0.12:5672 after None tries: 'NoneType' object has no attribute '__getitem__' 2018-11-07 10:33:56.797 10976 ERROR nova.api.openstack.wsgi Traceback (most recent call last): 2018-11-07 10:33:56.797 10976 ERROR nova.api.openstack.wsgi File "/usr/lib/python2.7/site-packages/nova/api/openstack/wsgi.py", line 788, in wrapped 2018-11-07 10:33:56.797 10976 ERROR nova.api.openstack.wsgi return f(*args, **kwargs) 2018-11-07 10:33:56.797 10976 ERROR nova.api.openstack.wsgi File "/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 108, in wrapper 2018-11-07 10:33:56.797 10976 ERROR nova.api.openstack.wsgi return func(*args, **kwargs) 2018-11-07 10:33:56.797 10976 ERROR nova.api.openstack.wsgi File "/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 108, in wrapper 2018-11-07 10:33:56.797 10976 ERROR nova.api.openstack.wsgi return func(*args, **kwargs) 2018-11-07 10:33:56.797 10976 ERROR nova.api.openstack.wsgi File "/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 108, in wrapper 2018-11-07 10:33:56.797 10976 ERROR nova.api.openstack.wsgi return func(*args, **kwargs) 2018-11-07 10:33:56.797 10976 ERROR nova.api.openstack.wsgi File "/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 108, in wrapper 2018-11-07 10:33:56.797 10976 ERROR nova.api.openstack.wsgi return func(*args, **kwargs) 2018-11-07 10:33:56.797 10976 ERROR nova.api.openstack.wsgi File "/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 108, in wrapper 2018-11-07 10:33:56.797 10976 ERROR nova.api.openstack.wsgi return func(*args, **kwargs) 2018-11-07 10:33:56.797 10976 ERROR nova.api.openstack.wsgi File "/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 108, in wrapper 2018-11-07 10:33:56.797 10976 ERROR nova.api.openstack.wsgi return func(*args, **kwargs) 2018-11-07 10:33:56.797 10976 ERROR nova.api.openstack.wsgi File "/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 108, in wrapper 2018-11-07 10:33:56.797 10976 ERROR nova.api.openstack.wsgi return func(*args, **kwargs) 2018-11-07 10:33:56.797 10976 ERROR nova.api.openstack.wsgi File "/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 108, in wrapper 2018-11-07 10:33:56.797 10976 ERROR nova.api.openstack.wsgi return func(*args, **kwargs) 2018-11-07 10:33:56.797 10976 ERROR nova.api.openstack.wsgi File "/usr/lib/python2.7/site-packages/nova/api/openstack/compute/servers.py", line 554, in create 2018-11-07 10:33:56.797 10976 ERROR nova.api.openstack.wsgi **create_kwargs) 2018-11-07 10:33:56.797 10976 ERROR nova.api.openstack.wsgi File "/usr/lib/python2.7/site-packages/nova/hooks.py", line 154, in inner 2018-11-07 10:33:56.797 10976 ERROR nova.api.openstack.wsgi rv = f(*args, **kwargs) 2018-11-07 10:33:56.797 10976 ERROR nova.api.openstack.wsgi File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 1649, in create 2018-11-07 10:33:56.797 10976 ERROR nova.api.openstack.wsgi tags=tags, supports_multiattach=supports_multiattach) 2018-11-07 10:33:56.797 10976 ERROR nova.api.openstack.wsgi File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 1180, in _create_instance 2018-11-07 10:33:56.797 10976 ERROR nova.api.openstack.wsgi tags=tags) 2018-11-07 10:33:56.797 10976 ERROR nova.api.openstack.wsgi File "/usr/lib/python2.7/site-packages/nova/conductor/api.py", line 136, in schedule_and_build_instances 2018-11-07 10:33:56.797 10976 ERROR nova.api.openstack.wsgi block_device_mapping, tags) 2018-11-07 10:33:56.797 10976 ERROR nova.api.openstack.wsgi File
[Yahoo-eng-team] [Bug 1802035] [NEW] Master branch failing py27 tests (oslo_db.exception.DBNonExistentTable:)
Public bug reported: Description === When working with the latest master branch (commit 002128208cdfb238568acea74a0d8b03492d714d), the py27 tests report 18 failed tests with no changes made to the project/code. The test output is much larger than I remember from other projects (Nova / Cinder) at a whopping 8.9MB (63,634 lines) and ultimately seems to be complaining (repeatedly) with: oslo_db.exception.DBNonExistentTable: (sqlite3.OperationalError) error in trigger federated_user_insert_trigger: no such table: main.migration_tmp [SQL: u'ALTER TABLE federated_user RENAME TO migration_tmp'] (Background on this error at: http://sqlalche.me/e/e3q8) Possible related bug report - https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=909989 Steps to reproduce == virtualenv keystone-venv source keystone-venv/bin/activate pip install tox flake8 sudo zypper in openssl-devel python-devel openldap2-devel sqlite3 git clone https://git.openstack.org/openstack/keystone.git cd keystone pip install -r test-requirements.txt tox -e pep8 # succeeded tox -r -e py27 # failed Expected result === All py27 tests pass Actual result = 18 tests failed Environment === (keystone-venv) cerealkiller@thegibson:~/Desktop/Dev/python/keystone> cat /etc/SUSE-brand openSUSE VERSION = 15.0 (keystone-venv) cerealkiller@thegibson:~/Desktop/Dev/python/keystone> uname -a Linux thegibson 4.18.14-1-default #1 SMP PREEMPT Sat Oct 13 18:49:22 UTC 2018 (ce1c446) x86_64 x86_64 x86_64 GNU/Linux (keystone-venv) cerealkiller@thegibson:~/Desktop/Dev/python/keystone> git show commit 002128208cdfb238568acea74a0d8b03492d714d (HEAD -> master, origin/master, origin/HEAD) Merge: 96a39282a 9c38bb5bd Author: Zuul Date: Tue Nov 6 21:23:19 2018 + Merge "Delete PKI middleware debugging section" (keystone-venv) cerealkiller@thegibson:~/Desktop/Dev/python/keystone> pip list --not-required Package Version - --- bashate 0.6.0 configparser 3.5.0 coverage 4.5.1 flake8-docstrings 0.2.1.post1 freezegun 0.3.11 hacking 0.12.0 lxml 4.2.5 os-testr 1.0.0 oslo.db 4.42.0 oslotest 3.7.0 pip 18.1 psycopg2 2.7.5 pycodestyle 2.4.0 PyMySQL 0.9.2 python-ldap 3.1.0 tempest 19.0.0 tox 3.5.3 WebTest 2.0.32 wheel 0.32.2 (keystone-venv) cerealkiller@thegibson:~/Desktop/Dev/python/keystone> rpm -qa | grep "libopenssl-devel\|python-devel\|openldap2-devel\|sqlite3" libopenssl-devel-1.1.0h-1.1.noarch python-devel-2.7.15-2.1.x86_64 sqlite3-3.25.2-1.1.x86_64 libsqlite3-0-3.25.2-1.1.x86_64 openldap2-devel-2.4.46-37.1.x86_64 ** Affects: keystone Importance: Undecided Status: New ** Attachment added: "tox log" https://bugs.launchpad.net/bugs/1802035/+attachment/5209823/+files/tox-py27.log -- 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/1802035 Title: Master branch failing py27 tests (oslo_db.exception.DBNonExistentTable:) Status in OpenStack Identity (keystone): New Bug description: Description === When working with the latest master branch (commit 002128208cdfb238568acea74a0d8b03492d714d), the py27 tests report 18 failed tests with no changes made to the project/code. The test output is much larger than I remember from other projects (Nova / Cinder) at a whopping 8.9MB (63,634 lines) and ultimately seems to be complaining (repeatedly) with: oslo_db.exception.DBNonExistentTable: (sqlite3.OperationalError) error in trigger federated_user_insert_trigger: no such table: main.migration_tmp [SQL: u'ALTER TABLE federated_user RENAME TO migration_tmp'] (Background on this error at: http://sqlalche.me/e/e3q8) Possible related bug report - https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=909989 Steps to reproduce == virtualenv keystone-venv source keystone-venv/bin/activate pip install tox flake8 sudo zypper in openssl-devel python-devel openldap2-devel sqlite3 git clone https://git.openstack.org/openstack/keystone.git cd keystone pip install -r test-requirements.txt tox -e pep8 # succeeded tox -r -e py27 # failed Expected result === All py27 tests pass Actual result = 18 tests failed Environment === (keystone-venv) cerealkiller@thegibson:~/Desktop/Dev/python/keystone> cat /etc/SUSE-brand openSUSE VERSION = 15.0 (keystone-venv) cerealkiller@thegibson:~/Desktop/Dev/python/keystone> uname -a Linux thegibson 4.18.14-1-default #1 SMP PREEMPT Sat Oct 13 18:49:22 UTC 2018 (ce1c446) x86_64 x86_64 x86_64 GNU/Linux (keystone-venv)
[Yahoo-eng-team] [Bug 1801361] Re: Missing install step for OVS-Self-service networks
Reviewed: https://review.openstack.org/616012 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=f4089680b507153b99cb8c659eec9f2a09ef3aa6 Submitter: Zuul Branch:master commit f4089680b507153b99cb8c659eec9f2a09ef3aa6 Author: Slawek Kaplonski Date: Tue Nov 6 22:40:05 2018 +0100 Add missing step for ovs deploy guides There was missing step about adding underlying interface to the provider bridge in ovs deployment guides. This patch adds this missing step. Change-Id: I2ef5f12c469647d7f197cb5db71692e68d23f718 Closes-Bug: #1801361 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1801361 Title: Missing install step for OVS-Self-service networks Status in neutron: Fix Released Bug description: I am using Openstack Queens release (on Ubuntu 16.04.4 LTS) and attempting to install the OVS mechanism driver for self-service network creation, as per the official documentation in https://docs.openstack.org/neutron/queens/admin/deploy-ovs- selfservice.html - [X] This doc is inaccurate in this way: At step 5 of the network node configuration (https://docs.openstack.org/neutron/queens/admin /deploy-ovs-selfservice.html#network-node), the user is asked to create the OVS provider bridge "br-provider". However, following this step, an instruction to add the provider network interface (in the network node) as a port on "br-provider" is missing. As a result, the router namespace, and consequently the VMs created in a self-service network interfaced with the router, will be unable to communicate with the provider network. - [X] This is a doc addition request. - [X] I have a fix to the document that I can paste below: Following step needs to be added after step 5: ovs-vsctl add-port br-provider PROVIDER_INTERFACE Replace PROVIDER_INTERFACE with the name of the underlying interface that handles provider networks. For example, eth1 --- Release: 12.0.5.dev39 on 2018-10-31 08:00 SHA: af84349a4cca1bb1dbca9d6444f3c50bbe260683 Source: https://git.openstack.org/cgit/openstack/neutron/tree/doc/source/admin/deploy-ovs-selfservice.rst URL: https://docs.openstack.org/neutron/queens/admin/deploy-ovs-selfservice.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1801361/+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 1796824] Re: Port in some type of device_owner should not allow update IP address
Reviewed: https://review.openstack.org/612969 Committed: https://git.openstack.org/cgit/openstack/neutron-lib/commit/?id=cd2c69890b042b0aa3df07de2c53f294e04a390d Submitter: Zuul Branch:master commit cd2c69890b042b0aa3df07de2c53f294e04a390d Author: LIU Yulong Date: Wed Oct 24 17:39:36 2018 +0800 Add shim extension l3-port-ip-change-not-allowed Change-Id: I3578ef48432792aca25acf7c30413d79a0fd4065 Closes-Bug: #1796824 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1796824 Title: Port in some type of device_owner should not allow update IP address Status in neutron: Fix Released Bug description: Some L3 ports can now be directly modify the IP address, but there are some type of device_owner, for instance network:router_centralized_snat, should not allow to change the IP address, otherwise it will make things really complicated. Step to reproduce, update dvr router network:router_centralized_snat port directly: $ openstack port show 85ffe5a3-4332-4864-8ea5-5b13f3c7f63f +---+---+ | Field | Value | +---+---+ | admin_state_up| UP | | allowed_address_pairs | | | binding_host_id | node3 | | binding_profile | | | binding_vif_details | datapath_type='system', ovs_hybrid_plug='False', port_filter='True' | | binding_vif_type | ovs | | binding_vnic_type | normal | | created_at| 2018-09-19T09:48:58Z | | data_plane_status | None | | description | | | device_id | 867e1473-4495-4513-8759-dee4cb1b9cef | | device_owner | network:router_centralized_snat | | dns_assignment| None | | dns_name | None | | extra_dhcp_opts | | | fixed_ips | ip_address='192.168.188.13', subnet_id='0bbb326f-91c7-4030-9425-bc994a25db84' | | id| 85ffe5a3-4332-4864-8ea5-5b13f3c7f63f | | ip_address| None | | mac_address | fa:16:3e:1e:01:f8 | | name | | | network_id| f5c2435f-4096-4b91-8211-e3e22e08233a | | option_name | None | | option_value | None | | port_security_enabled | False | | project_id| | | qos_policy_id | None | | revision_number | 266 | | security_group_ids| | | status| ACTIVE | | subnet_id | None | | tags | | | trunk_details | None
[Yahoo-eng-team] [Bug 1627619] Re: Launch instance only lists snapshots of images not created with a new volume
Reviewed: https://review.openstack.org/548181
Committed:
https://git.openstack.org/cgit/openstack/horizon/commit/?id=5f4057f8b5ebc9909f153f85875c131701f00fd1
Submitter: Zuul
Branch:master
commit 5f4057f8b5ebc9909f153f85875c131701f00fd1
Author: wangliangyu
Date: Mon Feb 26 18:05:25 2018 +0800
Show snapshots list correctly when launching instance
In launch instance modal, when a user selects 'Instance Snapshots',
not all snapshots are listed. The snapshots which are created from
an instance with new volume or an instance created from volume
or volume snapshot don't have 'image_type' but 'block_device_mapping'.
So, judging only by image_type is not enough.
Change-Id: I7e175b6a7260ca3d82560427a8f742f8cfa35565
Closes-Bug: #1627619
** Changed in: horizon
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1627619
Title:
Launch instance only lists snapshots of images not created with a new
volume
Status in OpenStack Dashboard (Horizon):
Fix Released
Bug description:
In launch instance modal, a user can choose a boot source.
When a user select 'Instance Snapshots', snapshots are listed.
However, these snapshots are not all.
At the moment, there are listed only snapshots created from a instance not
creating new volume.
As far as I know, when a user create a snapshot created from a instance with
new volume, it doesn't have image_type.
Instead of this, this has 'block_device_mapping' object. This object has
'source_type' attribute like below.
block_device_mapping='[{"guest_format": null, "boot_index": 0,
"delete_on_termination": false, "no_device": null, "snapshot_id":
"267a6729-056a-42b0-adaf-9d24eaeca67f", "device_name": "/dev/vda", "disk_bus":
"virtio", "image_id": null, "source_type": "snapshot", "tag": null,
"device_type": "disk", "volume_id": null, "destination_type": "volume",
"volume_size": 1}]'
Horizon is judging by only image_type but it seems not to be enough.
ref:properties of snapshots created from a instance with new volume
base_image_ref='', bdm_v2='True', block_device_mapping='[{"guest_format":
null, "boot_index": 0, "delete_on_termination": false, "no_device": null,
"snapshot_id": "267a6729-056a-42b0 |
| | -adaf-9d24eaeca67f", "device_name": "/dev/vda",
"disk_bus": "virtio", "image_id": null, "source_type": "snapshot", "tag": null,
"device_type": "disk", "volume_id": null, |
| | "destination_type": "volume", "volume_size": 1}]',
kernel_id='0dafcdfc-4f80-4bf1-9e78-d4e9c5c8ef8c',
ramdisk_id='baa56d26-6dfd-48c5-8f3d-230d9688de84', root_device_name='/dev/vda'
ref: properties of snapshots created from a instance not creating new volume.
base_image_ref='7c732922-6cb5-4b08-9247-13d4440ee992',
image_location='snapshot', image_state='available', image_type='snapshot',
instance_uuid='355dbfa8-c654-4dc3-a26d-c6b80383d2dd',
kernel_id='0dafcdfc-4f80-4bf1-9e78-d4e9c5c8ef8c',
owner_id='a25277ddba2b48ad969fedac2511ff1f',
ramdisk_id='baa56d26-6dfd-48c5-8f3d-230d9688de84',
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1627619/+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 1798688] Re: iptables_hybrid tests tempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON.test_shelve_shelved_server failed
This happened again: http://logs.openstack.org/26/615126/5/check /tempest-full/69d913a/job-output.txt.gz#_2018-11-06_19_51_54_083047 ** Also affects: nova 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/1798688 Title: iptables_hybrid tests tempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON.test_shelve_shelved_server failed Status in neutron: Incomplete Status in OpenStack Compute (nova): New Bug description: * Job: neutron-tempest-iptables_hybrid * Failed test: tempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON.test_shelve_shelved_server * Example of failure: http://logs.openstack.org/80/610280/8/check/neutron-tempest-iptables_hybrid/caa373a/job-output.txt.gz Details: (ServersNegativeTestJSON:tearDown) Server 7e7cf40f-0ab7-4f22 -91ce-6f4e22a54ac2 failed to reach ACTIVE status and task state "None" within the required time (196 s). Current status: SHELVED_OFFLOADED. Current task state: None. * Logstash: http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22failed%20to%20reach%20ACTIVE%20status%20and%20task%20state%20%5C%5C%5C%22None%5C%5C%5C%22%20within%20the%20required%20time%5C%22 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1798688/+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 1802006] [NEW] Floating IP attach/detach fails for non-admin user and unbound port with router in different tenant
Public bug reported:
Seeing this on pike, but code looks same in master so issue still likely
exists.
We have a shared external network connected to router in TenantA. Now
create a network, either shared in tenantA or owned by tenantB, and
attach to tenantA's router (an admin user will have to do this).
Now suppose a non-admin user in the different tenantB creates a Floating
IP on shared ext network. They then try to attach it to a port. It
passes if the port is bound to a VM. It fails if the port is unbound.
For example, pre-create a port on a network/subnet available to this
tenant, and then try the following /floatingips/ PUT API call. It will
fail. Then bring up a VM on same network, and attach Floating IP to it's
port, this will pass:
curl -k -X PUT -i
https://localhost/neutron/v2.0/floatingips/cc56cbb4-2c3b-4d53-9506-1baaa8e7b2d6
-H "X-Auth-Token: $TOK" -H "Content-Type: application/json" -d '{"floatingip":
{"port_id": "6af4bb1c-85b4-42c0-8b96-6efb90443aa7"}}'
HTTP/1.1 404 Not Found
Server: nginx/1.12.2
Date: Tue, 06 Nov 2018 07:31:54 GMT
Content-Type: application/json
Content-Length: 135
Connection: keep-alive
X-Openstack-Request-Id: req-31b02819-844c-4d41-a471-938f092b4a57
Access-Control-Allow-Credentials: true
{"NeutronError": {"message": "Router b819cfbb-7e8b-4bce-964e-
ec4b29614241 could not be found", "type": "RouterNotFound", "detail":
""}}
curl -k -X PUT -i
https://localhost/neutron/v2.0/floatingips/44361b51-7928-441e-8478-4fd35919e5c3
-H "X-Auth-Token: $TOK" -H "Content-Type: application/json" -d '{"floatingip":
{"port_id": "7ea1b40a-e3b1-490d-8a02-d5e2cf18b89c"}}'
HTTP/1.1 200 OK
Server: nginx/1.12.2
Date: Tue, 06 Nov 2018 07:15:10 GMT
Content-Type: application/json
Content-Length: 584
Connection: keep-alive
X-Openstack-Request-Id: req-50cb5289-fcbb-4a65-91d4-33f59b0f4632
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: X-Subject-Token
{"floatingip": {"router_id": "b819cfbb-7e8b-4bce-964e-ec4b29614241",
"status": "DOWN", "description": "", "tags": [], "updated_at":
"2018-11-06T07:15:09Z", "dns_domain": "", "floating_network_id":
"6580471a-cac0-4f03-ae2e-77ddfb76b181", "fixed_ip_address":
"10.168.1.14", "floating_ip_address": "10.4.252.154", "revision_number":
16, "port_id": "7ea1b40a-e3b1-490d-8a02-d5e2cf18b89c", "id":
"44361b51-7928-441e-8478-4fd35919e5c3", "dns_name": "", "created_at":
"2018-11-06T02:53:23Z", "tenant_id": "5e09d64a521b440e9ffbec28f5fb7de0",
"project_id": "5e09d64a521b440e9ffbec28f5fb7de0"}}
Problem is due to new code which allows binding FIP to unbound ports via
SNAT router, from this diff:
https://github.com/openstack/neutron/commit/9515c771e742a5b6d29b17f84f49a0b39706489b
An additional get_router() call is made here, and it needs the elevated
admin context to be passed in. It fails because default policy for
get_router is admin_or_owner, and it can't fetch the SNAT router in
different tenant. This code path is not hit for a VM port, as it is
bound and has a host:
https://github.com/openstack/neutron/blob/master/neutron/db/l3_dvr_db.py#L1098
which invokes get_router() here:
https://github.com/openstack/neutron/blob/master/neutron/db/l3_hascheduler_db.py#L45
Need to pass in context.elevated() in either one of those 2 places -
thinking the first location might be better?
** Affects: neutron
Importance: Undecided
Status: New
** Description changed:
Seeing this on pike, but code looks same in master so issue still likely
exists.
We have a shared external network connected to router in TenantA. Now
create a network, either shared in tenantA or owned by tenantB, and
attach to tenantA's router (an admin user will have to do this).
Now suppose a non-admin user in the different tenantB creates a Floating
IP on shared ext network. They then try to attach it to a port. It
passes if the port is bound to a VM. It fails if the port is unbound.
For example, pre-create a port on a network/subnet available to this
tenant, and then try the following /floatingips/ PUT API call. It will
fail. Then bring up a VM on same network, and attach Floating IP to it's
port, this will pass:
curl -k -X PUT -i
https://localhost/neutron/v2.0/floatingips/cc56cbb4-2c3b-4d53-9506-1baaa8e7b2d6
-H "X-Auth-Token: $TOK" -H "Content-Type: application/json" -d '{"floatingip":
{"port_id": "6af4bb1c-85b4-42c0-8b96-6efb90443aa7"}}'
HTTP/1.1 404 Not Found
Server: nginx/1.12.2
Date: Tue, 06 Nov 2018 07:31:54 GMT
Content-Type: application/json
Content-Length: 135
Connection: keep-alive
X-Openstack-Request-Id: req-31b02819-844c-4d41-a471-938f092b4a57
Access-Control-Allow-Credentials: true
{"NeutronError": {"message": "Router b819cfbb-7e8b-4bce-964e-
ec4b29614241 could not be found", "type": "RouterNotFound", "detail":
""}}
curl -k -X PUT -i
https://localhost/neutron/v2.0/floatingips/44361b51-7928-441e-8478-4fd35919e5c3
-H "X-Auth-Token: $TOK" -H "Content-Type: application/json" -d
[Yahoo-eng-team] [Bug 1717547] Re: Creating snapshot fails when image metadata has version field
Reviewed: https://review.openstack.org/614351 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=5c21a00e89539bbb271ccfa05e4a2ba1cddae58e Submitter: Zuul Branch:master commit 5c21a00e89539bbb271ccfa05e4a2ba1cddae58e Author: Jay Pipes Date: Tue Nov 6 10:59:40 2018 -0500 prevent common kwargs from glance client failure When creating a snapshot of a server using the nova API, failure occurs if the image contains the metadata property "version". This was due to the way that the GlanceClientWrapper.call() function signature was structured. This patch forces all client positional args to be passed as a named "args" argument to the call() function and all client named args to be pass as a named "kwargs" argument to the call() function. This eliminates any argument name-shadowing that previously caused issues. Closes-bug: #1717547 Change-Id: I3ed3303309fe2a25c0043fd206f36bada4b3b8f9 ** Changed in: nova Status: In Progress => Fix Released -- 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/1717547 Title: Creating snapshot fails when image metadata has version field Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) ocata series: Confirmed Status in OpenStack Compute (nova) pike series: Confirmed Bug description: Description: When creating a snapshot of a server using the nova API, failure occurs if the image contains the metadata property "version". It seems like image metadata is passed as an argument to _create_v2 (nova/image/glance.py) which is then passed to call (nova/image/glance.py) as kwargs. The function already takes in context, method, and version arguments, so it seems that any of these metadata properties would cause the snapshot to fail. OpenStack version : Pike Nova API version : 2.1 Steps to reporduce: 1. Create an image with metadata property "version" 2. Launch an server using this image 3. Try to create a server snapshot of the server you just launched image used: +--++ | Field| Value | +--++ | checksum | d19875d33815bd8c49fe39829b1df924 | | container_format | bare | | created_at | 2017-09-05T15:57:24Z | | disk_format | raw | | file | /v2/images/c7f76154-dd99-4102-afe2-662a4fcaba7b/file | | id | c7f76154-dd99-4102-afe2-662a4fcaba7b | | min_disk | 0 | | min_ram | 0 | | name | ubuntu-16.04-amd64_2 | | owner| 71cea55297f94953b33b2a2549d72a95 | | properties | architecture='amd64', direct_url='rbd://8838dc54-c385-4949-9624-1cf3911320 | | | 1d/images/c7f76154-dd99-4102-afe2-662a4fcaba7b/snap', | | | distribution='Ubuntu', family='Linux', username='ubuntu', version='16.04' | | protected| False | | schema | /v2/schemas/image | | size | 2361393152 | | status | active | | tags | | | updated_at | 2017-09-14T21:10:44Z | | virtual_size | None | | visibility | public | +--++ Expected result: succesfully create server snapshot Actual result: logs: 2017-09-14 19:57:53.486 27 ERROR nova.api.openstack.extensions [req-eea1ec3c-a500-4006-ab4d-00a05a6b4f33 f25d972f420840e48163a55bf5713bf6 c657c15a0a13435bbe2c323c732d4e4f -
[Yahoo-eng-team] [Bug 1800124] Re: internal NotFound error can lead to 500 error in modern devstack setup
Reviewed: https://review.openstack.org/613961
Committed:
https://git.openstack.org/cgit/openstack/keystone/commit/?id=ee490d82262804ce1d6cee301594294733a71b79
Submitter: Zuul
Branch:master
commit ee490d82262804ce1d6cee301594294733a71b79
Author: Morgan Fainberg
Date: Mon Oct 29 08:26:31 2018 -0700
Unregister "Exception" from flask handler
Unregister the default Exception from the flask error handler. This
is to allow flask 404 to bubble up outside of test cases normally with
out raising a 500 error.
Change-Id: I2159952acae0234472ee3fea7f387278cbefa6c3
Closes-Bug: #1800124
** Changed in: keystone
Status: In Progress => Fix Released
--
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/1800124
Title:
internal NotFound error can lead to 500 error in modern devstack setup
Status in OpenStack Identity (keystone):
Fix Released
Bug description:
I'm using a recent devstack in late October 2018, no special keystone
configuration, it is running under uwsgi and apache2.
If I make a request of the service to a bogus URL:
curl -v http://localhost/identity/v3/narf
> GET /identity/v3/narf HTTP/1.1
> Host: localhost
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 500 INTERNAL SERVER ERROR
< Date: Fri, 26 Oct 2018 10:08:34 GMT
< Server: Apache/2.4.29 (Ubuntu)
< Content-Type: application/json
< Content-Length: 138
< Vary: X-Auth-Token
< x-openstack-request-id: req-cfafa26b-75a9-4573-9076-61ff9290c6a7
< Connection: close
<
{"error":{"code":500,"message":"An unexpected error prevented the server from
fulfilling your request.","title":"Internal Server Error"}}
I stumbled upon this because I was experimenting with pulling the
catalog and requests /v3/catalog instead of /v3/services
Which doesn't seem ideal :)
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1800124/+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 1783654] Re: DVR process flow not installed on physical bridge for shared tenant network
This SRU is no longer needed as we're uploading neutron 12.0.5 to bionic (queens) which includes this fix. ** Changed in: cloud-archive/pike Status: Fix Committed => 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/1783654 Title: DVR process flow not installed on physical bridge for shared tenant network Status in Ubuntu Cloud Archive: Fix Released Status in Ubuntu Cloud Archive pike series: Invalid Status in Ubuntu Cloud Archive queens series: Fix Committed Status in Ubuntu Cloud Archive rocky series: Fix Released Status in neutron: Fix Released Status in neutron package in Ubuntu: Fix Released Status in neutron source package in Bionic: Fix Committed Status in neutron source package in Cosmic: Fix Released Bug description: Seems like collateral from https://bugs.launchpad.net/neutron/+bug/1751396 In DVR, the distributed gateway port's IP and MAC are shared in the qrouter across all hosts. The dvr_process_flow on the physical bridge (which replaces the shared router_distributed MAC address with the unique per-host MAC when its the source), is missing, and so is the drop rule which instructs the bridge to drop all traffic destined for the shared distributed MAC. Because of this, we are seeing the router MAC on the network infrastructure, causing it on flap on br-int on every compute host: root@milhouse:~# ovs-appctl fdb/show br-int | grep fa:16:3e:42:a2:ec 11 4 fa:16:3e:42:a2:ec1 root@milhouse:~# ovs-appctl fdb/show br-int | grep fa:16:3e:42:a2:ec 11 4 fa:16:3e:42:a2:ec2 root@milhouse:~# ovs-appctl fdb/show br-int | grep fa:16:3e:42:a2:ec 1 4 fa:16:3e:42:a2:ec0 root@milhouse:~# ovs-appctl fdb/show br-int | grep fa:16:3e:42:a2:ec 11 4 fa:16:3e:42:a2:ec0 root@milhouse:~# ovs-appctl fdb/show br-int | grep fa:16:3e:42:a2:ec 11 4 fa:16:3e:42:a2:ec0 root@milhouse:~# ovs-appctl fdb/show br-int | grep fa:16:3e:42:a2:ec 1 4 fa:16:3e:42:a2:ec0 root@milhouse:~# ovs-appctl fdb/show br-int | grep fa:16:3e:42:a2:ec 1 4 fa:16:3e:42:a2:ec0 root@milhouse:~# ovs-appctl fdb/show br-int | grep fa:16:3e:42:a2:ec 1 4 fa:16:3e:42:a2:ec0 root@milhouse:~# ovs-appctl fdb/show br-int | grep fa:16:3e:42:a2:ec 1 4 fa:16:3e:42:a2:ec1 root@milhouse:~# ovs-appctl fdb/show br-int | grep fa:16:3e:42:a2:ec 11 4 fa:16:3e:42:a2:ec0 root@milhouse:~# ovs-appctl fdb/show br-int | grep fa:16:3e:42:a2:ec 11 4 fa:16:3e:42:a2:ec0 root@milhouse:~# ovs-appctl fdb/show br-int | grep fa:16:3e:42:a2:ec 11 4 fa:16:3e:42:a2:ec0 Where port 1 is phy-br-vlan, connecting to the physical bridge, and port 11 is the correct local qr-interface. Because these dvr flows are missing on br-vlan, pkts w/ source mac ingress into the host and br- int learns it upstream. The symptom is when pinging a VM's floating IP, we see occasional packet loss (10-30%), and sometimes the responses are sent upstream by br-int instead of the qrouter, so the ICMP replies come with fixed IP of the replier since no NAT'ing took place, and on the tenant network rather than external network. When I force net_shared_only to False here, the problem goes away: https://github.com/openstack/neutron/blob/stable/pike/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_dvr_neutron_agent.py#L436 It should we noted we *ONLY* need to do this on our dvr_snat host. The dvr process's are missing on every compute host. But if we shut qrouter on the snat host, FIP functionality works and DVR mac stops flapping on others. Or if we apply fix only to snat host, it works. Perhaps there is something on SNAT node that is unique Ubuntu SRU details: --- [Impact] See above [Test Case] Deploy OpenStack with dvr enabled and then follow the steps above. [Regression Potential] The patches that are backported have already landed upstream in the corresponding stable branches, helping to minimize any regression potential. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1783654/+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 1798690] Re: Live migrate of iscsi-backed VM loses internal network connectivity
i have not looked into this closely but my guess is this could be related to the arp suppression rules used in the dvr case not being updated correctly that said it is just a guess so there may be something more going on here. eric can you try doing a hard reboot of the migrated instance and see if that corrects the connectivity to the internal network ips. it would also be helpful to know if you are using the iptabels firewall or openvswtich firewall and if following the migration the port status and port admin status are active/up? i may not have time to help futher but ill try and check in on this bug again in a few days. from a nova perspective i dont think this is a nova but or os-vif for that matter but i have been investaging live migration related issues this cycle and this is yet another edgecase that apperars to need fixing. ** Changed in: nova Status: New => Opinion -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1798690 Title: Live migrate of iscsi-backed VM loses internal network connectivity Status in neutron: New Status in OpenStack Compute (nova): Opinion Bug description: Description === Note that this may be a Neutron issue, but since it is happening during live migration, I wanted to point it out to the Nova group first, and let them decide whether to include the Neutron group on this ticket. Also note that this may not be related to iSCSI at all - I just don't have access to Ceph-backed VMs at the moment to test. Live migration of a VM that uses an iSCSI-backed volume-based boot disk (no other disks attached) will migrate correctly, including the volume, and DVR router functionality with floating IPs, but internal network connectivity won't work (pings between VMs on the same Neutron network fail). After live migrating the "bad" VM back to the original host, internal networking works again! NOTE - this seems to be only reproducible if you deploy the VMs, do "not" ping between the VMs, migrate one of the VMs, and "then" ping between the VMs. The ping fails in this case. In the case where pings are performed "prior" to migration, the pings succeed! So, it appears that something in Neutron isn't being migrated. I had tested this configuration back in the Liberty days and ran into the same issue, and thought it was possibly a bug that was fixed by now, but it looks like the problem still exists. Note that I'm still looking at logs to determine whether there is good evidence for why/when this happens, but wanted to get a bug report placed in case it was a known issue. Steps to reproduce == Deploy 2 VMs with an internal network, each with floating IPs, with security groups that are not very restrictive (allow everything including pings between VMs and the Internet). In our case, the two VMs were deployed on separate physical hosts. If VM #2 resides on physical host compute002 after deployment, live migrate this VM to physical host compute003 with: openstack server migrate --live compute003 d3d45afb-e913-4cb7-89df-a1c1d51d6339 From VM #2, ping VM #1. There is no ping response. If you perform all of the above, but ping between the VMs "prior" to migration, pings work fine after migrations (hiding the issue). Expected result === Network should function correctly after a migration - pings should work, for example, between VMs. Actual result = Testing with VM to VM pings: pings are lost and connectivity "never" resumes. I deployed the 2 VMs, migrated one of them, and started a ping from one VM to the other, waited 16+ minutes, and pings are still failing. Perform a live migrate of VM #2 back to the original host using: openstack server migrate --live compute002 d3d45afb-e913-4cb7-89df-a1c1d51d6339 and pings start to work again. Perform a live migrate of VM #2 to the same host as VM #1 and pings between VMs "also" work! Environment === stable/rocky deployment with Kolla-Ansible 7.0.0.0rc3devXX (the latest as of October 15th, 2018) and Kolla 7.0.0.0rc3devXX CentOS 7.5 with latest updates as of October 15, 2018. Kernel: Linux 4.18.14-1.el7.elrepo.x86_64 Hypervisor: KVM Storage: Blockbridge (unsupported, but functions the same as other iSCSI based backends) Networking: DVR with OpenVSwitch To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1798690/+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 1792763] Re: tap TX packet drops during high cpu load
the max tx queue lentgh value that is supported by qemu is 1024 seting it to 1 will not help. thisbug does not specify what netwrok backend is being used but i will assume you are using kernel ovs. on thing you could do is to enable multiqueue support. see: https://specs.openstack.org/openstack/nova-specs/specs/liberty/implemented/libvirt-virtiomq.html you could also try enabling hugepages and cpu pinning on the vms to enable better performance. if you have deployed with security groups enable you can also change to the openvswitch security group driver. this will disable hybridge plug and increase performance. assuming you are still seeing packet drops at this point then it indicates that you are exceeded the capasity of kernel ovs and need to consider other netwrok backends such as ovs-dpdk, sriov or vpp. in any case this is a support request not a bug so i am closing as invalid. ** Changed in: nova Status: New => Invalid -- 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/1792763 Title: tap TX packet drops during high cpu load Status in OpenStack Compute (nova): Invalid Bug description: We are running openstack and hypervisor is qemu-kvm and noticed during peak 50% packet loss on tap interface of instance. I have found in google increase txqueue will solve this issue but in my case after increase to 1 i am still seeing same issue. I have 32 core compute node and i didn't reserve any CPU core for hypervisor and i am running 2 vm instance with 15 vCPU core to each. OS: centos7.5 Kernel: 3.10.0-862.11.6.el7.x86_64 [root@ostack-compute-33 ~]# ifconfig tap5af7f525-5f | grep -i drop RX errors 0 dropped 0 overruns 0 frame 0 TX errors 0 dropped 2528788837 overruns 0 carrier 0 collisions 0 what else i should try? To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1792763/+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 1801930] [NEW] Functional test test_ha_router_namespace_has_ipv6_forwarding_disabled failing quite often
Public bug reported: Functional test neutron.tests.functional.agent.l3.test_ha_router.LinuxBridgeL3HATestCase. test_ha_router_namespace_has_ipv6_forwarding_disabled is failing quite often in the gate. Example of failure: http://logs.openstack.org/37/610737/2/gate/neutron- functional/286402b/logs/testr_results.html.gz Failure stack trace: Traceback (most recent call last): File "neutron/tests/base.py", line 151, in func return f(self, *args, **kwargs) File "neutron/tests/base.py", line 151, in func return f(self, *args, **kwargs) File "neutron/tests/functional/agent/l3/test_ha_router.py", line 365, in test_ha_router_namespace_has_ipv6_forwarding_disabled namespace=router.ns_name)) File "/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/testtools/testcase.py", line 411, in assertEqual self.assertThat(observed, matcher, message) File "/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/testtools/testcase.py", line 498, in assertThat raise mismatch_error testtools.matchers._impl.MismatchError: 1 != 0 It happens on stable branches and on master. ** Affects: neutron Importance: High Assignee: Slawek Kaplonski (slaweq) Status: Confirmed ** Tags: functional-tests gate-failure -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1801930 Title: Functional test test_ha_router_namespace_has_ipv6_forwarding_disabled failing quite often Status in neutron: Confirmed Bug description: Functional test neutron.tests.functional.agent.l3.test_ha_router.LinuxBridgeL3HATestCase. test_ha_router_namespace_has_ipv6_forwarding_disabled is failing quite often in the gate. Example of failure: http://logs.openstack.org/37/610737/2/gate /neutron-functional/286402b/logs/testr_results.html.gz Failure stack trace: Traceback (most recent call last): File "neutron/tests/base.py", line 151, in func return f(self, *args, **kwargs) File "neutron/tests/base.py", line 151, in func return f(self, *args, **kwargs) File "neutron/tests/functional/agent/l3/test_ha_router.py", line 365, in test_ha_router_namespace_has_ipv6_forwarding_disabled namespace=router.ns_name)) File "/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/testtools/testcase.py", line 411, in assertEqual self.assertThat(observed, matcher, message) File "/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/testtools/testcase.py", line 498, in assertThat raise mismatch_error testtools.matchers._impl.MismatchError: 1 != 0 It happens on stable branches and on master. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1801930/+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 1801919] [NEW] brctl is obsolete use ip
Public bug reported: bridge-utils (brctl) is obsolete, no modern software should depend on it. Used in: neutron/agent/linux/bridge_lib.py http://man7.org/linux/man-pages/man8/brctl.8.html Please use `ip` for basic bridge operations, than we can drop one obsolete dependency.. ** 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/1801919 Title: brctl is obsolete use ip Status in neutron: New Bug description: bridge-utils (brctl) is obsolete, no modern software should depend on it. Used in: neutron/agent/linux/bridge_lib.py http://man7.org/linux/man-pages/man8/brctl.8.html Please use `ip` for basic bridge operations, than we can drop one obsolete dependency.. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1801919/+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 1801904] [NEW] Server concepts in nova
Public bug reported: This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [x] This doc is inaccurate in this way: GET /servers/detail?locked=1 The 'locked'query parameter is not supported. It should be replaced with another query parameter. https://github.com/openstack/nova/blob/c64b03d218c4d05b9db47eaf7660cdab9baa6468/nova/api/openstack/compute/schemas/servers.py#L548-L636 - [ ] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. If you have a troubleshooting or support issue, use the following resources: - Ask OpenStack: http://ask.openstack.org - The mailing list: http://lists.openstack.org - IRC: 'openstack' channel on Freenode --- Release: 18.1.0.dev690 on 2018-11-06 09:00 SHA: 90b96170d3f269165f649e8b61739cf31ffb78b8 Source: https://git.openstack.org/cgit/openstack/nova/tree/api-guide/source/server_concepts.rst URL: https://developer.openstack.org/api-guide/compute/server_concepts.html ** Affects: nova Importance: Undecided Assignee: Takashi NATSUME (natsume-takashi) Status: New ** Tags: api-guide doc -- 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/1801904 Title: Server concepts in nova Status in OpenStack Compute (nova): New Bug description: This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [x] This doc is inaccurate in this way: GET /servers/detail?locked=1 The 'locked'query parameter is not supported. It should be replaced with another query parameter. https://github.com/openstack/nova/blob/c64b03d218c4d05b9db47eaf7660cdab9baa6468/nova/api/openstack/compute/schemas/servers.py#L548-L636 - [ ] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. If you have a troubleshooting or support issue, use the following resources: - Ask OpenStack: http://ask.openstack.org - The mailing list: http://lists.openstack.org - IRC: 'openstack' channel on Freenode --- Release: 18.1.0.dev690 on 2018-11-06 09:00 SHA: 90b96170d3f269165f649e8b61739cf31ffb78b8 Source: https://git.openstack.org/cgit/openstack/nova/tree/api-guide/source/server_concepts.rst URL: https://developer.openstack.org/api-guide/compute/server_concepts.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1801904/+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 1801897] [NEW] List AVZs can take several seconds
Public bug reported:
Getting the list of AVZs can take several seconds (~30 secs. in our case)
This is noticeable in Horizon when creating a new instance because the user
can't select an AVZ until this completes.
workflow:
- get all services from all cells (~1 for us)
- fetch all aggregates which are tagged as an AVZ
- construct a dict of {'service['host']: avz.value}
- return a dict of {'avz_value': list of hosts}
- separate available and not available zones.
Reproducible in Queens, Rocky
** 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/1801897
Title:
List AVZs can take several seconds
Status in OpenStack Compute (nova):
New
Bug description:
Getting the list of AVZs can take several seconds (~30 secs. in our case)
This is noticeable in Horizon when creating a new instance because the user
can't select an AVZ until this completes.
workflow:
- get all services from all cells (~1 for us)
- fetch all aggregates which are tagged as an AVZ
- construct a dict of {'service['host']: avz.value}
- return a dict of {'avz_value': list of hosts}
- separate available and not available zones.
Reproducible in Queens, Rocky
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1801897/+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 1791678] Re: Nested virtualization (aka CPU extra flags revisited)
** Changed in: openstack-publiccloud-wg Status: New => Fix Released -- 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/1791678 Title: Nested virtualization (aka CPU extra flags revisited) Status in OpenStack Compute (nova): Fix Released Status in OpenStack Public Cloud WG: Fix Released Bug description: We should contribute some authoritative documentation on how to configure nested virtualization in a way that (a) doesn't break live migration, (b) does not tank guest performance because of Spectre/Meltdown. Since https://review.openstack.org/#/c/534384/, we have the ability to set, in nova.conf: [libvirt] cpu_mode = custom cpu_model = IvyBridge cpu_model_extra_flags = It is my understanding that deployers should always set the pcid flag so that Spectre/Meltdown mitigation patches don't kill guest performance. Deployers who want to also enable nested virtualization should enable pcid,vmx (which is only available from Rocky forward — in prior releases pcid is the only available option for reasons discussed in that Gerrit change). This is already documented, albeit only deeply buried in the Nova configuration reference. I think it would be good to have a paragraph in the admin guide as well that simply explains how to enable nested virtualization, and what to consider. In particular, that enabling nested virtualization breaks live migration for guests that are themselves running guests, which tends to not be very widely known among OpenStack users. Related links: https://review.openstack.org/#/c/534384/ https://docs.openstack.org/nova/rocky/configuration/config.html#libvirt.cpu_model_extra_flags https://docs.openstack.org/nova/rocky/admin/index.html https://www.linux-kvm.org/page/Nested_Guests To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1791678/+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
