[Yahoo-eng-team] [Bug 1651658] [NEW] In drawer, 'priority' attribute should be handled conversely against rows
Public bug reported: 'priority' attribute has be handled in drawer [1][2], but the behavior is same as in rows. The behavior is that the items which have lower priority are hidden from both of row and drawer when widow width is narrower. Drawer is used for the supplements against the row, so it should be handled conversely. It means that items appear in drawer when they are hidden from row. [1] https://bugs.launchpad.net/horizon/+bug/1648332 [2] https://review.openstack.org/#/c/397132/ ** Affects: horizon Importance: Undecided Assignee: Shu Muto (shu-mutou) Status: New -- 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/1651658 Title: In drawer, 'priority' attribute should be handled conversely against rows Status in OpenStack Dashboard (Horizon): New Bug description: 'priority' attribute has be handled in drawer [1][2], but the behavior is same as in rows. The behavior is that the items which have lower priority are hidden from both of row and drawer when widow width is narrower. Drawer is used for the supplements against the row, so it should be handled conversely. It means that items appear in drawer when they are hidden from row. [1] https://bugs.launchpad.net/horizon/+bug/1648332 [2] https://review.openstack.org/#/c/397132/ To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1651658/+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 1504536] Re: Provide stevedore aliases for interface_driver option
** Also affects: kolla-ansible Importance: Undecided Status: New ** Changed in: kolla-ansible Assignee: (unassigned) => zhongshengping (chdzsp) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1504536 Title: Provide stevedore aliases for interface_driver option Status in devstack: Fix Released Status in kolla-ansible: In Progress Status in neutron: Fix Released Bug description: Currently, we require to set the full import path for those drivers. It's both not user friendly, and error prone in case we decide later to move the code to some other place. To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1504536/+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 1651650] [NEW] XenAPI: server rescue test sometime failed with timeout waiting for vif plugging
Public bug reported:
Observed several failure in citrix xenserver CI for this test case:
tempest.api.compute.servers.test_server_rescue
See there are timeout waiting for vif:
$ grep 'Timeout waiting for vif plugging callbac' screen-n-cpu.txt.gz
2016-12-20 10:58:52.036 4528 WARNING nova.virt.xenapi.vmops
[req-ff027cef-59be-4326-95e1-065f68077d63
tempest-ServerRescueTestJSON-1293983176
tempest-ServerRescueTestJSON-1293983176] [instance:
28b094ee-c571-4083-b72b-5ea78f1f4291] Timeout waiting for vif plugging callback
For rescue, it seems shouldn't wait for this event as this port should be
active at the rescuing start.
But observed:
neutron service reported the 2nd vif-plugin event:
2016-12-20 10:52:31.689 712 DEBUG neutron.notifiers.nova [-] Sending events:
[{'status': 'completed', 'tag': u'52d79a78-7205-4e69-8005-76a3cebbf267',
'name': 'network-vif-plugged', 'server_uuid':
u'28b094ee-c571-4083-b72b-5ea78f1f4291'}] send_events
/opt/stack/new/neutron/neutron/notifiers/nova.py:248
2016-12-20 10:53:45.179 712 DEBUG neutron.notifiers.nova [-] Sending
events: [{'status': 'completed', 'tag':
u'52d79a78-7205-4e69-8005-76a3cebbf267', 'name': 'network-vif-plugged',
'server_uuid': u'28b094ee-c571-4083-b72b-5ea78f1f4291'}] send_events
/opt/stack/new/neutron/neutron/notifiers/nova.py:248
And nova attempts to wait for this event after the 2nd event sent out; so it
won't catch the 2nd event at all:
2016-12-20 10:53:46.326 4528 DEBUG nova.virt.xenapi.vmops
[req-ff027cef-59be-4326-95e1-065f68077d63
tempest-ServerRescueTestJSON-1293983176
tempest-ServerRescueTestJSON-1293983176] wait for instance
event:[('network-vif-plugged', u'52d79a78-7205-4e69-8005-76a3cebbf267')] _spawn
/opt/stack/new/nova/nova/virt/xenapi/vmops.py:599
** 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/1651650
Title:
XenAPI: server rescue test sometime failed with timeout waiting for
vif plugging
Status in OpenStack Compute (nova):
New
Bug description:
Observed several failure in citrix xenserver CI for this test case:
tempest.api.compute.servers.test_server_rescue
See there are timeout waiting for vif:
$ grep 'Timeout waiting for vif plugging callbac' screen-n-cpu.txt.gz
2016-12-20 10:58:52.036 4528 WARNING nova.virt.xenapi.vmops
[req-ff027cef-59be-4326-95e1-065f68077d63
tempest-ServerRescueTestJSON-1293983176
tempest-ServerRescueTestJSON-1293983176] [instance:
28b094ee-c571-4083-b72b-5ea78f1f4291] Timeout waiting for vif plugging callback
For rescue, it seems shouldn't wait for this event as this port should be
active at the rescuing start.
But observed:
neutron service reported the 2nd vif-plugin event:
2016-12-20 10:52:31.689 712 DEBUG neutron.notifiers.nova [-] Sending events:
[{'status': 'completed', 'tag': u'52d79a78-7205-4e69-8005-76a3cebbf267',
'name': 'network-vif-plugged', 'server_uuid':
u'28b094ee-c571-4083-b72b-5ea78f1f4291'}] send_events
/opt/stack/new/neutron/neutron/notifiers/nova.py:248
2016-12-20 10:53:45.179 712 DEBUG neutron.notifiers.nova [-] Sending
events: [{'status': 'completed', 'tag':
u'52d79a78-7205-4e69-8005-76a3cebbf267', 'name': 'network-vif-
plugged', 'server_uuid': u'28b094ee-c571-4083-b72b-5ea78f1f4291'}]
send_events /opt/stack/new/neutron/neutron/notifiers/nova.py:248
And nova attempts to wait for this event after the 2nd event sent out; so it
won't catch the 2nd event at all:
2016-12-20 10:53:46.326 4528 DEBUG nova.virt.xenapi.vmops
[req-ff027cef-59be-4326-95e1-065f68077d63
tempest-ServerRescueTestJSON-1293983176
tempest-ServerRescueTestJSON-1293983176] wait for instance
event:[('network-vif-plugged', u'52d79a78-7205-4e69-8005-76a3cebbf267')] _spawn
/opt/stack/new/nova/nova/virt/xenapi/vmops.py:599
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1651650/+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 1597208] Re: Failed to Create an Instance using macvtap cause existence of "_" in interface vf_name (Regex miss)
** Changed in: neutron Status: Fix Committed => 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/1597208 Title: Failed to Create an Instance using macvtap cause existence of "_" in interface vf_name (Regex miss) Status in neutron: Fix Released Bug description: Step to reproduce : 1) neutron port-create --name port1 --binding:vnic_type=macvtap private 2) nova boot --flavor 2 --image --nic port-id= vm_1 Interface Name on Compute = "p2p1_0" From n-cpu.log : 2016-06-29 06:01:04.592 1265 ERROR nova.compute.manager [req-a4694341-f7e0-4e7b-b98e-5f640abbf950 admin admin] [instance: 7a3063f5-43a7-4d25-b23e-335a2a3274ab] Failed to allocate network(s) 2016-06-29 06:01:04.592 1265 ERROR nova.compute.manager [instance: 7a3063f5-43a7-4d25-b23e-335a2a3274ab] Traceback (most recent call last): 2016-06-29 06:01:04.592 1265 ERROR nova.compute.manager [instance: 7a3063f5-43a7-4d25-b23e-335a2a3274ab] File "/opt/stack/nova/nova/compute/manager.py", line 2064, in _build_and_run_instance 2016-06-29 06:01:04.592 1265 ERROR nova.compute.manager [instance: 7a3063f5-43a7-4d25-b23e-335a2a3274ab] block_device_info=block_device_info) 2016-06-29 06:01:04.592 1265 ERROR nova.compute.manager [instance: 7a3063f5-43a7-4d25-b23e-335a2a3274ab] File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 2780, in spawn 2016-06-29 06:01:04.592 1265 ERROR nova.compute.manager [instance: 7a3063f5-43a7-4d25-b23e-335a2a3274ab] block_device_info=block_device_info) 2016-06-29 06:01:04.592 1265 ERROR nova.compute.manager [instance: 7a3063f5-43a7-4d25-b23e-335a2a3274ab] File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 4946, in _create_domain_and_network 2016-06-29 06:01:04.592 1265 ERROR nova.compute.manager [instance: 7a3063f5-43a7-4d25-b23e-335a2a3274ab] raise exception.VirtualInterfaceCreateException() 2016-06-29 06:01:04.592 1265 ERROR nova.compute.manager [instance: 7a3063f5-43a7-4d25-b23e-335a2a3274ab] VirtualInterfaceCreateException: Virtual Interface creation failed 2016-06-29 06:01:04.592 1265 ERROR nova.compute.manager [instance: 7a3063f5-43a7-4d25-b23e-335a2a3274ab] 2016-06-29 06:01:04.593 1265 DEBUG nova.compute.utils [req-a4694341-f7e0-4e7b-b98e-5f640abbf950 admin admin] [instance: 7a3063f5-43a7-4d25-b23e-335a2a3274ab] Virtual Interface creation failed notify_about_instance_usage /opt/stack/nova/nova/compute/utils.py:284 2016-06-29 06:01:04.593 1265 ERROR nova.compute.manager [req-a4694341-f7e0-4e7b-b98e-5f640abbf950 admin admin] [instance: 7a3063f5-43a7-4d25-b23e-335a2a3274ab] Build of instance 7a3063f5-43a7-4d25-b23e-335a2a3274ab aborted: Failed to allocate the network(s), not rescheduling. 2016-06-29 06:01:04.593 1265 ERROR nova.compute.manager [instance: 7a3063f5-43a7-4d25-b23e-335a2a3274ab] Traceback (most recent call last): 2016-06-29 06:01:04.593 1265 ERROR nova.compute.manager [instance: 7a3063f5-43a7-4d25-b23e-335a2a3274ab] File "/opt/stack/nova/nova/compute/manager.py", line 1926, in _do_build_and_run_instance 2016-06-29 06:01:04.593 1265 ERROR nova.compute.manager [instance: 7a3063f5-43a7-4d25-b23e-335a2a3274ab] filter_properties) 2016-06-29 06:01:04.593 1265 ERROR nova.compute.manager [instance: 7a3063f5-43a7-4d25-b23e-335a2a3274ab] File "/opt/stack/nova/nova/compute/manager.py", line 2102, in _build_and_run_instance 2016-06-29 06:01:04.593 1265 ERROR nova.compute.manager [instance: 7a3063f5-43a7-4d25-b23e-335a2a3274ab] reason=msg) 2016-06-29 06:01:04.593 1265 ERROR nova.compute.manager [instance: 7a3063f5-43a7-4d25-b23e-335a2a3274ab] BuildAbortException: Build of instance 7a3063f5-43a7-4d25-b23e-335a2a3274ab aborted: Failed to alloca te the network(s), not rescheduling. 2016-06-29 06:01:04.593 1265 ERROR nova.compute.manager [instance: 7a3063f5-43a7-4d25-b23e-335a2a3274ab] To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1597208/+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 1651064] Re: HTTP 500 when calling os-volume_boot with invalid destination_type
Thanks for reporting Honjo-san. The error message (Invalid input for field/attribute ..) seems that JSON-Schema works fine. So I mark it 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/1651064 Title: HTTP 500 when calling os-volume_boot with invalid destination_type Status in OpenStack Compute (nova): Invalid Bug description: When calling os-volume_boot with invalid bdm destination_type (e.g. volume1 as a typo of volume) HTTP 500 will raise. Setp 1: call os-volumes_boot API or use "nova boot" CLI with --block- device provided(it will call os-volumes_boot) nova-api log for my test can be found in: http://paste.openstack.org/show/592762/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1651064/+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 1645553] Re: Wrong link to role-assignment doc in Identity v3 api-ref
** Project changed: openstack-api-site => keystone -- 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/1645553 Title: Wrong link to role-assignment doc in Identity v3 api-ref Status in OpenStack Identity (keystone): New Bug description: Detail doc mentioned in identity v3 api-ref for role assignment is not right one. api-ref - http://developer.openstack.org/api-ref/identity/v3/?expanded =list-effective-role-assignments-detail non accessible link - http://docs.openstack.org/api/openstack- identity/3/rel/role_assignments To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1645553/+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 1645553] [NEW] Wrong link to role-assignment doc in Identity v3 api-ref
You have been subscribed to a public bug: Detail doc mentioned in identity v3 api-ref for role assignment is not right one. api-ref - http://developer.openstack.org/api-ref/identity/v3/?expanded =list-effective-role-assignments-detail non accessible link - http://docs.openstack.org/api/openstack- identity/3/rel/role_assignments ** Affects: keystone Importance: Undecided Status: New -- Wrong link to role-assignment doc in Identity v3 api-ref https://bugs.launchpad.net/bugs/1645553 You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). -- 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 1641433] Re: Deprecate SR-IOV 'physical_device_mappings' config option
A bulk update for Ocata updates will treat this deprecation with doc- tool. ** Changed in: openstack-manuals 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/1641433 Title: Deprecate SR-IOV 'physical_device_mappings' config option Status in neutron: Invalid Status in openstack-manuals: Won't Fix Bug description: https://review.openstack.org/395044 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit 03b84bc920b5499e1fef23c646268fffa1d859d7 Author: Edan David Date: Tue Nov 8 10:30:45 2016 -0500 Deprecate SR-IOV 'physical_device_mappings' config option The device to physnet validation is made in Nova by pci_whitelist config option. Therefore it is redundant to validate it in Neutron with physical_device_mappings config option. Closes-Bug: #1640220 DocImpact Change-Id: I5f363347b327212a49a9b78a7164c11d9e457b10 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1641433/+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 1649341] Re: Undercloud upgrade fails with "Cell mappings are not created, but required for Ocata"
Reviewed: https://review.openstack.org/409948
Committed:
https://git.openstack.org/cgit/openstack/puppet-nova/commit/?id=4234ce3df430f16d3e9278e587238148db8e3a47
Submitter: Jenkins
Branch:master
commit 4234ce3df430f16d3e9278e587238148db8e3a47
Author: Alex Schultz
Date: Mon Dec 12 14:52:57 2016 -0700
Add cell_v2 simple_cell_setup
As part of Ocata, nova has made the cell_v2 setup manditory for the
nova-api db sync process. This change adds a simple cell_v2 setup with a
cell0 and an execution of the 'nova-manage cell_v2 simple_cell_setup' as
part of the nova-api db setup and sync process.
Change-Id: Idfc369e9e17f7d5a30ce4ff52beb604dd4a6ac23
Closes-Bug: #1649341
** Changed in: puppet-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/1649341
Title:
Undercloud upgrade fails with "Cell mappings are not created, but
required for Ocata"
Status in OpenStack Compute (nova):
Fix Released
Status in puppet-nova:
Fix Released
Status in tripleo:
In Progress
Bug description:
Trying to upgrade with recent trunk nova and puppet-nova gives this
error:
Notice: /Stage[main]/Nova::Db::Sync_api/Exec[nova-db-sync-api]/returns:
error: Cell mappings are not created, but required for Ocata. Please run
nova-manage db simple_cell_setup before continuing.
Error: /usr/bin/nova-manage api_db sync returned 1 instead of one of [0]
Error: /Stage[main]/Nova::Db::Sync_api/Exec[nova-db-sync-api]/returns: change
from notrun to 0 failed: /usr/bin/nova-manage api_db sync returned 1 instead
of one of [0]
Debugging manually gives:
$ sudo /usr/bin/nova-manage api_db sync
error: Cell mappings are not created, but required for Ocata. Please run
nova-manage db simple_cell_setup before continuing.
but...
$ sudo nova-manage db simple_cell_setup
usage: nova-manage db [-h]
{archive_deleted_rows,null_instance_uuid_scan,online_data_migrations,sync,version}
...
nova-manage db: error: argument action: invalid choice: 'simple_cell_setup'
(choose from 'archive_deleted_rows', 'null_instance_uuid_scan',
'online_data_migrations', 'sync', 'version')
I tried adding openstack-nova* to the delorean-current whitelist, but with
the latest nova packages there still appears to be this mismatch.
[stack@instack /]$ rpm -qa | grep nova
openstack-nova-conductor-15.0.0-0.20161212155146.909410c.el7.centos.noarch
python-nova-15.0.0-0.20161212155146.909410c.el7.centos.noarch
openstack-nova-scheduler-15.0.0-0.20161212155146.909410c.el7.centos.noarch
puppet-nova-10.0.0-0.20161211003757.09b9f7b.el7.centos.noarch
python2-novaclient-6.0.0-0.20161003181629.25117fa.el7.centos.noarch
openstack-nova-api-15.0.0-0.20161212155146.909410c.el7.centos.noarch
openstack-nova-cert-15.0.0-0.20161212155146.909410c.el7.centos.noarch
openstack-nova-common-15.0.0-0.20161212155146.909410c.el7.centos.noarch
openstack-nova-compute-15.0.0-0.20161212155146.909410c.el7.centos.noarch
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1649341/+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 1651626] [NEW] Shared checkbox in networks should not be shown if non-admin users are not allowed to touch.
Public bug reported: Currently, an admin user is allowed by the policy to create or update a network with the attribute of 'shared' checkbox during the creating workflow or the updating form. However, a non-admin user is not allowed by the policy to create or update the 'shared' attribute for the network. The current implementation for non-admin users of this process is to present the 'shared' checkbox. This checkbox is disabled, namely not allowed to touch, and with help text of 'Non admin users are not allowed to set shared option.'. By function point of view, this is correct with no problem. But from my opinion, non-admin users would try to tick the checkbox and then see that it is not allowed by the help text. This makes non-admin users confused. If this is not allowed to use by non-admin users, why not just make it invisible to non-admin users. This is my concern to improve the use case. ** Affects: horizon Importance: Undecided Assignee: Han Chao (hanchao-v) Status: New ** Changed in: horizon Assignee: (unassigned) => Han Chao (hanchao-v) -- 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/1651626 Title: Shared checkbox in networks should not be shown if non-admin users are not allowed to touch. Status in OpenStack Dashboard (Horizon): New Bug description: Currently, an admin user is allowed by the policy to create or update a network with the attribute of 'shared' checkbox during the creating workflow or the updating form. However, a non-admin user is not allowed by the policy to create or update the 'shared' attribute for the network. The current implementation for non-admin users of this process is to present the 'shared' checkbox. This checkbox is disabled, namely not allowed to touch, and with help text of 'Non admin users are not allowed to set shared option.'. By function point of view, this is correct with no problem. But from my opinion, non-admin users would try to tick the checkbox and then see that it is not allowed by the help text. This makes non-admin users confused. If this is not allowed to use by non-admin users, why not just make it invisible to non-admin users. This is my concern to improve the use case. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1651626/+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 1619393] Re: cloud-init useradd/groupadd fails on ubuntu-core-16 with readonly /etc/passwd
This bug was fixed in the package cloud-init - 0.7.8-49-g9e904bb- 0ubuntu1~16.10.1 --- cloud-init (0.7.8-49-g9e904bb-0ubuntu1~16.10.1) yakkety; urgency=medium * debian/cloud-init.templates: enable DigitalOcean by default [Ben Howard] * debian/cloud-init.postinst: update /etc/fstab on Azure to fix future resize operations. (LP: #1611074) * New upstream snapshot. - systemd/cloud-init-local.service: + replace 'Wants' and 'After' on local-fs.target with more granular After=systemd-remount-fs.service and RequiresMountsFor=/var/lib and Before=sysinit.target. This is done run sufficiently early enough to update /etc/fstab. (LP: #1611074) - systemd/cloud-init.service: + add Before=sysinit.target and DefaultDependencies=no (LP: #1611074) + drop Requires=networking.service to work where networking.service is not needed. + add Conflicts=shutdown.target + drop unnecessary Wants=local-fs.target - net: support reading ipv6 dhcp config from initramfs [LaMont Jones] (LP: #1621615) - dmidecode: Allow dmidecode to be used on aarch64, and only attempt usage on x86, x86_64, and aarch64. [Robert Schweikert] - disk-config: udev settle after partitioning in gpt format. (LP: #1626243) - Add support for snap create-user on Ubuntu Core images. [Ryan Harper] (LP: #1619393) - Fix sshd restarts for rhel distros. [Jim Gorz] - Move user/group functions to new ug_util file [Joshua Harlow] - update Gentoo initscripts to run in the correct order [Matthew Thode] - MAAS: improve the debugging tool in datasource to consider config provided on kernel cmdline. - DataSources: + Ec2: protect against non-dictionary in block-device-mapping. + AliYun: Add new datasource for Ali-Cloud ECS, that is available but not enabled by default [kaihuan.pkh] + OpenNebula: replace parsing of 'ip' command with similar function available in cloudinit.net. This fixed unit tests when running in environment with no networking. - doc changes: + Add documentation on stages of boot. + make the RST files consistently formated and other improvements. + fixed example to not overwrite /etc/hosts [Chris Glass] + fix spelling / typos in ca_certs and scripts_vendor. + improve HACKING.rst file + Add documentation for logging features. [Wesley Wiedenmeier] - code style and unit test changes: + pep8: fix style errors reported by pycodestyle 2.1.0 + pyflakes: fix issue with pyflakes 1.3 found in ubuntu zesty-proposed. + Add coverage dependency to bddeb to fix package build. + Add coverage collection to tox unit tests. [Joshua Powers] + do not read system /etc/cloud/cloud.cfg.d (LP: #1635350) + tests: silence the Cheetah UserWarning about NameMapper C version. + Fix python2.6 things found running in centos 6. -- Scott Moser Tue, 22 Nov 2016 17:04:36 -0500 ** Changed in: cloud-init (Ubuntu Yakkety) Status: Fix Committed => 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/1619393 Title: cloud-init useradd/groupadd fails on ubuntu-core-16 with readonly /etc/passwd Status in cloud-init: Fix Committed Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Fix Released Status in cloud-init source package in Yakkety: Fix Released Bug description: === Begin SRU Template === [Impact] When running under ubuntu-core 16 images, /etc/passwd is read-only. If my user-data includes any non-default username, creation fails due to the read-only nature of the image. This is addressed by useradd/groupadd including a command line flag, --extrausers which instructs the command to look for a different user/group database in /var/lib/extrausers , which is writable in the ubuntu-core 16 image. [Test Case] In a snappy image that has cloud-init enabled, launch image with the following user-data: #cloud-config users: - name: bob snapuser: b...@bobcom.io And also: #cloud-config snappy: email: b...@bobcom.io where 'b...@bobcom.io' is your launchpad registered email address. Assume you can log in. [Regression Potential] The code is intended to be backwards compatible and inert unless cloud-config provided turns it on. It is also gated by a 'system_is_snappy' method that checks if the system is snappy (ubuntu core). Unit tests are provided, so regression should be somewhat reduced. Some code was moved around to implement this, and a new config module was added. [Other Info] The upstream change made here is at [1] [1] https://git.launchpad.net/cloud- init/commit?id=d8534561ba76db25b6fc0044eb1bfda63686e859 === End SRU Template ===
[Yahoo-eng-team] [Bug 1611074] Re: Reformatting of ephemeral drive fails on resize of Azure VM
This bug was fixed in the package cloud-init - 0.7.8-49-g9e904bb- 0ubuntu1~16.10.1 --- cloud-init (0.7.8-49-g9e904bb-0ubuntu1~16.10.1) yakkety; urgency=medium * debian/cloud-init.templates: enable DigitalOcean by default [Ben Howard] * debian/cloud-init.postinst: update /etc/fstab on Azure to fix future resize operations. (LP: #1611074) * New upstream snapshot. - systemd/cloud-init-local.service: + replace 'Wants' and 'After' on local-fs.target with more granular After=systemd-remount-fs.service and RequiresMountsFor=/var/lib and Before=sysinit.target. This is done run sufficiently early enough to update /etc/fstab. (LP: #1611074) - systemd/cloud-init.service: + add Before=sysinit.target and DefaultDependencies=no (LP: #1611074) + drop Requires=networking.service to work where networking.service is not needed. + add Conflicts=shutdown.target + drop unnecessary Wants=local-fs.target - net: support reading ipv6 dhcp config from initramfs [LaMont Jones] (LP: #1621615) - dmidecode: Allow dmidecode to be used on aarch64, and only attempt usage on x86, x86_64, and aarch64. [Robert Schweikert] - disk-config: udev settle after partitioning in gpt format. (LP: #1626243) - Add support for snap create-user on Ubuntu Core images. [Ryan Harper] (LP: #1619393) - Fix sshd restarts for rhel distros. [Jim Gorz] - Move user/group functions to new ug_util file [Joshua Harlow] - update Gentoo initscripts to run in the correct order [Matthew Thode] - MAAS: improve the debugging tool in datasource to consider config provided on kernel cmdline. - DataSources: + Ec2: protect against non-dictionary in block-device-mapping. + AliYun: Add new datasource for Ali-Cloud ECS, that is available but not enabled by default [kaihuan.pkh] + OpenNebula: replace parsing of 'ip' command with similar function available in cloudinit.net. This fixed unit tests when running in environment with no networking. - doc changes: + Add documentation on stages of boot. + make the RST files consistently formated and other improvements. + fixed example to not overwrite /etc/hosts [Chris Glass] + fix spelling / typos in ca_certs and scripts_vendor. + improve HACKING.rst file + Add documentation for logging features. [Wesley Wiedenmeier] - code style and unit test changes: + pep8: fix style errors reported by pycodestyle 2.1.0 + pyflakes: fix issue with pyflakes 1.3 found in ubuntu zesty-proposed. + Add coverage dependency to bddeb to fix package build. + Add coverage collection to tox unit tests. [Joshua Powers] + do not read system /etc/cloud/cloud.cfg.d (LP: #1635350) + tests: silence the Cheetah UserWarning about NameMapper C version. + Fix python2.6 things found running in centos 6. -- Scott Moser Tue, 22 Nov 2016 17:04:36 -0500 ** Changed in: cloud-init (Ubuntu Yakkety) Status: Fix Committed => 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/1611074 Title: Reformatting of ephemeral drive fails on resize of Azure VM Status in cloud-init: Fix Committed Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Fix Released Status in cloud-init source package in Yakkety: Fix Released Bug description: === Begin SRU Template === [Impact] In some cases, cloud-init writes entries to /etc/fstab, and on azure it will even format a disk for mounting and then write the entry for that 'ephemeral' disk there. A supported operation on Azure is to "resize" the system. When you do this the system is shut down, resized (given larger/faster disks and more CPU) and then brought back up. In that process, the "ephemeral" disk re-initialized to its original NTFS format. The designed goal is for cloud-init to recognize this situation and re-format the disk to ext4. The problem is that the mount of that disk happens before cloud-init can reformat. Thats because the entry in fstab has 'auto' and is automatically mounted. The end result is that after resize operation the user will be left with the ephemeral disk mounted at /mnt and having a ntfs filesystem rather than ext4. [Test Case] The text in comment 3 describes how to recreate by the original reporter. Another way to do this is to just re-format the ephemeral disk as ntfs and then reboot. The result *should* be that after reboot it comes back up and has an ext4 filesystem on it. 1.) boot system on azure (for this, i use https://gist.github.com/smoser/5806147, but you can use web ui or any other way). Save output of journalctl --no-pager > journalctl.orig systemctl st
[Yahoo-eng-team] [Bug 1621615] Re: network not configured when ipv6 netbooted into cloud-init
This bug was fixed in the package cloud-init - 0.7.8-49-g9e904bb- 0ubuntu1~16.10.1 --- cloud-init (0.7.8-49-g9e904bb-0ubuntu1~16.10.1) yakkety; urgency=medium * debian/cloud-init.templates: enable DigitalOcean by default [Ben Howard] * debian/cloud-init.postinst: update /etc/fstab on Azure to fix future resize operations. (LP: #1611074) * New upstream snapshot. - systemd/cloud-init-local.service: + replace 'Wants' and 'After' on local-fs.target with more granular After=systemd-remount-fs.service and RequiresMountsFor=/var/lib and Before=sysinit.target. This is done run sufficiently early enough to update /etc/fstab. (LP: #1611074) - systemd/cloud-init.service: + add Before=sysinit.target and DefaultDependencies=no (LP: #1611074) + drop Requires=networking.service to work where networking.service is not needed. + add Conflicts=shutdown.target + drop unnecessary Wants=local-fs.target - net: support reading ipv6 dhcp config from initramfs [LaMont Jones] (LP: #1621615) - dmidecode: Allow dmidecode to be used on aarch64, and only attempt usage on x86, x86_64, and aarch64. [Robert Schweikert] - disk-config: udev settle after partitioning in gpt format. (LP: #1626243) - Add support for snap create-user on Ubuntu Core images. [Ryan Harper] (LP: #1619393) - Fix sshd restarts for rhel distros. [Jim Gorz] - Move user/group functions to new ug_util file [Joshua Harlow] - update Gentoo initscripts to run in the correct order [Matthew Thode] - MAAS: improve the debugging tool in datasource to consider config provided on kernel cmdline. - DataSources: + Ec2: protect against non-dictionary in block-device-mapping. + AliYun: Add new datasource for Ali-Cloud ECS, that is available but not enabled by default [kaihuan.pkh] + OpenNebula: replace parsing of 'ip' command with similar function available in cloudinit.net. This fixed unit tests when running in environment with no networking. - doc changes: + Add documentation on stages of boot. + make the RST files consistently formated and other improvements. + fixed example to not overwrite /etc/hosts [Chris Glass] + fix spelling / typos in ca_certs and scripts_vendor. + improve HACKING.rst file + Add documentation for logging features. [Wesley Wiedenmeier] - code style and unit test changes: + pep8: fix style errors reported by pycodestyle 2.1.0 + pyflakes: fix issue with pyflakes 1.3 found in ubuntu zesty-proposed. + Add coverage dependency to bddeb to fix package build. + Add coverage collection to tox unit tests. [Joshua Powers] + do not read system /etc/cloud/cloud.cfg.d (LP: #1635350) + tests: silence the Cheetah UserWarning about NameMapper C version. + Fix python2.6 things found running in centos 6. -- Scott Moser Tue, 22 Nov 2016 17:04:36 -0500 ** Changed in: cloud-init (Ubuntu Yakkety) Status: Fix Committed => Fix Released ** Changed in: cloud-initramfs-tools (Ubuntu Yakkety) Status: Fix Committed => 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/1621615 Title: network not configured when ipv6 netbooted into cloud-init Status in cloud-init: Fix Committed Status in MAAS: In Progress Status in cloud-init package in Ubuntu: Fix Released Status in cloud-initramfs-tools package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Fix Released Status in cloud-initramfs-tools source package in Xenial: Fix Released Status in cloud-init source package in Yakkety: Fix Released Status in cloud-initramfs-tools source package in Yakkety: Fix Released Bug description: https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1621507 talks of how IPv6 netboot with iscsi root disk doesn't work, blocking IPv6-only MAAS. After I hand-walked busybox through getting an IPv6 address, everything worked just fine until cloud-init couldn't fetch the instance data, because it insisted on bringing up the interface in IPv4, and there is no IPv4 DHCP on that vlan. Please work with initramfs and friends on getting IPv6 netboot to actually configure the interface. This may be as simple as teaching it about "inet6 dhcp" interfaces, and bolting the pieces together. Note that "use radvd" is not really an option for our use case. Related bugs: * bug 1621507: initramfs-tools configure_networking() fails to dhcp IPv6 addresses * bug 1635716: Can't bring up a machine on a dual network (ipv4 and ipv6) * bug 1639930: initramfs network configuration ignored if only ip6= on kernel command line [Impact] It is not possible to enlist, commmission, or deploy with MAAS in an IPv6-only environment. An
[Yahoo-eng-team] [Bug 1626243] Re: Cloud-init fails to write ext4 filesystem to Azure Ephemeral Drive
This bug was fixed in the package cloud-init - 0.7.8-49-g9e904bb- 0ubuntu1~16.10.1 --- cloud-init (0.7.8-49-g9e904bb-0ubuntu1~16.10.1) yakkety; urgency=medium * debian/cloud-init.templates: enable DigitalOcean by default [Ben Howard] * debian/cloud-init.postinst: update /etc/fstab on Azure to fix future resize operations. (LP: #1611074) * New upstream snapshot. - systemd/cloud-init-local.service: + replace 'Wants' and 'After' on local-fs.target with more granular After=systemd-remount-fs.service and RequiresMountsFor=/var/lib and Before=sysinit.target. This is done run sufficiently early enough to update /etc/fstab. (LP: #1611074) - systemd/cloud-init.service: + add Before=sysinit.target and DefaultDependencies=no (LP: #1611074) + drop Requires=networking.service to work where networking.service is not needed. + add Conflicts=shutdown.target + drop unnecessary Wants=local-fs.target - net: support reading ipv6 dhcp config from initramfs [LaMont Jones] (LP: #1621615) - dmidecode: Allow dmidecode to be used on aarch64, and only attempt usage on x86, x86_64, and aarch64. [Robert Schweikert] - disk-config: udev settle after partitioning in gpt format. (LP: #1626243) - Add support for snap create-user on Ubuntu Core images. [Ryan Harper] (LP: #1619393) - Fix sshd restarts for rhel distros. [Jim Gorz] - Move user/group functions to new ug_util file [Joshua Harlow] - update Gentoo initscripts to run in the correct order [Matthew Thode] - MAAS: improve the debugging tool in datasource to consider config provided on kernel cmdline. - DataSources: + Ec2: protect against non-dictionary in block-device-mapping. + AliYun: Add new datasource for Ali-Cloud ECS, that is available but not enabled by default [kaihuan.pkh] + OpenNebula: replace parsing of 'ip' command with similar function available in cloudinit.net. This fixed unit tests when running in environment with no networking. - doc changes: + Add documentation on stages of boot. + make the RST files consistently formated and other improvements. + fixed example to not overwrite /etc/hosts [Chris Glass] + fix spelling / typos in ca_certs and scripts_vendor. + improve HACKING.rst file + Add documentation for logging features. [Wesley Wiedenmeier] - code style and unit test changes: + pep8: fix style errors reported by pycodestyle 2.1.0 + pyflakes: fix issue with pyflakes 1.3 found in ubuntu zesty-proposed. + Add coverage dependency to bddeb to fix package build. + Add coverage collection to tox unit tests. [Joshua Powers] + do not read system /etc/cloud/cloud.cfg.d (LP: #1635350) + tests: silence the Cheetah UserWarning about NameMapper C version. + Fix python2.6 things found running in centos 6. -- Scott Moser Tue, 22 Nov 2016 17:04:36 -0500 ** Changed in: cloud-init (Ubuntu Yakkety) Status: Fix Committed => 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/1626243 Title: Cloud-init fails to write ext4 filesystem to Azure Ephemeral Drive Status in cloud-init: Fix Committed Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Fix Released Status in cloud-init source package in Yakkety: Fix Released Status in cloud-init source package in Zesty: Fix Released Bug description: === Begin SRU Template === [Impact] There is a race condition that occurs when cloud-init tries to partition a block device (/dev/sdb) and then put a filesystem on a partition on it. It is possible that cloud-init tries to run mkfs on /dev/sdb1 after partitioning the device /dev/sdb but before the partition device node '/dev/sdb1' exists. When this race condition occurs, cloud-init will fail to make the "ephemeral" device available to the user on Azure. [Test Case] A reliable reproduce test case is hard to come by here. The failure case is believed to be well understood. [Regression Potential] There should be very little chance for regression, as essentially all the change does is change: 1. sgdisk -n 1:0:0 /dev/sdb 2. mkfs.ext4 /dev/sdb1 to 1. sgdisk -n 1:0:0 /dev/sdb 1a udevadm settle 1b blockdev --rereadpt 1c udevadm settle 2. mkfs.ext4 /dev/sdb1 The steps '1b' and '1c' above are not necessary, but were present already in the method. They serve here as additional wait. [Other Info] The change that fixes this is viewable at [1]. For context, viewin all of cc_disk_setup.py [2]. Basically we just add a call to read_parttbl [3] to exec_mkpart_gpt after invoking a sgdisk command that partitions a disk. read_partbl basically does a ud
[Yahoo-eng-team] [Bug 1635350] Re: unit tests fail as non-root on maas deployed system
This bug was fixed in the package cloud-init - 0.7.8-49-g9e904bb-
0ubuntu1~16.10.1
---
cloud-init (0.7.8-49-g9e904bb-0ubuntu1~16.10.1) yakkety; urgency=medium
* debian/cloud-init.templates: enable DigitalOcean by default [Ben Howard]
* debian/cloud-init.postinst: update /etc/fstab on Azure to fix
future resize operations. (LP: #1611074)
* New upstream snapshot.
- systemd/cloud-init-local.service:
+ replace 'Wants' and 'After' on local-fs.target with more granular
After=systemd-remount-fs.service and RequiresMountsFor=/var/lib
and Before=sysinit.target.
This is done run sufficiently early enough to update /etc/fstab.
(LP: #1611074)
- systemd/cloud-init.service:
+ add Before=sysinit.target and DefaultDependencies=no (LP: #1611074)
+ drop Requires=networking.service to work where networking.service is
not needed.
+ add Conflicts=shutdown.target
+ drop unnecessary Wants=local-fs.target
- net: support reading ipv6 dhcp config from initramfs [LaMont Jones]
(LP: #1621615)
- dmidecode: Allow dmidecode to be used on aarch64, and only attempt
usage on x86, x86_64, and aarch64. [Robert Schweikert]
- disk-config: udev settle after partitioning in gpt format.
(LP: #1626243)
- Add support for snap create-user on Ubuntu Core images. [Ryan Harper]
(LP: #1619393)
- Fix sshd restarts for rhel distros. [Jim Gorz]
- Move user/group functions to new ug_util file [Joshua Harlow]
- update Gentoo initscripts to run in the correct order [Matthew Thode]
- MAAS: improve the debugging tool in datasource to consider
config provided on kernel cmdline.
- DataSources:
+ Ec2: protect against non-dictionary in block-device-mapping.
+ AliYun: Add new datasource for Ali-Cloud ECS, that is
available but not enabled by default [kaihuan.pkh]
+ OpenNebula: replace parsing of 'ip' command with similar function
available in cloudinit.net. This fixed unit tests when running
in environment with no networking.
- doc changes:
+ Add documentation on stages of boot.
+ make the RST files consistently formated and other improvements.
+ fixed example to not overwrite /etc/hosts [Chris Glass]
+ fix spelling / typos in ca_certs and scripts_vendor.
+ improve HACKING.rst file
+ Add documentation for logging features. [Wesley Wiedenmeier]
- code style and unit test changes:
+ pep8: fix style errors reported by pycodestyle 2.1.0
+ pyflakes: fix issue with pyflakes 1.3 found in ubuntu zesty-proposed.
+ Add coverage dependency to bddeb to fix package build.
+ Add coverage collection to tox unit tests. [Joshua Powers]
+ do not read system /etc/cloud/cloud.cfg.d (LP: #1635350)
+ tests: silence the Cheetah UserWarning about NameMapper C version.
+ Fix python2.6 things found running in centos 6.
-- Scott Moser Tue, 22 Nov 2016 17:04:36 -0500
** Changed in: cloud-init (Ubuntu Yakkety)
Status: Fix Committed => 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/1635350
Title:
unit tests fail as non-root on maas deployed system
Status in cloud-init:
Fix Committed
Status in cloud-init package in Ubuntu:
Fix Released
Status in cloud-init source package in Xenial:
Fix Released
Status in cloud-init source package in Yakkety:
Fix Released
Bug description:
=== Begin SRU Template ===
[Impact]
Running cloud-init's unit test cases on a system deployed by MAAS would
fail. The reason is that the non-root user would not be able to read
files with MAAS node credentials in /etc/cloud/cloud.cfg.d
We want this change SRU so that an attempt to build and run tests on a
system deployed by maas will work rather than fail due to unit test failure.
[Test Case]
Run unit tests on a system deployed by maas, or even just with:
f=/etc/cloud/cloud.cfg.d/90_dpkg_maas.cfg
sh -c 'mkdir -p "${1%/*}" && touch "$1" && chmod ugo-r "$1"' -- "$f"
tox -e py3
[Regression Potential]
This was just to fix a build break or unit tests being run.
Changes are only to unit tests.
=== End SRU Template ===
Observed Behavior:
On a system deployed by MAAS I checked out master and then tried to
immediately build it:
> git clone https://git.launchpad.net/cloud-init
> cd cloud-init
> ./packages/bddeb
I get a number of errors around permission issues around this file:
PermissionError: [Errno 13] Permission denied:
\'/etc/cloud/cloud.cfg.d/90_dpkg_maas.cfg\'
See: https://paste.ubuntu.com/23354559/
or formatted better: http://paste.ubuntu.com/23374383/
If I run as root however, it build as expected.
Expected Behavior:
Running bddeb works as a non-root user.
To manage notifications about this bug go to:
https://bugs.la
[Yahoo-eng-team] [Bug 1643287] Re: Glance-manage db purge not remove rows that was created less then one day
Reviewed: https://review.openstack.org/407177 Committed: https://git.openstack.org/cgit/openstack/glance/commit/?id=d4f07cc32268c3b27047be77a6449667d931d903 Submitter: Jenkins Branch:master commit d4f07cc32268c3b27047be77a6449667d931d903 Author: Alexander Bashmakov Date: Mon Dec 5 19:56:42 2016 + Allow purging of records less than 1 day old. Adding ability to purge records less than 1 day old, using the glance-manage db_purge utility. Closes-Bug: #1643287 Change-Id: Ibaea583d49bd5d09ad2e6bf99d2c0efaac5cb4ec ** 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/1643287 Title: Glance-manage db purge not remove rows that was created less then one day Status in Glance: Fix Released Bug description: Currently, the value of glance-manage db purge --age_in_days cannot be 0. This is annoying for those testing scenarios in which a large number of images are created and deleted. It would be useful to use --age_in_days=0 to purge the deleted rows immediately. Nothing seems to be gained by having to wait a day before doing the delete. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1643287/+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 1631513] Re: DVR: Fix race conditions when trying to add default gateway for fip gateway port.
Reviewed: https://review.openstack.org/385617 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=d40322c7d4aa1dd6d595dfe415278c9f252f4da2 Submitter: Jenkins Branch:master commit d40322c7d4aa1dd6d595dfe415278c9f252f4da2 Author: Swaminathan Vasudevan Date: Fri Oct 7 10:30:40 2016 -0700 DVR: Fix race condition in creation of fip gateway In large-scale environments, we have seen a router update arrive for one tenant while we are still creating the router for a different tenant and initializing the shared floating IP gateway port. Sometimes these updates can get scheduled simultaneously, with the second running before we are done creating all the resources in the first, causing an exception when trying to set the default route since either the interface or IP address does not exist yet. Add a lock to better synchronize these functions so a create can finish before an update can be done. If it still fails, we will throw an exception so that the namespace will be cleaned-up and the update can be re-scheduled for the next iteration. Closes-Bug: #1631513 Change-Id: Ia8c92cea2f8798582c39ad3450ab3b3c45a356f7 ** 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/1631513 Title: DVR: Fix race conditions when trying to add default gateway for fip gateway port. Status in neutron: Fix Released Bug description: There seems to be a race condition when trying to add default gateway route in fip namespace for the fip agent gateway port. The way it happens is at high scale testing, when there is a router update that is currently happening for the Router-A which has a floatingip, a fip namespace is getting created and gateway ports plugged to the external bridge in the context of the fip namespace. While it is getting created, if there is another router update for the same Router-A, then it calls 'update-gateway-port' and tries to set the default gateway and fails. We do find a log message in the l3-agent with 'Failed to process compatible router' and also a TRACE in the l3-agent. Traceback (most recent call last): File "/opt/stack/venv/neutron-20160927T090820Z/lib/python2.7/site-packages/neutron/agent/l3/agent.py", line 501, in _process_router_update self._process_router_if_compatible(router) File "/opt/stack/venv/neutron-20160927T090820Z/lib/python2.7/site-packages/neutron/agent/l3/agent.py", line 440, in _process_router_if_compatible self._process_updated_router(router) File "/opt/stack/venv/neutron-20160927T090820Z/lib/python2.7/site-packages/neutron/agent/l3/agent.py", line 454, in _process_updated_router ri.process(self) File "/opt/stack/venv/neutron-20160927T090820Z/lib/python2.7/site-packages/neutron/agent/l3/dvr_local_router.py", line 538, in process super(DvrLocalRouter, self).process(agent) File "/opt/stack/venv/neutron-20160927T090820Z/lib/python2.7/site-packages/neutron/agent/l3/dvr_router_base.py", line 31, in process super(DvrRouterBase, self).process(agent) File "/opt/stack/venv/neutron-20160927T090820Z/lib/python2.7/site-packages/neutron/common/utils.py", line 396, in call self.logger(e) File "/opt/stack/venv/neutron-20160927T090820Z/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__ self.force_reraise() File "/opt/stack/venv/neutron-20160927T090820Z/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise six.reraise(self.type_, self.value, self.tb) File "/opt/stack/venv/neutron-20160927T090820Z/lib/python2.7/site-packages/neutron/common/utils.py", line 393, in call return func(*args, **kwargs) File "/opt/stack/venv/neutron-20160927T090820Z/lib/python2.7/site-packages/neutron/agent/l3/router_info.py", line 989, in process self.process_external(agent) File "/opt/stack/venv/neutron-20160927T090820Z/lib/python2.7/site-packages/neutron/agent/l3/dvr_local_router.py", line 491, in process_external self.create_dvr_fip_interfaces(ex_gw_port) File "/opt/stack/venv/neutron-20160927T090820Z/lib/python2.7/site-packages/neutron/agent/l3/dvr_local_router.py", line 522, in create_dvr_fip_interfaces self.fip_ns.update_gateway_port(fip_agent_port) File "/opt/stack/venv/neutron-20160927T090820Z/lib/python2.7/site-packages/neutron/agent/l3/dvr_fip_ns.py", line 243, in update_gateway_port ipd.route.add_gateway(gw_ip) File "/opt/stack/venv/neutron-20160927T090820Z/lib/python2.7/site-packages/neutron/agent/linux/ip_lib.py", line 690, in add_gateway self._as_root([ip_version], tuple(args)) File "/opt/stack/venv/neutron-20160927T090820Z/lib/python2.7/site-packages/neutro
[Yahoo-eng-team] [Bug 1643879] Re: Adding/removing/replacing tags cannot bump in network revision_number
Reviewed: https://review.openstack.org/408867 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=6bd3ad2bb3d52a4d51d357656525abdb6ebb696e Submitter: Jenkins Branch:master commit 6bd3ad2bb3d52a4d51d357656525abdb6ebb696e Author: Kevin Benton Date: Fri Dec 9 14:21:24 2016 -0800 Bump revision of resource on tag add/remove This updates the tag to bump the revision of the standard attr record it's associated with. This required a small change to include a bump revision method directly on the standard attr records. Closes-Bug: #1643879 Change-Id: Ia096cd342ed3eeec33a8ae64efe13d469c375dd6 ** 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/1643879 Title: Adding/removing/replacing tags cannot bump in network revision_number Status in neutron: Fix Released Bug description: When adding/removing/replacing tags for network, revision_number cannot be bumped. [How to reproduce] 1. Create a network 2. Execute following commands: $ neutron net-show rev -c revision_number -c tags +-+---+ | Field | Value | +-+---+ | revision_number | 3 | | tags| | +-+---+ $ neutron tag-add --resource-type network --resource rev --tag "tag" $ neutron net-show rev -c revision_number -c tags +-+-+ | Field | Value | +-+-+ | revision_number | 3 | | tags| tag | +-+-+ In db model(https://github.com/openstack/neutron/blob/master/neutron/db/models/tag.py), there is no child-parent relation b/w tags and network. Therefore, I'm not sure that this behavior is bug or not. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1643879/+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 1651549] [NEW] fix spec file variable
Public bug reported: https://github.com/openstack/horizon/blob/master/openstack_dashboard/static/app/core/images/details/overview.controller.spec.js#L33 should be sessionDeferred. ** Affects: horizon Importance: Low Assignee: Cindy Lu (clu-m) Status: New ** Changed in: horizon Assignee: (unassigned) => Cindy Lu (clu-m) ** Changed in: horizon Milestone: None => ocata-2 ** Changed in: horizon Importance: Undecided => Low -- 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/1651549 Title: fix spec file variable Status in OpenStack Dashboard (Horizon): New Bug description: https://github.com/openstack/horizon/blob/master/openstack_dashboard/static/app/core/images/details/overview.controller.spec.js#L33 should be sessionDeferred. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1651549/+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 1651540] [NEW] Lines missing for heat topology in dashboard
Public bug reported: Seems like the heat topology in horizon is broken. The lines connecting all the elements is no longer visible. Please check attached image for the same. ** Affects: horizon Importance: Undecided Status: New ** Attachment added: "newton_horizon_heat_topology.png" https://bugs.launchpad.net/bugs/1651540/+attachment/4794385/+files/newton_horizon_heat_topology.png -- 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/1651540 Title: Lines missing for heat topology in dashboard Status in OpenStack Dashboard (Horizon): New Bug description: Seems like the heat topology in horizon is broken. The lines connecting all the elements is no longer visible. Please check attached image for the same. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1651540/+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 1651526] [NEW] nova-compute reports OSError: [Errno 24] Too many open files
Public bug reported: Description === After we upgraded our openstack deployment to Mitaka we started noticing more and more VMs in an error and/or shutoff state. We found out that although nova service-list was reporting all nova-compute as "up" nova-compute was logging : ERROR nova.compute.manager OSError: [Errno 24] Too many open files our deployment uses ceph as storage backend for ephemeral/cinder/glance with currently around 900 osd installed. Steps to reproduce == Ask a compute node to perform several actions at once such as: -take a live snapshot -delete a VM -boot a VM Depending on the task the compute will allow for a certain number of jobs before complaining about the number of open files. Expected behaviour = Nova-compute should be more robust in handling requests and should report when in error state. Environment === We are currently running: nova-common 2:13.1.2-0ubuntu2~cloud0 nova-compute 2:13.1.2-0ubuntu2~cloud0 hypervisor: Libvirt + KVM nova-compute-kvm 2:13.1.2-0ubuntu2~cloud0 nova-compute-libvirt 2:13.1.2-0ubuntu2~cloud0 storage: ceph 0.94.9-1trusty networking: neutron + openvswitch neutron-common 2:8.3.0-0ubuntu1.1~cloud0 Logs & Configs == ** Affects: nova Importance: Undecided Status: New ** Attachment added: "nova-compute.log" https://bugs.launchpad.net/bugs/1651526/+attachment/4794382/+files/nova-compute.log -- 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/1651526 Title: nova-compute reports OSError: [Errno 24] Too many open files Status in OpenStack Compute (nova): New Bug description: Description === After we upgraded our openstack deployment to Mitaka we started noticing more and more VMs in an error and/or shutoff state. We found out that although nova service-list was reporting all nova-compute as "up" nova-compute was logging : ERROR nova.compute.manager OSError: [Errno 24] Too many open files our deployment uses ceph as storage backend for ephemeral/cinder/glance with currently around 900 osd installed. Steps to reproduce == Ask a compute node to perform several actions at once such as: -take a live snapshot -delete a VM -boot a VM Depending on the task the compute will allow for a certain number of jobs before complaining about the number of open files. Expected behaviour = Nova-compute should be more robust in handling requests and should report when in error state. Environment === We are currently running: nova-common 2:13.1.2-0ubuntu2~cloud0 nova-compute 2:13.1.2-0ubuntu2~cloud0 hypervisor: Libvirt + KVM nova-compute-kvm 2:13.1.2-0ubuntu2~cloud0 nova-compute-libvirt 2:13.1.2-0ubuntu2~cloud0 storage: ceph 0.94.9-1trusty networking: neutron + openvswitch neutron-common 2:8.3.0-0ubuntu1.1~cloud0 Logs & Configs == To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1651526/+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 1648064] Re: Error "Table 'neutron.ml2_vlan_allocations' doesn't exist" in neutron server
Sorry that was a mistake on my part, the bug is still happening: http://logs.openstack.org/58/411358/1/check/gate-openstack-ansible-os_nova-ansible-func-ubuntu-xenial/d9467db/logs/openstack/openstack1/neutron/neutron-server.log.txt.gz - from today ** Changed in: openstack-ansible Status: Invalid => Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1648064 Title: Error "Table 'neutron.ml2_vlan_allocations' doesn't exist" in neutron server Status in neutron: New Status in openstack-ansible: Confirmed Bug description: Hello, This issue (Table 'neutron.ml2_vlan_allocations' doesn't exist") appears in the neutron.conf after a deploy in openstack-ansible. Our deploy is working fine, and I see no functional test issues, so this seems a low priority issue. This message appears on both trusty and Xenial. I guess this is a migration issue, and I don't know what we are doing wrong. Anyway, this is the log [1]. You can see in the same file the neutron release BUT this bug appeared in earlier releases. We just never paid attention because everything functionally works. Sadly, I cannot trace back further than what our gates store. I can tell you it's earlier than 2016-10-21 [2] (which is really old. SHA for the checked-out version is: 287bb35e167143388ab3d069af209341a75430f3). That also means the bug probably appeared in newton cycle. Any recent commit in neutron role will have these issues listed, so we can reproduce it quite easily with the latest sha's too. All the neutron logs available in our gates if you want. Best regards, JP. === [1]: http://logs.openstack.org/24/391524/48/check/gate-openstack- ansible-os_neutron-ansible-func-ubuntu- xenial/9c75e15/logs/openstack/openstack1/neutron/neutron- server.log.txt.gz#_2016-12-04_15_45_58_790 [2]: http://logs.openstack.org/05/389705/1/check/gate-openstack- ansible-os_neutron-ansible-func-ubuntu- xenial/b83b5e3/logs/openstack/openstack1/neutron/neutron- server.log.txt.gz#_2016-10-24_17_44_10_157 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1648064/+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 1648064] Re: Error "Table 'neutron.ml2_vlan_allocations' doesn't exist" in neutron server
According to our bug triagers, the error doesn't seem to appear anymore. There was probably a change that didn't mention this bug. Could the neutron team verify if that's ok to close for neutron too? ** Changed in: openstack-ansible 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/1648064 Title: Error "Table 'neutron.ml2_vlan_allocations' doesn't exist" in neutron server Status in neutron: New Status in openstack-ansible: Confirmed Bug description: Hello, This issue (Table 'neutron.ml2_vlan_allocations' doesn't exist") appears in the neutron.conf after a deploy in openstack-ansible. Our deploy is working fine, and I see no functional test issues, so this seems a low priority issue. This message appears on both trusty and Xenial. I guess this is a migration issue, and I don't know what we are doing wrong. Anyway, this is the log [1]. You can see in the same file the neutron release BUT this bug appeared in earlier releases. We just never paid attention because everything functionally works. Sadly, I cannot trace back further than what our gates store. I can tell you it's earlier than 2016-10-21 [2] (which is really old. SHA for the checked-out version is: 287bb35e167143388ab3d069af209341a75430f3). That also means the bug probably appeared in newton cycle. Any recent commit in neutron role will have these issues listed, so we can reproduce it quite easily with the latest sha's too. All the neutron logs available in our gates if you want. Best regards, JP. === [1]: http://logs.openstack.org/24/391524/48/check/gate-openstack- ansible-os_neutron-ansible-func-ubuntu- xenial/9c75e15/logs/openstack/openstack1/neutron/neutron- server.log.txt.gz#_2016-12-04_15_45_58_790 [2]: http://logs.openstack.org/05/389705/1/check/gate-openstack- ansible-os_neutron-ansible-func-ubuntu- xenial/b83b5e3/logs/openstack/openstack1/neutron/neutron- server.log.txt.gz#_2016-10-24_17_44_10_157 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1648064/+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 1651512] [NEW] Dhcpagent "reserved_dhcp_port" not well managed during startup
Public bug reported: During DHCP agent startup, same reserved DHCP port can be configured by 2 different DHCP agent (HA case). In this special case (race condition case) a DhcpPortInUse RemoteError exception is triggered. This exception is actually not well catched, instead of trying with the next "reserved DHCP port" a new exception is raised. ** Affects: neutron Importance: Undecided Assignee: Bertrand Lallau (bertrand-lallau) Status: In Progress ** Changed in: neutron Assignee: (unassigned) => Bertrand Lallau (bertrand-lallau) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1651512 Title: Dhcpagent "reserved_dhcp_port" not well managed during startup Status in neutron: In Progress Bug description: During DHCP agent startup, same reserved DHCP port can be configured by 2 different DHCP agent (HA case). In this special case (race condition case) a DhcpPortInUse RemoteError exception is triggered. This exception is actually not well catched, instead of trying with the next "reserved DHCP port" a new exception is raised. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1651512/+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 1651465] [NEW] support prefix delegation in HA router
Public bug reported: Prefix delegation was introduced in regular neutron router since Liberty. But it doesn't work in neutron HA router. This bug is opened to add its support in neutron HA router. ** Affects: neutron Importance: Undecided Assignee: Baodong (Robert) Li (baoli) Status: New ** Changed in: neutron Assignee: (unassigned) => Baodong (Robert) Li (baoli) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1651465 Title: support prefix delegation in HA router Status in neutron: New Bug description: Prefix delegation was introduced in regular neutron router since Liberty. But it doesn't work in neutron HA router. This bug is opened to add its support in neutron HA router. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1651465/+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 1633518] Re: The passphrase used to encrypt or decrypt volumes was mangled prior to Newton
lyarwood - AFAIK we do not use ``Fix COmmited`` status, just ``Fix
Released``.
** Changed in: nova
Status: Fix Committed => 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/1633518
Title:
The passphrase used to encrypt or decrypt volumes was mangled prior to
Newton
Status in OpenStack Compute (nova):
Fix Released
Status in os-brick:
In Progress
Bug description:
Description
===
tl;dr hex(x) previously stripped leading 0's from individual hex
numbers while encoding the passphrase back to a hex string before use
to encrypt/decrypt a luks volume.
Prior to Newton the following method was used to encode passphrases
when attempting to use or create a luks volume :
def _get_passphrase(self, key):
"""Convert raw key to string."""
return ''.join(hex(x).replace('0x', '') for x in key)
https://github.com/openstack/nova/blob/82190bdd283dda37f7517fd9a268b5e55183f06c/nova/volume/encryptors/cryptsetup.py#L92-L94
This was replaced in Newton with the move to Castellan in the
following change that altered both the decoding and encoding steps :
Replace key manager with Castellan
https://review.openstack.org/#/c/309614/
The original method used the built-in hex() call to convert individual
unsigned ints back to hex. This would strip the leading 0 from each
hex digit pair, altering the eventual passphrase used to encrypt or
decrypt the volume.
For example, the following one liner represents both the initial
decode step preformed by ConfKeyManager and the step above to encode
the passphrase in the LuksEncryptor class :
>>> ''.join(hex(x).replace('0x', '') for x in array.array('B',
'752523eb50c3bf2ba3ff639c250405805fd4e779894ef5360e15e081696a'.decode('hex')).tolist())
'752523eb50c3bf2ba3ff639c2545805fd4e779894ef536e15e081696a'
Original string: 752523eb50c3bf2ba3ff639c250405805fd4e779894ef5360e15e081696a
New string : 752523eb50c3bf2ba3ff639c25 4 5805fd4e779894ef536 e15e081696a
The returned string is missing various 0's that have been stripped by
the hex() call :
>>> hex(14)
'0xe'
>>> int(0x0e)
14
>>> int(0xe)
14
>>> hex(4)
'0x4'
>>> int(0x04)
4
>>> int(0x4)
4
The following one liner represents the current decode and encode
steps, producing the same string as is entered :
>>> import binascii
>>>
binascii.hexlify(bytes(binascii.unhexlify('752523eb50c3bf2ba3ff639c250405805fd4e779894ef5360e15e081696a'))).decode('utf-8')
u'752523eb50c3bf2ba3ff639c250405805fd4e779894ef5360e15e081696a'
Original string: 752523eb50c3bf2ba3ff639c250405805fd4e779894ef5360e15e081696a
New string : 752523eb50c3bf2ba3ff639c250405805fd4e779894ef5360e15e081696a
IMHO the way to handle this is to add a simple retry in master and
stable/newton when we fail due to a bad passphrase using the mangled
passphrase.
We should also improve the testing in this area as it appears all
previous testing used zero based passphrases, missing this issue when
it landed in Newton.
More notes available downstream in the following bug :
Nova encryption alters the key used
https://bugzilla.redhat.com/show_bug.cgi?id=1382415
Steps to reproduce
==
- Encrypt a volume in Mitaka or earlier.
- Upgrade to Newton or later.
- Attempt to use the volume.
Expected result
===
Volume is decrypted and usable.
Actual result
=
Unable to decrypt the volume due to the use of an modified passphrase during
initial formatting and use prior to Newton.
Environment
===
1. Exact version of OpenStack you are running. See the following
list for all releases: http://docs.openstack.org/releases/
Newton and later.
2. Which hypervisor did you use?
Libvirt
2. Which storage type did you use?
N/A
3. Which networking type did you use?
(For example: nova-network, Neutron with OpenVSwitch, ...)
N/A
Logs & Configs
==
N/A
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1633518/+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 1651443] [NEW] Filter instances in Horizon based on user id
Public bug reported: Currently, there is isn't an option added in Horizon to filter the instances of a project based on the user id (owner field). Adding such a filter would help a non-admin to view all the instances created by him in the current project. It would also help an admin to view all instances created by a particular user (across all projects). ** Affects: horizon Importance: Undecided Assignee: Ankit Agarwal (aka1293) Status: New ** Tags: wishlist ** Summary changed: - Filter instances in Horizon based on user/owner id + Filter instances in Horizon based on user id ** Changed in: horizon Assignee: (unassigned) => Ankit Agarwal (aka1293) -- 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/1651443 Title: Filter instances in Horizon based on user id Status in OpenStack Dashboard (Horizon): New Bug description: Currently, there is isn't an option added in Horizon to filter the instances of a project based on the user id (owner field). Adding such a filter would help a non-admin to view all the instances created by him in the current project. It would also help an admin to view all instances created by a particular user (across all projects). To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1651443/+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 1651441] [NEW] api-ref: wrong parameter type and a missing parameter in servers-admin-action.inc
Public bug reported: In api-ref/source/servers-admin-action.inc, the following parameters' type should be 'object'. * createBackup * os-resetState And there is a missing parameter in 'os-migrateLive' Action. It is 'os-migrateLive'(object). ** Affects: nova Importance: Undecided Assignee: Takashi NATSUME (natsume-takashi) 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/1651441 Title: api-ref: wrong parameter type and a missing parameter in servers- admin-action.inc Status in OpenStack Compute (nova): In Progress Bug description: In api-ref/source/servers-admin-action.inc, the following parameters' type should be 'object'. * createBackup * os-resetState And there is a missing parameter in 'os-migrateLive' Action. It is 'os-migrateLive'(object). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1651441/+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 1651420] [NEW] Can not clear source or dest port (range) for existing firewall rule
Public bug reported: We need to give user a way to update firewall rule to clear source or dest port (range). ** Affects: neutron Importance: Undecided Assignee: Jesse (jesse-5) Status: New ** Changed in: neutron Assignee: (unassigned) => Jesse (jesse-5) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1651420 Title: Can not clear source or dest port (range) for existing firewall rule Status in neutron: New Bug description: We need to give user a way to update firewall rule to clear source or dest port (range). To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1651420/+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 1644725] Re: Check destination_type when booting with bdm provided
** Also affects: python-openstackclient
Importance: Undecided
Status: New
** Changed in: python-openstackclient
Assignee: (unassigned) => Zhenyu Zheng (zhengzhenyu)
** No longer affects: python-openstackclient
--
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/1644725
Title:
Check destination_type when booting with bdm provided
Status in Cinder:
New
Status in OpenStack Compute (nova):
In Progress
Status in python-novaclient:
In Progress
Bug description:
When booting instance with block_device_mapping provided, in the
current implementation, the "destination_type" is allowed to be None,
and this lead to un-sync between Nova and Cinder:
Step 1: Booting with block_device_mapping, leave destination_type to
be None:
root@SZX1000191849:/var/log/nova# nova --debug boot --flavor 1
--image 2ba75018-403f-407b-864a-08564022e1f8 --nic net-
id=cce1d2f1-acf4-4646-abdc-069f8d0dbb71 --block-device
'source=volume,id=9f49d5b0-3625-46a2-9ed4-d82f19949148' test_bdm
the corresponding REST call is:
DEBUG (session:342) REQ: curl -g -i -X POST
http://10.229.45.17:8774/v2.1/os-volumes_boot -H "Accept: application/json" -H
"User-Agent: python-novaclient" -H "OpenStack-API-Version: compute 2.37" -H
"X-OpenStack-Nova-API-Version: 2.37" -H "X-Auth-Token:
{SHA1}4d8c2c43338e1c4d96e08bcd1c2f3ff36de14154" -H "Content-Type:
application/json" -d '{"server": {"name": "test_bdm", "imageRef":
"2ba75018-403f-407b-864a-08564022e1f8", "block_device_mapping_v2":
[{"source_type": "image", "delete_on_termination": true, "boot_index": 0,
"uuid": "2ba75018-403f-407b-864a-08564022e1f8", "destination_type": "local"},
{"source_type": "volume", "uuid": "9f49d5b0-3625-46a2-9ed4-d82f19949148"}],
"flavorRef": "1", "max_count": 1, "min_count": 1, "networks": [{"uuid":
"cce1d2f1-acf4-4646-abdc-069f8d0dbb71"}]}}'
Step 2: After the instance is successfully launched, the detailed info
is like this:
root@SZX1000191849:/var/log/nova# nova show
83d9ec32-93e0-441a-ae10-00e08b65de0b
+--+--+
| Property | Value
|
+--+--+
| OS-DCF:diskConfig| MANUAL
|
| OS-EXT-AZ:availability_zone | nova
|
| OS-EXT-SRV-ATTR:host | SZX1000191849
|
| OS-EXT-SRV-ATTR:hostname | test-bdm
|
| OS-EXT-SRV-ATTR:hypervisor_hostname | SZX1000191849
|
| OS-EXT-SRV-ATTR:instance_name| instance-0016
|
| OS-EXT-SRV-ATTR:kernel_id| 87c9afd6-3a47-4a4c-a804-6b456d68136d
|
| OS-EXT-SRV-ATTR:launch_index | 0
|
| OS-EXT-SRV-ATTR:ramdisk_id | acd02b28-6484-4f90-a5e7-bba7159343e1
|
| OS-EXT-SRV-ATTR:reservation_id | r-fiqwkq02
|
| OS-EXT-SRV-ATTR:root_device_name | /dev/vda
|
| OS-EXT-SRV-ATTR:user_data| -
|
| OS-EXT-STS:power_state | 1
|
| OS-EXT-STS:task_state| -
|
| OS-EXT-STS:vm_state | active
|
| OS-SRV-USG:launched_at | 2016-11-25T06:50:36.00
|
| OS-SRV-USG:terminated_at | -
|
| accessIPv4 |
|
| accessIPv6 |
|
| config_drive |
[Yahoo-eng-team] [Bug 1650999] Re: api-ref: `osapi_max_limit' should be replaced with 'max_limit'
Fixed in https://review.openstack.org/#/c/411444/ ** 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/1650999 Title: api-ref: `osapi_max_limit' should be replaced with 'max_limit' Status in OpenStack Compute (nova): Fix Released Bug description: The 'osapi_max_limit' has been renamed to 'max_limit' since Ida4ee57d6e1822e35e3198f6d3a89410e211d57d. So `osapi_max_limit' should be replaced with 'max_limit' in the API reference. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1650999/+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 1493714] Re: nova allows booting two instances with the same neutron port in parallel
Neutron feature is here: https://review.openstack.org/#/c/409577/
** Also affects: neutron
Importance: Undecided
Status: New
** Changed in: neutron
Status: New => In Progress
** Changed in: neutron
Assignee: (unassigned) => Kevin Benton (kevinbenton)
** 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/1493714
Title:
nova allows booting two instances with the same neutron port in
parallel
Status in neutron:
In Progress
Status in OpenStack Compute (nova):
In Progress
Bug description:
It seems that to reproduce the problem we need a multi node deployment
with at least two nova-compute service.
To reproduce it do the following:
1) create a neutron port
2) boot two instances in parallel with that port
Sometimes both instances become ACTIVE in nova which is clearly wrong.
vagrant@controller:~/devstack$ neutron net-list
+--+-+--+
| id | name| subnets
|
+--+-+--+
| fc257a00-d3bf-47e6-b91f-e2cef985c414 | public |
a610715c-614f-492c-8810-f51e03c5d383 2001:db8::/64 |
| | |
a923871f-90ad-4354-935d-db24861a5890 172.24.4.0/24 |
| 7a057b12-0e69-4c31-859e-098263abeeba | private |
04f3b138-d7c6-48e1-98e3-7f70eb7ab4fe fda4:10b7:acaa::/64 |
| | |
ee70023c-f273-471a-8b84-cb25bb64fcf9 10.0.0.0/24 |
+--+-+--+
vagrant@controller:~/devstack$ neutron port-create
7a057b12-0e69-4c31-859e-098263abeeba
Created a new port:
+---+-+
| Field | Value
|
+---+-+
| admin_state_up| True
|
| allowed_address_pairs |
|
| binding:host_id |
|
| binding:profile | {}
|
| binding:vif_details | {}
|
| binding:vif_type | unbound
|
| binding:vnic_type | normal
|
| device_id |
|
| device_owner |
|
| fixed_ips | {"subnet_id":
"ee70023c-f273-471a-8b84-cb25bb64fcf9", "ip_address": "10.0.0.4"}
|
| | {"subnet_id":
"04f3b138-d7c6-48e1-98e3-7f70eb7ab4fe", "ip_address":
"fda4:10b7:acaa:0:f816:3eff:fe0c:285d"} |
| id| f2da8f78-8ae4-49f0-bca0-5820588d33ea
|
| mac_address | fa:16:3e:0c:28:5d
|
| name |
|
| network_id| 7a057b12-0e69-4c31-859e-098263abeeba
|
| port_security_enabled | True
|
| security_groups | 73853e74-a6c7-4b71-ba45-5b82b5e1ad81
|
| status| DOWN
|
| tenant_id
[Yahoo-eng-team] [Bug 1643121] Re: The Result is different from API document about 'qos-policy-show'
Reviewed: https://review.openstack.org/400660
Committed:
https://git.openstack.org/cgit/openstack/neutron-lib/commit/?id=1152f9d4c39cc5994255e193ce3b56667c3a84fd
Submitter: Jenkins
Branch:master
commit 1152f9d4c39cc5994255e193ce3b56667c3a84fd
Author: QunyingRan
Date: Tue Nov 22 18:10:02 2016 +0800
Modify API response information in API documents
The result is different from API document about 'qos-policy-show',
bandwidth and DSCP description in rules list not in policy
Change-Id: I1d857f5061f4fc7a58ed13766016d04ff6d315eb
Closes-Bug: #1643121
** 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/1643121
Title:
The Result is different from API document about 'qos-policy-show'
Status in neutron:
Fix Released
Bug description:
The rules descriptions In response of 'qos-policy-show' is different from
actual result.
In API document,the response of 'qos-policy-show' is follow:
{
"policy": {
"project_id": "8d4c70a21fed4aeba121a1a429ba0d04",
"tenant_id": "8d4c70a21fed4aeba121a1a429ba0d04",
"id": "46ebaec0-0570-43ac-82f6-60d2b03168c4",
"name": "10Mbit",
"description": "This policy limits the ports to 10Mbit max.",
"shared": false,
"bandwidth_limit_rules": [
{
"id": "5f126d84-551a-4dcf-bb01-0e9c0df0c793",
"policy_id": "46ebaec0-0570-43ac-82f6-60d2b03168c4",
"max_kbps": "1",
"max_burst_kbps": "0"
}
],
"dscp_marking_rules": [
{
"id": "5f126d84-551a-4dcf-bb01-0e9c0df0c794",
"policy_id": "46ebaec0-0570-43ac-82f6-60d2b03168c4",
"dscp_mark": "26"
}
]
}
}
but the result in fact is:
{"policy":
{"name": "p1",
"rules": [
{"max_kbps": 1,
"type": "bandwidth_limit",
"id": "25352eaa-0651-4c3d-b0e0-f1eb5857d4b7",
"max_burst_kbps": 0,
"qos_policy_id": "d92847df-38b2-48db-bf56-d12288e9cdbb"},
{"dscp_mark": 20,
"type": "dscp_marking",
"id": "4c31a158-73ff-484f-aef4-7cfb14035009",
"qos_policy_id": "d92847df-38b2-48db-bf56-d12288e9cdbb"}
],
"tenant_id": "9a5b27e4da8b4aec99df42b222a8a696",
"created_at": "2016-11-19T03:48:05Z",
"updated_at": "2016-11-19T03:49:30Z",
"revision_number": 3,
"shared": false,
"project_id": "9a5b27e4da8b4aec99df42b222a8a696",
"id": "d92847df-38b2-48db-bf56-d12288e9cdbb",
"description": ""}
}
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1643121/+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 1651390] [NEW] Instance is getting 2 ports attached during launching with one of which is in down status
Public bug reported: [Test process] 1. launch an instance in horizon or via API 2. select image, network, security rule...etc [Test result]: 1.2 IP addresses are shown to be attached to the created instance(eg:10.156.95.47 and 10.156.95.48) 2.go to network tab and check ports: port 10.156.95.47 is in status down while port 10.156.95.48 is in status up(both are up in admin status) 3.10.156.95.48 is actually assigned to the instance I am using openstack mitaka. This happens only with internal networks and not with external-provider ones. Frequency is about 2/3 launches. I am not using any OVS tool to configure the network. FYI. This issue won't occur if you launch instances with CLI. It happens only when using horizon or API. ** 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/1651390 Title: Instance is getting 2 ports attached during launching with one of which is in down status Status in neutron: New Bug description: [Test process] 1. launch an instance in horizon or via API 2. select image, network, security rule...etc [Test result]: 1.2 IP addresses are shown to be attached to the created instance(eg:10.156.95.47 and 10.156.95.48) 2.go to network tab and check ports: port 10.156.95.47 is in status down while port 10.156.95.48 is in status up(both are up in admin status) 3.10.156.95.48 is actually assigned to the instance I am using openstack mitaka. This happens only with internal networks and not with external-provider ones. Frequency is about 2/3 launches. I am not using any OVS tool to configure the network. FYI. This issue won't occur if you launch instances with CLI. It happens only when using horizon or API. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1651390/+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 1651368] [NEW] Dhcpagent not efficient during initialization process
Public bug reported: During DhcpAgent startup procedure all networks initialization will be done twice: * Killing old dnsmasq processes * set and configure all TAP interfaces * building all Dnsmasq config files (lease and host files) * launching dnsmasq processes This is really inefficient and can be strange in case of namespaces monitoring. The following Dhcpagent traces show the procedure describe just above (logs have been cleanup to show only relevant informations) 2016-12-20 09:02:42.200 DEBUG neutron.openstack.common.service [req-b0a2772 None None] log_opt_values /usr/lib/python2.7/dist-packages/oslo_config/cfg.py:2197 2016-12-20 09:02:42.214 INFO neutron.agent.dhcp.agent [-] Synchronizing state 2016-12-20 09:02:43.262 DEBUG neutron.agent.dhcp.agent [-] Calling driver for network: 5be9fe58-0790-4342-9182-172438e8e0bc action: enable call_driver /usr/lib/python2.7/dist-packages/neutron/agent/dhcp/agent.py:106 2016-12-20 09:02:43.314 DEBUG neutron.agent.dhcp.agent [-] Calling driver for network: f2a73fc1-6a93-4822-aa45-b789d50d action: enable call_driver /usr/lib/python2.7/dist-packages/neutron/agent/dhcp/agent.py:106 Command: ['sudo', '/usr/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'kill', '-9', '24540'] 2016-12-20 09:02:43.441 DEBUG neutron.agent.linux.utils [-] Unable to access /var/lib/neutron/dhcp/5be9fe58-0790-4342-9182-172438e8e0bc/pid get_value_from_file /usr/lib/python2.7/dist-packages/neutron/agent/linux/utils.py:222 Command: ['sudo', '/usr/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'kill', '-9', '24542'] 2016-12-20 09:02:43.459 DEBUG neutron.agent.linux.utils [-] Unable to access /var/lib/neutron/dhcp/f2a73fc1-6a93-4822-aa45-b789d50d/pid get_value_from_file /usr/lib/python2.7/dist-packages/neutron/agent/linux/utils.py:222 Command: ['sudo', '/usr/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'netns', 'exec', 'qdhcp-5be9fe58-0790-4342-9182-172438e8e0bc', 'ip', 'link', 'set', 'tap5c7f794d-08', 'up'] Command: ['sudo', '/usr/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'netns', 'exec', 'qdhcp-f2a73fc1-6a93-4822-aa45-b789d50d', 'ip', 'link', 'set', 'tap995da463-09', 'up'] Command: ['sudo', '/usr/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'netns', 'exec', 'qdhcp-5be9fe58-0790-4342-9182-172438e8e0bc', 'ip', 'addr', 'show', 'tap5c7f794d-08', 'permanent', 'scope', 'global'] Stdout: 32: tap5c7f794d-08: mtu 1500 qdisc noqueue state UNKNOWN group default link/ether fa:16:3e:6b:cb:29 brd ff:ff:ff:ff:ff:ff inet 20.0.0.36/24 brd 20.0.0.255 scope global tap5c7f794d-08 valid_lft forever preferred_lft forever inet 169.254.169.254/16 brd 169.254.255.255 scope global tap5c7f794d-08 valid_lft forever preferred_lft forever Command: ['sudo', '/usr/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'netns', 'exec', 'qdhcp-f2a73fc1-6a93-4822-aa45-b789d50d', 'ip', 'addr', 'show', 'tap995da463-09', 'permanent', 'scope', 'global'] Stdout: 35: tap995da463-09: mtu 1500 qdisc noqueue state UNKNOWN group default link/ether fa:16:3e:49:6e:68 brd ff:ff:ff:ff:ff:ff inet 20.0.1.36/24 brd 20.0.1.255 scope global tap995da463-09 valid_lft forever preferred_lft forever inet 169.254.169.254/16 brd 169.254.255.255 scope global tap995da463-09 valid_lft forever preferred_lft forever Command: ['sudo', '/usr/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'netns', 'exec', 'qdhcp-f2a73fc1-6a93-4822-aa45-b789d50d', 'ip', '-4', 'route', 'list', 'dev', 'tap995da463-09', 'scope', 'link'] Stdout: 20.0.1.0/24 proto kernel src 20.0.1.36 169.254.0.0/16 proto kernel src 169.254.169.254 Command: ['sudo', '/usr/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'netns', 'exec', 'qdhcp-5be9fe58-0790-4342-9182-172438e8e0bc', 'ip', '-4', 'route', 'list', 'dev', 'tap5c7f794d-08', 'scope', 'link'] Stdout: 20.0.0.0/24 proto kernel src 20.0.0.36 169.254.0.0/16 proto kernel src 169.254.169.254 Command: ['sudo', '/usr/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'netns', 'exec', 'qdhcp-f2a73fc1-6a93-4822-aa45-b789d50d', 'ip', '-6', 'route', 'list', 'dev', 'tap995da463-09', 'scope', 'link'] Command: ['sudo', '/usr/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'netns', 'exec', 'qdhcp-5be9fe58-0790-4342-9182-172438e8e0bc', 'ip', '-6', 'route', 'list', 'dev', 'tap5c7f794d-08', 'scope', 'link'] Command: ['sudo', '/usr/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'netns', 'exec', 'qdhcp-f2a73fc1-6a93-4822-aa45-b789d50d', 'ip', 'route', 'list', 'dev', 'tap995da463-09'] Stdout: 20.0.1.0/24 proto kernel scope link src 20.0.1.36 169.254.0.0/16 proto kernel scope link src 169.254.169.254 2016-12-20 09:02:44.154 DEBUG neutron.agent.linux.dhcp [-] Building initial lease file: /var/lib/neutron/dhcp/f2a73fc1-6a93-4822-aa
[Yahoo-eng-team] [Bug 1158684] Re: Pre-created ports get deleted on VM delete
** Also affects: ironic 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/1158684 Title: Pre-created ports get deleted on VM delete Status in Group Based Policy: Won't Fix Status in heat: Invalid Status in Ironic: New Status in OpenStack Compute (nova): Fix Released Bug description: 1) Pre create a port using port-create 2) Boot a VM with nova boot --nic port_id= 3) Delete a VM. Expected: VM should boot using provided port_id at boot time. When VM is deleted, port corresponding to pre-created port_id should not get deleted, as a lot of application, security settings could have port properties configured in them in a large network. Observed behavior: There is no way, I could prevent port_id associated with VM from being deleted with nova delete. To manage notifications about this bug go to: https://bugs.launchpad.net/group-based-policy/+bug/1158684/+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 1635674] Re: 'hw:cpu_thread_policy=isolate' is not accounted properly on non-HT hosts
Reviewed: https://review.openstack.org/391416 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=9f12b592d1d26a985699fefde2a7ce0164d0b5d3 Submitter: Jenkins Branch:master commit 9f12b592d1d26a985699fefde2a7ce0164d0b5d3 Author: Sergey Nikitin Date: Fri Dec 9 17:42:14 2016 +0400 Mark sibling CPUs as 'used' for cpu_thread_policy = 'isolated' 'isolated' CPU allocation thread policy is guarantee that no vCPUs from other guests wouldn't be able to be placed on the cores of booted VM (In this case core is a set of sibling vCPUs). But we still able to boot VMs with 'dedicated' CPU allocation policy on these cores. This problem is actual for hosts without HyperThreading. In this case sets of siblings vCPUs are empty for each core but we are still trying to work with them as with HyperThreading cores. This causes the problem when one "isolated" core is used by several VMs. To fix it we must use method unpin_cpus_with_siblings() only if NUMA cell has siblings (i.e. has HyperThreading). For cells without HyperThreading CPU isolation is guaranteed by 'dedicated' CPU allocation policy. Closes-Bug: #1635674 Change-Id: I8f72187153c930cd941b7ee7e835a20ed0c0de03 ** 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/1635674 Title: 'hw:cpu_thread_policy=isolate' is not accounted properly on non-HT hosts Status in OpenStack Compute (nova): Fix Released Bug description: If an instance with 'hw:cpu_thread_policy=isolate' is scheduled on a non-HT host, the pinned pCPUs are not properly accounted for. This can lead to multiple instances running on the same pCPUs The problem is that in LibvirtDriver._get_host_numa_topology() when calculating the NUMACell.siblings field we filter out single cpus. On a non-HT host this means that NUMACell.siblings is an empty list. Later when _update_usage() runs it ends up eventually running NUMACell.pin_cpus_with_siblings(). This contains the following code: def pin_cpus_with_siblings(self, cpus): pin_siblings = set() for sib in self.siblings: if cpus & sib: pin_siblings.update(sib) self.pin_cpus(pin_siblings) Since "self.siblings" is empty, we end up calling self.pin_cpus() with an empty list, which means that we don't update self.pinned_cpus. Stephen Finucane has suggested the correct fix might be to leave single pCPUs in the NUMACell.siblings field. This needs to be verified to make sure that it doesn't cause other problems. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1635674/+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 1646779] Re: libvirt killed by kernel on general protection or stack segment traps
I marked this as incomplete from a Tempest POV - I couldn't find
anything wrong with the tests in Tempest that seem to trigger this,
apart from triggering sometimes what looks like a libvirt issue.
** Also affects: libvirt
Importance: Undecided
Status: New
** Changed in: tempest
Status: New => Incomplete
--
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/1646779
Title:
libvirt killed by kernel on general protection or stack segment traps
Status in libvirt:
New
Status in OpenStack Compute (nova):
Incomplete
Status in tempest:
Incomplete
Bug description:
A VM fails to spawn with no host available. The nova-cpu logs reveals
a problem connecting to libvirt. 84 hits since Nov 23rd:
message: "libvirtError: Failed to connect socket to '/var/run/libvirt
/libvirt-sock': Connection refused"
Recent failure: http://logs.openstack.org/66/401366/4/gate/gate-
tempest-dsvm-neutron-full-ubuntu-
xenial/3deacc5/logs/screen-n-cpu.txt.gz?level=ERROR
2016-12-01 18:16:05.117 6160 ERROR nova.virt.libvirt.host
[req-12fbb338-7df0-4654-b686-257245421442
tempest-ImagesOneServerNegativeTestJSON-1400886372
tempest-ImagesOneServerNegativeTestJSON-1400886372] Connection to libvirt
failed: Failed to connect socket to '/var/run/libvirt/libvirt-sock': Connection
refused
2016-12-01 18:16:05.117 6160 ERROR nova.virt.libvirt.host Traceback (most
recent call last):
2016-12-01 18:16:05.117 6160 ERROR nova.virt.libvirt.host File
"/opt/stack/new/nova/nova/virt/libvirt/host.py", line 453, in get_connection
2016-12-01 18:16:05.117 6160 ERROR nova.virt.libvirt.host conn =
self._get_connection()
2016-12-01 18:16:05.117 6160 ERROR nova.virt.libvirt.host File
"/opt/stack/new/nova/nova/virt/libvirt/host.py", line 436, in _get_connection
2016-12-01 18:16:05.117 6160 ERROR nova.virt.libvirt.host {'msg': ex})
2016-12-01 18:16:05.117 6160 ERROR nova.virt.libvirt.host File
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in
__exit__
2016-12-01 18:16:05.117 6160 ERROR nova.virt.libvirt.host
self.force_reraise()
2016-12-01 18:16:05.117 6160 ERROR nova.virt.libvirt.host File
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in
force_reraise
2016-12-01 18:16:05.117 6160 ERROR nova.virt.libvirt.host
six.reraise(self.type_, self.value, self.tb)
2016-12-01 18:16:05.117 6160 ERROR nova.virt.libvirt.host File
"/opt/stack/new/nova/nova/virt/libvirt/host.py", line 425, in _get_connection
2016-12-01 18:16:05.117 6160 ERROR nova.virt.libvirt.host
self._wrapped_conn = self._get_new_connection()
2016-12-01 18:16:05.117 6160 ERROR nova.virt.libvirt.host File
"/opt/stack/new/nova/nova/virt/libvirt/host.py", line 370, in
_get_new_connection
2016-12-01 18:16:05.117 6160 ERROR nova.virt.libvirt.host wrapped_conn =
self._connect(self._uri, self._read_only)
2016-12-01 18:16:05.117 6160 ERROR nova.virt.libvirt.host File
"/opt/stack/new/nova/nova/virt/libvirt/host.py", line 226, in _connect
2016-12-01 18:16:05.117 6160 ERROR nova.virt.libvirt.host
libvirt.openAuth, uri, auth, flags)
2016-12-01 18:16:05.117 6160 ERROR nova.virt.libvirt.host File
"/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 144, in
proxy_call
2016-12-01 18:16:05.117 6160 ERROR nova.virt.libvirt.host rv = execute(f,
*args, **kwargs)
2016-12-01 18:16:05.117 6160 ERROR nova.virt.libvirt.host File
"/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 125, in execute
2016-12-01 18:16:05.117 6160 ERROR nova.virt.libvirt.host six.reraise(c,
e, tb)
2016-12-01 18:16:05.117 6160 ERROR nova.virt.libvirt.host File
"/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 83, in tworker
2016-12-01 18:16:05.117 6160 ERROR nova.virt.libvirt.host rv =
meth(*args, **kwargs)
2016-12-01 18:16:05.117 6160 ERROR nova.virt.libvirt.host File
"/usr/local/lib/python2.7/dist-packages/libvirt.py", line 105, in openAuth
2016-12-01 18:16:05.117 6160 ERROR nova.virt.libvirt.host if ret is
None:raise libvirtError('virConnectOpenAuth() failed')
2016-12-01 18:16:05.117 6160 ERROR nova.virt.libvirt.host libvirtError:
Failed to connect socket to '/var/run/libvirt/libvirt-sock': Connection refused
2016-12-01 18:16:05.117 6160 ERROR nova.virt.libvirt.host
2016-12-01 18:16:05.123 6160 ERROR nova.compute.manager
[req-12fbb338-7df0-4654-b686-257245421442
tempest-ImagesOneServerNegativeTestJSON-1400886372
tempest-ImagesOneServerNegativeTestJSON-1400886372] [instance:
6fa73b04-c6a7-47a8-908b-6738f36f6ffc] Instance failed to spawn
2016-12-01 18:16:05.123 6160 ERROR nova.compute.manager [instance:
6fa73b04-c6a7-47a8-908b-6738f36f6ffc] Traceback (most recent call last):
2016-12-01 18:16:05.123 6160 ERROR nova.compute.manager [instance:
6fa73b04-c6a
