[Yahoo-eng-team] [Bug 1811905] [NEW] Deffered IP allocation, port update with binding_host_id + set new mac address fails
Public bug reported:
On a routed provider network IP allocation will be deffered if
insufficent binding information is available.
When a port is updated with binding_host_id only this works as expected:
$ openstack port create --network ctlplane testport -f yaml
admin_state_up: UP
allowed_address_pairs: ''
binding_host_id: ''
binding_profile: ''
binding_vif_details: ''
binding_vif_type: unbound
binding_vnic_type: normal
created_at: '2019-01-16T00:13:19Z'
data_plane_status: null
description: ''
device_id: ''
device_owner: ''
dns_assignment: null
dns_domain: null
dns_name: null
extra_dhcp_opts: ''
fixed_ips: ''
id: 9e05e8fe-c11a-4682-ba69-2a402094758d
mac_address: fa:16:3e:31:de:01
name: testport
network_id: 1f731773-6dcf-45ce-aa11-aaf205f2faf6
port_security_enabled: true
project_id: 9d8aea1921f04207b35a9e1fc4923ae1
qos_policy_id: null
revision_number: 1
security_group_ids: 2354cbbe-5726-42ef-8b45-e642cb9bf2ea
status: DOWN
tags: ''
trunk_details: null
updated_at: '2019-01-16T00:13:19Z'
$ openstack port set --host 05a94a66-27ca-4642-ad62-8f53827055c7
testport
$ openstack port show testport -f yaml
admin_state_up: UP
allowed_address_pairs: ''
binding_host_id: 05a94a66-27ca-4642-ad62-8f53827055c7
binding_profile: ''
binding_vif_details: ''
binding_vif_type: binding_failed
binding_vnic_type: normal
created_at: '2019-01-16T00:13:19Z'
data_plane_status: null
description: ''
device_id: ''
device_owner: ''
dns_assignment: null
dns_domain: null
dns_name: null
extra_dhcp_opts: ''
fixed_ips: ip_address='172.20.0.11',
subnet_id='61745187-973c-4515-a025-c719776bbf44'
id: 9e05e8fe-c11a-4682-ba69-2a402094758d
mac_address: fa:16:3e:31:de:01
name: testport
network_id: 1f731773-6dcf-45ce-aa11-aaf205f2faf6
port_security_enabled: true
project_id: 9d8aea1921f04207b35a9e1fc4923ae1
qos_policy_id: null
revision_number: 3
security_group_ids: 2354cbbe-5726-42ef-8b45-e642cb9bf2ea
status: DOWN
tags: ''
trunk_details: null
updated_at: '2019-01-16T00:13:58Z'
2019-01-16 01:13:58.064 38 DEBUG neutron.api.v2.base
[req-3baa886c-f409-4a2f-82b4-a46055e6653b 944d2af27c0e4e41bc8203acf9b4e6fb
9d8aea1921f04207b35a9e1fc4923ae1 - default default] Request body: {u'port':
{u'binding:host_id':
u'05a94a66-27ca-4642-ad62-8f53827055c7'}} prepare_request_body
/usr/lib/python2.7/site-packages/neutron/api/v2/base.py:715
2019-01-16 01:13:58.310 38 DEBUG neutron.db.db_base_plugin_common
[req-3baa886c-f409-4a2f-82b4-a46055e6653b 944d2af27c0e4e41bc8203acf9b4e6fb
9d8aea1921f04207b35a9e1fc4923ae1 - default default] Allocated IP 172.20.0.11
(1f731
773-6dcf-45ce-aa11-aaf205f2faf6/61745187-973c-4515-a025-c719776bbf44/9e05e8fe-c11a-4682-ba69-2a402094758d)
_store_ip_allocation
/usr/lib/python2.7/site-packages/neutron/db/db_base_plugin_common.py:124
When a port update request contain both binding_host_id and a new mac address,
IP allocation does not happen:
--
$ openstack port create --network ctlplane testport -f yaml
admin_state_up: UP
allowed_address_pairs: ''
binding_host_id: ''
binding_profile: ''
binding_vif_details: ''
binding_vif_type: unbound
binding_vnic_type: normal
created_at: '2019-01-16T00:15:35Z'
data_plane_status: null
description: ''
device_id: ''
device_owner: ''
dns_assignment: null
dns_domain: null
dns_name: null
extra_dhcp_opts: ''
fixed_ips: ''
id: 3c6ecca2-3f77-4528-86c2-66971c89ef2e
mac_address: fa:16:3e:aa:f4:46
name: testport
network_id: 1f731773-6dcf-45ce-aa11-aaf205f2faf6
port_security_enabled: true
project_id: 9d8aea1921f04207b35a9e1fc4923ae1
qos_policy_id: null
revision_number: 1
security_group_ids: 2354cbbe-5726-42ef-8b45-e642cb9bf2ea
status: DOWN
tags: ''
trunk_details: null
updated_at: '2019-01-16T00:15:35Z'
$ openstack port set --host 05a94a66-27ca-4642-ad62-8f53827055c7 --mac-
address 52:54:00:76:4f:56 testport
$ openstack port show testport -f yaml
admin_state_up: UP
allowed_address_pairs: ''
binding_host_id: 05a94a66-27ca-4642-ad62-8f53827055c7
binding_profile: ''
binding_vif_details: ''
binding_vif_type: binding_failed
binding_vnic_type: normal
created_at: '2019-01-16T00:15:35Z'
data_plane_status: null
description: ''
device_id: ''
device_owner: ''
dns_assignment: null
dns_domain: null
dns_name: null
extra_dhcp_opts: ''
fixed_ips: ''
id: 3c6ecca2-3f77-4528-86c2-66971c89ef2e
mac_address: 52:54:00:76:4f:56
name: testport
network_id: 1f731773-6dcf-45ce-aa11-aaf205f2faf6
port_security_enabled: true
project_id: 9d8aea1921f04207b35a9e1fc4923ae1
qos_policy_id: null
revision_number: 3
security_group_ids: 2354cbbe-5726-42ef-8b45-e642cb9bf2ea
status: DOWN
tags: ''
trunk_details: null
updated_at: '2019-01-16T00:15:46Z'
2019-01-16 01:15:45.684 39 DEBUG neutron.api.v2.base
[req-8373dd06-d3fe-4fdc-841e-3850ec6eb374 944d2af27c0e4e41bc8203acf9b4e6fb
9d8aea1921f04207b35a9e1fc4923ae1 - default default] Request body: {u'port':
{u'binding:host_id':
u'05a94a66-27ca-4642-ad62-8f53827055c7', u'mac_address':
[Yahoo-eng-team] [Bug 1811740] Re: neutron qos_plugin AttributeError: 'NoneType' object has no attribute 'qos_policy_id'
** Description changed: - In python 3.5 congress dsvm gate job, neutron qos plugin experiences the - following error: + In congress dsvm gate job, neutron qos plugin began experiencing the + following error (master branch neutron==14.0.0.0b2.dev52): - ERROR neutron.pecan_wsgi.hooks.translation [None req-4bb47849-a723-4366-be41-b5753ff57fdc admin admin] GET failed.: AttributeError: 'NoneType' object has no attribute 'qos_policy_id' + ERROR neutron.pecan_wsgi.hooks.translation [None req-7b3d042a-af94-419c-ab38-a698bfcc77f5 tempest-TestNeutronV2Driver-1133229655 tempest-TestNeutronV2Driver-1133229655] GET failed.: AttributeError: 'NoneType' object has no attribute 'qos_policy_id' [...] ERROR oslo_messaging.rpc.server File "/opt/stack/new/neutron/neutron/services/qos/qos_plugin.py", line 102, in _extend_port_resource_request ERROR oslo_messaging.rpc.server if net.qos_policy_id: ERROR oslo_messaging.rpc.server AttributeError: 'NoneType' object has no attribute 'qos_policy_id' + [http://logs.openstack.org/74/621974/2/check/congress-devstack-api-mysql/8c0dd86/logs/screen-q-svc.txt.gz?level=ERROR#_Jan_15_20_07_10_822453] - http://logs.openstack.org/91/630091/2/check/congress-devstack-py35-api- - mysql/6797e81/logs/screen-q-svc.txt.gz?level=ERROR + The timing and the file suggests the error may have something to do with this recent neutron merge: + https://github.com/openstack/neutron/commit/83eb3e16138cbf3cd2df723020c07ac2f65c88ce + + All environmental information is available here: http://logs.openstack.org/74/621974/2/check/congress-devstack-api-mysql/8c0dd86/ + http://logs.openstack.org/74/621974/2/check/congress-devstack-api-mysql/8c0dd86/zuul-info/zuul-info.primary.txt + + Additional logs are available here: + http://logs.openstack.org/74/621974/2/check/congress-devstack-api-mysql/8c0dd86/logs/ ** Also affects: neutron Importance: Undecided Status: New ** Summary changed: - neutron qos_plugin AttributeError: 'NoneType' object has no attribute 'qos_policy_id' + neutron GET ports 500 error: 'NoneType' object has no attribute 'qos_policy_id' -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1811740 Title: neutron GET ports 500 error: 'NoneType' object has no attribute 'qos_policy_id' Status in congress: New Status in neutron: New Bug description: In congress dsvm gate job, neutron qos plugin began experiencing the following error (master branch neutron==14.0.0.0b2.dev52): ERROR neutron.pecan_wsgi.hooks.translation [None req-7b3d042a-af94-419c-ab38-a698bfcc77f5 tempest-TestNeutronV2Driver-1133229655 tempest-TestNeutronV2Driver-1133229655] GET failed.: AttributeError: 'NoneType' object has no attribute 'qos_policy_id' [...] ERROR oslo_messaging.rpc.server File "/opt/stack/new/neutron/neutron/services/qos/qos_plugin.py", line 102, in _extend_port_resource_request ERROR oslo_messaging.rpc.server if net.qos_policy_id: ERROR oslo_messaging.rpc.server AttributeError: 'NoneType' object has no attribute 'qos_policy_id' [http://logs.openstack.org/74/621974/2/check/congress-devstack-api-mysql/8c0dd86/logs/screen-q-svc.txt.gz?level=ERROR#_Jan_15_20_07_10_822453] The timing and the file suggests the error may have something to do with this recent neutron merge: https://github.com/openstack/neutron/commit/83eb3e16138cbf3cd2df723020c07ac2f65c88ce All environmental information is available here: http://logs.openstack.org/74/621974/2/check/congress-devstack-api-mysql/8c0dd86/ http://logs.openstack.org/74/621974/2/check/congress-devstack-api-mysql/8c0dd86/zuul-info/zuul-info.primary.txt Additional logs are available here: http://logs.openstack.org/74/621974/2/check/congress-devstack-api-mysql/8c0dd86/logs/ To manage notifications about this bug go to: https://bugs.launchpad.net/congress/+bug/1811740/+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 1811897] [NEW] Useful image properties in glance - hw_disk_bus is also used by the vmware driver
Public bug reported: - [x] This doc is inaccurate in this way: The docs say that the hw_disk_bus property is only used by the libvirt driver but it's also used by the vmware API driver: https://github.com/openstack/nova/blob/89c2d1056b3f37bad243c7468d974ded71336a0f/nova/virt/vmwareapi/images.py#L152 --- Release: on 2018-11-19 14:34:37 SHA: 437ba3ee9b361b33e8918b804bd35f25a722457c Source: https://git.openstack.org/cgit/openstack/glance/tree/doc/source/admin/useful-image-properties.rst URL: https://docs.openstack.org/glance/latest/admin/useful-image-properties.html ** Affects: glance Importance: Undecided Status: New ** Tags: documentation -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1811897 Title: Useful image properties in glance - hw_disk_bus is also used by the vmware driver Status in Glance: New Bug description: - [x] This doc is inaccurate in this way: The docs say that the hw_disk_bus property is only used by the libvirt driver but it's also used by the vmware API driver: https://github.com/openstack/nova/blob/89c2d1056b3f37bad243c7468d974ded71336a0f/nova/virt/vmwareapi/images.py#L152 --- Release: on 2018-11-19 14:34:37 SHA: 437ba3ee9b361b33e8918b804bd35f25a722457c Source: https://git.openstack.org/cgit/openstack/glance/tree/doc/source/admin/useful-image-properties.rst URL: https://docs.openstack.org/glance/latest/admin/useful-image-properties.html To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1811897/+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 1811886] [NEW] Overcommit allowed for pinned instances when using hugepages
Public bug reported: When working on a fix for bug 181097, it was noted that the check to ensure pinned instances do not overcommit was not pagesize aware. This means if an instance without hugepages boots on a host with a large number of hugepages allocated, it may not get all of the memory allocated to it. The solution seems to be to make the check pagesize aware. Test cases to prove this is the case are provided below. --- # Host information The memory capacity (and some other stuff) for our node: $ virsh capabilities | xmllint --xpath '/capabilities/host/topology/cells' - 16298528 3075208 4000 0 ... 16512884 3128797 4000 0 ... Clearly there are not 3075208 and 3128797 4k pages on NUMA nodes 0 and 1, respectively, since, for NUMA node 0, (3075208 * 4) + (4000 * 2048) != 16298528. We use [1] to resolve this. Instead we have 16298528 - (4000 * 2048) = 8106528 KiB memory (or 7.93 GiB) for NUMA cell 0 and something similar for cell 1. To make things easier, cell 1 is totally disabled by adding the following to 'nova-cpu.conf': [DEFAULT] vcpu_pin_set = 0-5,12-17 [1] https://review.openstack.org/631038 For all test cases I create the flavor then try to create two servers with the same flavor. # Test A, unpinned, implicit small pages, oversubscribed. This should work because we're not using a specific page size. $ openstack flavor create --vcpu 2 --disk 0 --ram 7168 test.numa $ openstack flavor set test.numa --property hw:numa_nodes=1 $ openstack server create --flavor test.numa --image cirros-0.3.6-x86_64-disk --wait test1 $ openstack server create --flavor test.numa --image cirros-0.3.6-x86_64-disk --wait test2 Expect: SUCCESS Actual: SUCCESS # Test B, unpinned, explicit small pages, oversubscribed This should fail because we are request a specific page size, though that size is small pages (4k). $ openstack flavor create --vcpu 2 --disk 0 --ram 7168 test.numa $ openstack flavor set test.numa --property hw:numa_nodes=1 $ openstack flavor set test.numa --property hw:mem_page_size=small $ openstack server create --flavor test.numa --image cirros-0.3.6-x86_64-disk --wait test1 $ openstack server create --flavor test.numa --image cirros-0.3.6-x86_64-disk --wait test2 Expect: FAILURE Actual: FAILURE # Test C, pinned, implicit small pages, oversubscribed This should fail because we don't allow oversubscription with CPU pinning. $ openstack flavor create --vcpu 2 --disk 0 --ram 7168 test.pinned $ openstack flavor set test.pinned --property hw:cpu_policy=dedicated $ openstack server create --flavor test.pinned --image cirros-0.3.6-x86_64-disk --wait test1 $ openstack server create --flavor test.pinned --image cirros-0.3.6-x86_64-disk --wait test2 Expect: FAILURE Actual: SUCCESS Interestingly, this fails on the third VM. This is likely because the total memory for that cell, 16298528 KiB, is sufficient to handle two instances but not three. # Test D, pinned, explicit small pages, oversubscribed This should fail because we don't allow oversubscription with CPU pinning. $ openstack flavor create --vcpu 2 --disk 0 --ram 7168 test.pinned $ openstack flavor set test.pinned --property hw:cpu_policy=dedicated $ openstack flavor set test.pinned --property hw:mem_page_size=small $ openstack server create --flavor test.pinned --image cirros-0.3.6-x86_64-disk --wait test1 $ openstack server create --flavor test.pinned --image cirros-0.3.6-x86_64-disk --wait test2 Expect: FAILURE Actual: FAILURE ** Affects: nova Importance: Undecided Assignee: Stephen Finucane (stephenfinucane) Status: In Progress -- 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/1811886 Title: Overcommit allowed for pinned instances when using hugepages Status in OpenStack Compute (nova): In Progress Bug description: When working on a fix for bug 181097, it was noted that the check to ensure pinned instances do not overcommit was not pagesize aware. This means if an instance without hugepages boots on a host with a large number of hugepages allocated, it may not get all of the memory allocated to it. The solution seems to be to make the check pagesize aware. Test cases to prove this is the case are provided below. --- # Host information The memory capacity (and some other stuff) for our node: $ virsh capabilities | xmllint --xpath '/capabilities/host/topology/cells' - 16298528 3075208 4000 0 ... 16512884 3128797 4000 0 ... Clearly there are not 3075208 and 3128797 4k pages on NUMA nodes 0 and 1,
[Yahoo-eng-team] [Bug 1724895] Re: MTU not applied on private ethernet interfaces
Marking this invalid for cloud-init per netplan symptoms 'fixed' in https://bugs.launchpad.net/netplan/+bug/1807273 look like it might be the same case here with no change to cloud-init ** Changed in: cloud-init Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1724895 Title: MTU not applied on private ethernet interfaces Status in cloud-init: Invalid Status in netplan: Fix Committed Status in netplan.io package in Ubuntu: Triaged Status in nplan package in Ubuntu: Won't Fix Bug description: == cloud-init query == Cloud-init isn't adding MAC addresses in the match stanza for various network interfaces in /etc/netplan/50-cloud-init.yaml, which is leading to unexpected results. Is there any reason this would happen? == Original Description == Running nplan 0.30 on Ubuntu 17.10. From what I can tell, the ethernets/interface/mtu field isn't applied when testing against a private ethernet adapter. Using a netplan yaml file (/etc/netplan/10-ens7.yaml): --- network: version: 2 renderer: networkd ethernets: ens7: mtu: 1450 dhcp4: no addresses: [10.99.0.13/16] --- Then running "netplan apply" (or rebooting), yields the following: --- 6: ens7: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:2a:19:bc brd ff:ff:ff:ff:ff:ff inet 10.99.0.13/16 brd 10.99.255.255 scope global ens7 valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fe2a:19bc/64 scope link valid_lft forever preferred_lft forever --- Is this a bug in netplan, or am I misunderstanding the YAML syntax? Best, Andrew To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1724895/+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 1802075] Re: Fix bug that causes failure due to reporting ready using torn down dhcp lease info
** Changed in: cloud-init Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1802075 Title: Fix bug that causes failure due to reporting ready using torn down dhcp lease info Status in cloud-init: Fix Released Bug description: When Azure reports ready after reprovision, we use a torn down lease, causing several minutes of retry and ultimately failure. Get new lease using ephemeral dhcp when reporting ready, or reuse the existing lease without tearing down the ephemeral nic. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1802075/+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 1811873] [NEW] get_l3_agent_with_min_routers fails with postgresql backend
Public bug reported: We have our own L3 agent that uses the generic neutron function get_l3_agent_with_min_routers, rendering following exception if using a postgresql backend: 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource File "/var/lib/openstack/local/lib/python2.7/site-packages/neutron/db/l3_agentschedulers_db.py", line 469, in get_l3_agent_with_min_routers 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource context, agent_ids) 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource File "/var/lib/openstack/local/lib/python2.7/site-packages/neutron/objects/agent.py", line 102, in get_l3_agent_with_min_routers 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource res = query.filter(agent_model.Agent.id.in_(agent_ids)).first() 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource File "/var/lib/openstack/local/lib/python2.7/site-packages/sqlalchemy/orm/query.py", line 2778, in first 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource ret = list(self[0:1]) 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource File "/var/lib/openstack/local/lib/python2.7/site-packages/sqlalchemy/orm/query.py", line 2570, in __getitem__ 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource return list(res) 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource File "/var/lib/openstack/local/lib/python2.7/site-packages/sqlalchemy/orm/query.py", line 2878, in __iter__ 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource return self._execute_and_instances(context) 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource File "/var/lib/openstack/local/lib/python2.7/site-packages/sqlalchemy/orm/query.py", line 2901, in _execute_and_instances 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource result = conn.execute(querycontext.statement, self._params) 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource File "/var/lib/openstack/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", line 948, in execute 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource return meth(self, multiparams, params) 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource File "/var/lib/openstack/local/lib/python2.7/site-packages/sqlalchemy/sql/elements.py", line 269, in _execute_on_connection 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource return connection._execute_clauseelement(self, multiparams, params) 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource File "/var/lib/openstack/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", line 1060, in _execute_clauseelement 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource compiled_sql, distilled_params 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource File "/var/lib/openstack/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", line 1200, in _execute_context 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource context) 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource File "/var/lib/openstack/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", line 1409, in _handle_dbapi_exception 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource util.raise_from_cause(newraise, exc_info) 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource File "/var/lib/openstack/local/lib/python2.7/site-packages/sqlalchemy/util/compat.py", line 203, in raise_from_cause 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource reraise(type(exception), exception, tb=exc_tb, cause=cause) 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource File "/var/lib/openstack/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", line 1193, in _execute_context 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource context) 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource File "/var/lib/openstack/local/lib/python2.7/site-packages/sqlalchemy/engine/default.py", line 507, in do_execute 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource cursor.execute(statement, parameters) 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource DBError: (psycopg2.ProgrammingError) column "agents.agent_type" must appear in the GROUP BY clause or be used in an aggregate function 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource LINE 1: SELECT agents.id AS agents_id, agents.agent_type AS agents_a... 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource ^ 2019-01-15 16:34:33,091.091 59 ERROR neutron.api.v2.resource [SQL: 'SELECT agents.id AS agents_id, agents.agent_type AS agents_agent_type, agents."binary" AS agents_binary, agents.topic AS agents_topic, agents.host AS agents_host, agents.availability_zone AS agents_availability_zone, agents.admin_state_up AS agents_admin_state_up, agents.created_at AS
[Yahoo-eng-team] [Bug 1811870] [NEW] libvirt reporting incorrect value of 4k (small) pages
Public bug reported: libvirt < 4.3.0 had an issue whereby assigning more than 4 GB of huge pages would result in an incorrect value for the number of 4k (small) pages. This was tracked and fixed via rhbz#1569678 and the fixes appear to have been backported to the libvirt versions for RHEL 7.4+. However, this is still an issue with the versions of libvirt available on Ubuntu 16.04, 18.04 and who knows what else. We should either alert the user that the bug exists or, better again, work around the issue using the rest of the (correct) values for different page sizes. # Incorrect value (Ubuntu 16.04, libvirt 4.0.0) $ virsh capabilities | xmllint --xpath /capabilities/host/topology/cells/cell[1] - 16298528 3075208 4000 0 ... (3075208 * 4) + (4000 * 2048) != 16298528 # Correct values (Fedora ??, libvirt 4.10) $ virsh capabilities | xmllint --xpath /capabilities/host/topology/cells/cell[1] - 32359908 8038777 100 0 ... (8038777 * 4) + (100 * 2048) == 32359908 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1569678 ** 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/1811870 Title: libvirt reporting incorrect value of 4k (small) pages Status in OpenStack Compute (nova): New Bug description: libvirt < 4.3.0 had an issue whereby assigning more than 4 GB of huge pages would result in an incorrect value for the number of 4k (small) pages. This was tracked and fixed via rhbz#1569678 and the fixes appear to have been backported to the libvirt versions for RHEL 7.4+. However, this is still an issue with the versions of libvirt available on Ubuntu 16.04, 18.04 and who knows what else. We should either alert the user that the bug exists or, better again, work around the issue using the rest of the (correct) values for different page sizes. # Incorrect value (Ubuntu 16.04, libvirt 4.0.0) $ virsh capabilities | xmllint --xpath /capabilities/host/topology/cells/cell[1] - 16298528 3075208 4000 0 ... (3075208 * 4) + (4000 * 2048) != 16298528 # Correct values (Fedora ??, libvirt 4.10) $ virsh capabilities | xmllint --xpath /capabilities/host/topology/cells/cell[1] - 32359908 8038777 100 0 ... (8038777 * 4) + (100 * 2048) == 32359908 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1569678 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1811870/+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 1809943] Re: nova send None global_request_id on neutron calls
** Also affects: nova/queens Importance: Undecided Status: New ** Also affects: nova/rocky 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/1809943 Title: nova send None global_request_id on neutron calls Status in OpenStack Compute (nova): In Progress Status in OpenStack Compute (nova) queens series: New Status in OpenStack Compute (nova) rocky series: New Bug description: I config logging_context_format_string in cinder.conf, neutron.conf and nova.conf。 [default] logging_context_format_string=%(asctime)s.%(msecs)03d %(process)d %(levelname)s %(name)s [%(global_request_id)s %(request_id)s %(user_identity)s] %(instance)s%(message)s After boot a new instance, I get the request_id of the nova request which is req-3acf5bf3-3fcb-40c7-b9f2-3a96947836cc. [root@shyiq ~(keystone_admin)]# openstack server event list 96e0c916-0ca9-4b35-9663-3129944d7e81 +--+--+++ | Request ID | Server ID | Action | Start Time | +--+--+++ | req-3acf5bf3-3fcb-40c7-b9f2-3a96947836cc | 96e0c916-0ca9-4b35-9663-3129944d7e81 | create | 2018-12-28T02:04:35.00 | +--+--+++ I can find req-3acf5bf3-3fcb-40c7-b9f2-3a96947836cc as global_request_id in /var/log/nova/nova-placement-api.log and /var/log/cinder/api.log, but None in /var/log/neutron/server.log。 Nova send request_id to glance, cinder and neutron in the following Change-Id Ic5ee9161cd1174a2dd32b7f155194a7110cc5219 I16f9dda3c904c4a2578fa6a691fed646a41f6793 I866b8c6593c76c089da6bed55cf863ac556c9a8e But since I41724a612a5f3eabd504f3eaa9d2f9d141ca3f69 nova send context.global_request_id which may be None on neutron calls. stable/rocky and stable/queens also have this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1809943/+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 1414895] Re: failed compute node didn't delete instance's path directory in init_host
** Also affects: nova/queens Importance: Undecided Status: New ** Also affects: nova/rocky Importance: Undecided Status: New ** Changed in: nova/rocky Status: New => In Progress ** Changed in: nova/queens Status: New => In Progress ** Changed in: nova/queens Assignee: (unassigned) => Lee Yarwood (lyarwood) ** Changed in: nova/rocky Assignee: (unassigned) => Lee Yarwood (lyarwood) ** Changed in: nova/rocky Importance: Undecided => Low ** Changed in: nova/queens Importance: Undecided => Low -- 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/1414895 Title: failed compute node didn't delete instance's path directory in init_host Status in OpenStack Compute (nova): In Progress Status in OpenStack Compute (nova) queens series: In Progress Status in OpenStack Compute (nova) rocky series: In Progress Bug description: It will do clean for evacuated instances in method init_host in nova/compute/manager.py we restart a failed compute node . while using volume-backend shared-storage (like ceph) , nova leaves instance path directory in failed compuet node. The root cause is that we only passed argument "destroy_disks" to driver.destroy, the value will be true while using ceph. then will not delete instance path . This may lead live-migration instance failure with exeption DestinationDiskExists To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1414895/+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 1811238] Re: Install and configure controller node in neutron (manual) - Prerequisites
Best I can tell the docs already all do use -u and -p option [1]. If there's something else that's needed please reopen/clarify. [1] http://codesearch.openstack.org/?q=mysql=nope=doc=neutron ** Changed in: neutron Assignee: (unassigned) => Boden R (boden) ** Changed in: neutron Status: Confirmed => 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/1811238 Title: Install and configure controller node in neutron (manual) - Prerequisites Status in neutron: Invalid Bug description: - [X] This doc is inaccurate in this way: In section 1 the command: # mysql should be: # mysql -u root -p for reference check: https://docs.openstack.org/nova/rocky/install/controller-install-rdo.html --- Release: 13.0.3.dev26 on 2019-01-04 17:45 SHA: 025e767b94cf29e522a67e3c1ddd8aa3dba9140a Source: https://git.openstack.org/cgit/openstack/neutron/tree/doc/source/install/controller-install-rdo.rst URL: https://docs.openstack.org/neutron/rocky/install/controller-install-rdo.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1811238/+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 1784994] Re: Install and configure (Ubuntu) in glance
Reviewed: https://review.openstack.org/595013 Committed: https://git.openstack.org/cgit/openstack/glance/commit/?id=7191c7ac055404aebe43a3e6279cafe353f83762 Submitter: Zuul Branch:master commit 7191c7ac055404aebe43a3e6279cafe353f83762 Author: Brian Rosmaita Date: Wed Aug 22 10:01:34 2018 -0400 Update Ubuntu install guide The DB creation step for Ubuntu is slightly different from the other distros. Change-Id: Ib664da7ac647898f54ffb82bcadcbb6299bb5cc6 Closes-bug: #1784994 ** Changed in: glance Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1784994 Title: Install and configure (Ubuntu) in glance Status in Glance: Fix Released 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: __ In below part of document: "Use the database access client to connect to the database server as the root user: $ mysql -u root -p" Compared with other project documentation (e.g. initial openstack installation, identity, nova) and based on wording before "mysql" command, mysql is executed with root shell user. By executing using root shell user, mysql will not ask for password. and it is inline with other documentation and avoid confusion for new user installing openstack. so abova part should be written. "Use the database access client to connect to the database server as the root user: # mysql" --- Release: 15.0.2.dev4 on 'Wed Jun 27 16:17:38 2018, commit a4562ab' SHA: a4562abeb13b47f8bc765f792794f6d214df96cd Source: https://git.openstack.org/cgit/openstack/glance/tree/doc/source/install/install-ubuntu.rst URL: https://docs.openstack.org/glance/pike/install/install-ubuntu.html To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1784994/+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
