[Yahoo-eng-team] [Bug 1744846] [NEW] Show all when the network list or router list filtered by tenant
Public bug reported: 1.Access Admin->Netwrok->Netwroks or Admin->Network->Routers and select the tenant filter; 2.Filter a tenant which does not exist; 3.Now,the all result will be shown in page, not an empty list. ** Affects: horizon Importance: Undecided Assignee: Wangliangyu (wangly) Status: New ** Changed in: horizon Assignee: (unassigned) => Wangliangyu (wangly) -- 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/1744846 Title: Show all when the network list or router list filtered by tenant Status in OpenStack Dashboard (Horizon): New Bug description: 1.Access Admin->Netwrok->Netwroks or Admin->Network->Routers and select the tenant filter; 2.Filter a tenant which does not exist; 3.Now,the all result will be shown in page, not an empty list. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1744846/+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 1744780] Re: Nova::Cell_v2::Simple_setup/Nova_cell_v2[cell0] fails on master promote
Reviewed: https://review.openstack.org/536546 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=0467b537bfcf0cb973eb74b49ff7207dafbdbdbc Submitter: Zuul Branch:master commit 0467b537bfcf0cb973eb74b49ff7207dafbdbdbc Author: Dan Smith Date: Mon Jan 22 11:57:53 2018 -0800 Fix update_cell to ignore existing identical cells The recent cell duplication filter makes it impossible to do update_cell on an existing cell with identical details. If we're updating a cell by uuid and specify the exact same parameters, we shouldn't signal failure. Change-Id: I2faaec9bc7d29fda1facd22e0da3bc6f01f9 Closes-Bug: #1744780 ** 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/1744780 Title: Nova::Cell_v2::Simple_setup/Nova_cell_v2[cell0] fails on master promote Status in OpenStack Compute (nova): Fix Released Status in tripleo: Triaged Bug description: FS20 is failing in the promote pipeline for master during deploy. It looks like we have a regression in either nova or puppet-nova. The error in the deploy logs is: "Error: /Stage[main]/Nova::Cell_v2::Simple_setup/Nova_cell_v2[cell0]: Could not evaluate: Execution of '/usr/bin/nova-manage cell_v2 update_cell --cell_uuid ---- --transport-url none:/// --database_connection mysql+pymysql://nova:QWDqCAV6AmavmFxPPpxCJecd6@192.168.24.8/nova_cell0?read_default_group=tripleo&read_default_file=/etc/my.cnf.d/tripleo.cnf' returned 3: The specified transport_url and/or database_connection combination already exists for another cell with uuid ----.", Full logs for the job at: https://logs.rdoproject.org/openstack-periodic/periodic-tripleo-ci- centos-7-ovb-1ctlr_1comp-featureset020-master/12230cb To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1744780/+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 1744829] [NEW] Avoid mixed usage of old and new transaction styles
Public bug reported: The newly merged (distributed) Port Binding OVO integration patch [1] is mixing the old nested transaction style used by OVO with the new engine facade transactions. According to what we learnt in https://review.openstack.org/#/c/529169 and https://review.openstack.org/#/c/532343, this shouldn't be done. A patch to change the new engine facade transactions back to old nested transaction style is required. [1] https://review.openstack.org/#/c/407868 ** Affects: neutron Importance: Undecided Assignee: Lujin Luo (luo-lujin) Status: New ** Changed in: neutron Assignee: (unassigned) => Lujin Luo (luo-lujin) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1744829 Title: Avoid mixed usage of old and new transaction styles Status in neutron: New Bug description: The newly merged (distributed) Port Binding OVO integration patch [1] is mixing the old nested transaction style used by OVO with the new engine facade transactions. According to what we learnt in https://review.openstack.org/#/c/529169 and https://review.openstack.org/#/c/532343, this shouldn't be done. A patch to change the new engine facade transactions back to old nested transaction style is required. [1] https://review.openstack.org/#/c/407868 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1744829/+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 1374508] Re: Mismatch happens between BDM and domain XML If instance does not respond to ACPI hotplug during detach/attach.
** Also affects: nova (Ubuntu Trusty) 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/1374508 Title: Mismatch happens between BDM and domain XML If instance does not respond to ACPI hotplug during detach/attach. Status in OpenStack Compute (nova): Fix Released Status in nova package in Ubuntu: New Status in nova source package in Trusty: New Bug description: tempest.api.compute.servers.test_server_rescue_negative:ServerRescueNegativeTestJSON.test_rescued_vm_detach_volume This test passes however it fails to properly cleanup after itself - the detach completes but without running the necessary iscsiadm commands. In nova.virt.libvirt.volume.LibvirtISCSIVolumeDriver.disconnect_volume the list returned by self.connection._get_all_block_devices includes the host_device which means that self._disconnect_from_iscsi_portal is never run. You can see evidence of this in /etc/iscsi/nodes as well as errors logged in /var/log/syslog I'm guessing there is a race between the unrescue and the detach within libvirt. In nova.virt.libvirt.driver.LibvirtDriver.detach_volume if I put in a sleep before virt_dom.detachDeviceFlags(xml, flags) the detach appears to work properly however if I sleep after that line it does not appear to have any effect. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1374508/+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 1374508] Re: Mismatch happens between BDM and domain XML If instance does not respond to ACPI hotplug during detach/attach.
** Also affects: nova (Ubuntu) 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/1374508 Title: Mismatch happens between BDM and domain XML If instance does not respond to ACPI hotplug during detach/attach. Status in OpenStack Compute (nova): Fix Released Status in nova package in Ubuntu: New Status in nova source package in Trusty: New Bug description: tempest.api.compute.servers.test_server_rescue_negative:ServerRescueNegativeTestJSON.test_rescued_vm_detach_volume This test passes however it fails to properly cleanup after itself - the detach completes but without running the necessary iscsiadm commands. In nova.virt.libvirt.volume.LibvirtISCSIVolumeDriver.disconnect_volume the list returned by self.connection._get_all_block_devices includes the host_device which means that self._disconnect_from_iscsi_portal is never run. You can see evidence of this in /etc/iscsi/nodes as well as errors logged in /var/log/syslog I'm guessing there is a race between the unrescue and the detach within libvirt. In nova.virt.libvirt.driver.LibvirtDriver.detach_volume if I put in a sleep before virt_dom.detachDeviceFlags(xml, flags) the detach appears to work properly however if I sleep after that line it does not appear to have any effect. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1374508/+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 1744645] Re: Pass vlan-id value during net-create
** Changed in: neutron Status: Incomplete => 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/1744645 Title: Pass vlan-id value during net-create Status in neutron: Invalid Bug description: User should be able to pass vlan-id as a parameter during net-create call. if this value is not passed auto assignment should work. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1744645/+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 1744824] [NEW] functional tests broken under py27
Public bug reported: Over the weekend, the py27 tests began failing. To reproduce, you need to use an upgraded Ubuntu. It appears to be a distro package issue (though it's not clear ATM what package). The failing tests are functional tests, the unit tests pass OK. The py35 tests all pass (both unit and functional). In the meantime, the requirements team has dropped the glance py27 tests from the requirements gate: https://review.openstack.org/#/c/536082/ We should fix soon to get our tests back into the gate to prevent other bad stuff from happening to glance. ** Affects: glance Importance: Critical Status: Triaged -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1744824 Title: functional tests broken under py27 Status in Glance: Triaged Bug description: Over the weekend, the py27 tests began failing. To reproduce, you need to use an upgraded Ubuntu. It appears to be a distro package issue (though it's not clear ATM what package). The failing tests are functional tests, the unit tests pass OK. The py35 tests all pass (both unit and functional). In the meantime, the requirements team has dropped the glance py27 tests from the requirements gate: https://review.openstack.org/#/c/536082/ We should fix soon to get our tests back into the gate to prevent other bad stuff from happening to glance. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1744824/+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 1739593] Re: Swapping encrypted volumes can lead to data loss and a possible compute host DOS attack
Reviewed: https://review.openstack.org/460243 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=cd3eb60c2c00bcccfa9ccd4bf9d1a96ae7a5cd88 Submitter: Zuul Branch:master commit cd3eb60c2c00bcccfa9ccd4bf9d1a96ae7a5cd88 Author: Lee Yarwood Date: Mon Apr 24 19:23:44 2017 +0100 libvirt: Collocate encryptor and volume driver calls This change introduces new utility methods for attaching and detaching frontend volume encryptors. These methods centralise the optional fetching of encryption metadata associated with a volume, fetching of the required encryptor and calls to detach or attach the encryptor. These new utility methods are called either after initially connecting to or before disconnecting from a volume. This ensures encryptors are correctly connected when swapping volumes for example, where previously no attempt was made to attach an encryptor to the target volume. The request context is provided to swap_volume and various other config generation related methods to allow for the lookup of the relevant encryption metadata if it is not provided. Closes-bug: #1739593 Change-Id: Ica323b87fa85a454fca9d46ada3677f18fe50022 ** 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/1739593 Title: Swapping encrypted volumes can lead to data loss and a possible compute host DOS attack Status in OpenStack Compute (nova): Fix Released Status in OpenStack Security Advisory: Incomplete Bug description: Description === At present when swapping encrypted volumes no attempt is made to attach an encryptor to the target volume. This results in the RAW underlying volume being used during the rebase, where decrypted data is copied from the original volume to the target: https://github.com/openstack/nova/blob/76dfdfc1ad8c0e5376bd997e45f65bec9ff53d12/nova/virt/libvirt/driver.py#L1338-L1372 Any attempt to detach and then reattach this volume from the instance will lead to the volume being reformatted as the os-brick supplied encryptors do not identify the volume as encrypted: https://github.com/openstack/os- brick/blob/6835b885dc4144fdc6e9863ca59ae54f76938995/os_brick/encryptors/luks.py#L138-L161 Additionally, while unlikely, a malicious user could easily DOS the compute node hosting the instance by writing a corrupt LUKS header to the RAW volume before detaching and reattaching the volume. For example, setting a keyslot iters (used by PBKDF2) to a large value etc (kudos to mdbooth for suggesting this): https://gitlab.com/cryptsetup/cryptsetup/wikis/LUKS-standard/on-disk- format.pdf This method of DOS'ing the compute host was previously discussed in the context of bug 1724573 but dismissed as access to the underlying volume was dependent on a host reboot, outside of a users control. This bug differs as a user has full control of the above volume- update/swap_volume flow that provides access to the underlying volume. Steps to reproduce == - Create two encrypted volumes $ cinder type-create LUKS $ cinder encryption-type-create --cipher aes-xts-plain64 \ --key_size 256 \ --control_location front-end LUKS luks $ cinder type-create LUKS_NEW $ cinder encryption-type-create --cipher aes-xts-plain64 \ --key_size 256 \ --control_location front-end LUKS_NEW luks $ cinder create --volume-type LUKS 1 $ cinder create --volume-type LUKS_NEW 1 - Spawn an instance, attaching the first volume before swapping to the second: $ nova boot --image cirros-0.3.5-x86_64-disk --flavor 1 swap_test $ nova volume-attach $instance $vol-luks $ nova volume-update $instance $vol-luks $vol-luks-new - Review the resulting volume attachment on the compute host: $ virsh domblklist $instance Target Source vda /opt/stack/data/nova/instances/3d4c5842-45ab-4660-bf6e-9459f9a2ff8a/disk vdb/dev/disk/by-id/scsi-36001405ba072cc9f93e444c9433ead1c $ ll /dev/disk/by-id/scsi-36001405ba072cc9f93e444c9433ead1c lrwxrwxrwx. 1 root root 9 Dec 21 05:30 /dev/disk/by-id/scsi-36001405ba072cc9f93e444c9433ead1c -> ../../sdd $ sudo qemu-img info /dev/disk/by-id/scsi-36001405ba072cc9f93e444c9433ead1c image: /dev/disk/by-id/scsi-36001405ba072cc9f93e444c9433ead1c file format: raw virtual size: 1.0G (1073741824 bytes) disk size: 0 Expected result === The encrypted volumes are rebased with their associated encryptors attached, leading to encrypted data being written to the underlying volumes. Actual result = Decrypte
[Yahoo-eng-team] [Bug 1660612] Re: gate-tempest-dsvm-neutron-linuxbridge-ubuntu-xenial times out on execution
Other jobs, not just linuxbridge, are also affected. For example, DVR/pike job here: http://logs.openstack.org/08/533308/1/check/neutron- tempest-dvr/bfc4761/ara/ ** Summary changed: - gate-tempest-dsvm-neutron-linuxbridge-ubuntu-xenial times out on execution + Tempest full jobs time out on execution ** Tags removed: linuxbridge ** Also affects: tempest 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/1660612 Title: Tempest full jobs time out on execution Status in neutron: Confirmed Status in tempest: New Bug description: It took a bit above 1 hour to run tempest with linux bridge agent and then the job was terminated: http://logs.openstack.org/47/416647/4/check/gate-tempest-dsvm-neutron- linuxbridge-ubuntu- xenial/7d1d4e5/console.html#_2017-01-30_17_51_50_343819 e-r-q: http://logstash.openstack.org/#dashboard/file/logstash.json?query=build_name %3Agate-tempest-dsvm-neutron-linuxbridge-ubuntu- xenial%20AND%20message%3A%5C%22Killed%5C%22%20AND%20message%3A%5C%22timeout%20-s%209%5C%22%20AND%20tags%3Aconsole To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1660612/+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 1744796] [NEW] cloud-init status traceback on successful Ec2
Public bug reported:
On Ec2 successful deployments, the command cloud-init status hits the following
traceback:
cloud-init status
Traceback (most recent call last):
File "/usr/bin/cloud-init", line 11, in
load_entry_point('cloud-init==17.2', 'console_scripts', 'cloud-init')()
File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 853, in main
get_uptime=True, func=functor, args=(name, args))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2279, in
log_time
ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/cmd/status.py", line 55, in
handle_status_args
status, status_detail, time = _get_status_details(init.paths)
File "/usr/lib/python3/dist-packages/cloudinit/cmd/status.py", line 114, in
_get_status_details
CLOUDINIT_DISABLED_FILE, paths)
File "/usr/lib/python3/dist-packages/cloudinit/cmd/status.py", line 96, in
_is_cloudinit_disabled
return (is_disabled, reason)
UnboundLocalError: local variable 'reason' referenced before assignment
In Ec2's case, modules-init is never run because we detect the datasource in
init-local timeframe. As a result the status.json looks like this (note that
start and finished are both null on mondules-init stage:
{
"v1": {
"datasource": "DataSourceEc2Local",
"init": {
"errors": [],
"finished": 1515706844.3537874,
"start": 1515706843.7459064
},
"init-local": {
"errors": [],
"finished": 1515706841.0270455,
"start": 1515706840.1508064
},
"modules-config": {
"errors": [],
"finished": 1515706846.916724,
"start": 1515706846.218318
},
"modules-final": {
"errors": [],
"finished": 1515706847.6123502,
"start": 1515706847.2455244
},
"modules-init": {
"errors": [],
"finished": null,
"start": null
},
"stage": null
}
}
** Affects: cloud-init
Importance: Medium
Assignee: Chad Smith (chad.smith)
Status: In Progress
** Changed in: cloud-init
Importance: Undecided => Medium
** Changed in: cloud-init
Status: New => In Progress
** Changed in: cloud-init
Assignee: (unassigned) => Chad Smith (chad.smith)
--
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/1744796
Title:
cloud-init status traceback on successful Ec2
Status in cloud-init:
In Progress
Bug description:
On Ec2 successful deployments, the command cloud-init status hits the
following traceback:
cloud-init status
Traceback (most recent call last):
File "/usr/bin/cloud-init", line 11, in
load_entry_point('cloud-init==17.2', 'console_scripts', 'cloud-init')()
File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 853, in
main
get_uptime=True, func=functor, args=(name, args))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2279, in
log_time
ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/cmd/status.py", line 55, in
handle_status_args
status, status_detail, time = _get_status_details(init.paths)
File "/usr/lib/python3/dist-packages/cloudinit/cmd/status.py", line 114, in
_get_status_details
CLOUDINIT_DISABLED_FILE, paths)
File "/usr/lib/python3/dist-packages/cloudinit/cmd/status.py", line 96, in
_is_cloudinit_disabled
return (is_disabled, reason)
UnboundLocalError: local variable 'reason' referenced before assignment
In Ec2's case, modules-init is never run because we detect the datasource in
init-local timeframe. As a result the status.json looks like this (note that
start and finished are both null on mondules-init stage:
{
"v1": {
"datasource": "DataSourceEc2Local",
"init": {
"errors": [],
"finished": 1515706844.3537874,
"start": 1515706843.7459064
},
"init-local": {
"errors": [],
"finished": 1515706841.0270455,
"start": 1515706840.1508064
},
"modules-config": {
"errors": [],
"finished": 1515706846.916724,
"start": 1515706846.218318
},
"modules-final": {
"errors": [],
"finished": 1515706847.6123502,
"start": 1515706847.2455244
},
"modules-init": {
"errors": [],
"finished": null,
"start": null
},
"stage": null
}
}
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1744796/+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 1744786] [NEW] SchedulerReportClient.put with empty (not None) payload errors 415
Public bug reported:
https://github.com/openstack/nova/blob/f0d830d56d20c7f34372cd3c68d13a94bdf645a6/nova/scheduler/client/report.py#L295-L302
295 def put(self, url, data, version=None):
296 # NOTE(sdague): using json= instead of data= sets the
297 # media type to application/json for us. Placement API is
298 # more sensitive to this than other APIs in the OpenStack
299 # ecosystem.
300 kwargs = {'microversion': version}
301 if data:
302 kwargs['json'] = data
On line 301, if data is a False value other than None, we won't set the
json kwarg, so Session won't set the content type to application/json,
and we'll run afoul of:
415 Unsupported Media Type
415 Unsupported Media Type
The request media type None is not supported by this server.
The media type None is not supported, use application/json
A normal "workaround" - which is being used for e.g. inventories - is
for the caller to check for "empty" and hit the DELETE API instead.
But we don't have a DELETE API for resource provider aggregates
(/resource_providers/{u}/aggregates).
** 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/1744786
Title:
SchedulerReportClient.put with empty (not None) payload errors 415
Status in OpenStack Compute (nova):
New
Bug description:
https://github.com/openstack/nova/blob/f0d830d56d20c7f34372cd3c68d13a94bdf645a6/nova/scheduler/client/report.py#L295-L302
295 def put(self, url, data, version=None):
296 # NOTE(sdague): using json= instead of data= sets the
297 # media type to application/json for us. Placement API is
298 # more sensitive to this than other APIs in the OpenStack
299 # ecosystem.
300 kwargs = {'microversion': version}
301 if data:
302 kwargs['json'] = data
On line 301, if data is a False value other than None, we won't set
the json kwarg, so Session won't set the content type to
application/json, and we'll run afoul of:
415 Unsupported Media Type
415 Unsupported Media Type
The request media type None is not supported by this server.
The media type None is not supported, use application/json
A normal "workaround" - which is being used for e.g. inventories - is
for the caller to check for "empty" and hit the DELETE API instead.
But we don't have a DELETE API for resource provider aggregates
(/resource_providers/{u}/aggregates).
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1744786/+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 1744780] Re: Nova::Cell_v2::Simple_setup/Nova_cell_v2[cell0] fails on master promote
That fix needs to omit the cell being updated from the cells that are inspected for conflicts. ** Also affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1744780 Title: Nova::Cell_v2::Simple_setup/Nova_cell_v2[cell0] fails on master promote Status in OpenStack Compute (nova): New Status in tripleo: Triaged Bug description: FS20 is failing in the promote pipeline for master during deploy. It looks like we have a regression in either nova or puppet-nova. The error in the deploy logs is: "Error: /Stage[main]/Nova::Cell_v2::Simple_setup/Nova_cell_v2[cell0]: Could not evaluate: Execution of '/usr/bin/nova-manage cell_v2 update_cell --cell_uuid ---- --transport-url none:/// --database_connection mysql+pymysql://nova:QWDqCAV6AmavmFxPPpxCJecd6@192.168.24.8/nova_cell0?read_default_group=tripleo&read_default_file=/etc/my.cnf.d/tripleo.cnf' returned 3: The specified transport_url and/or database_connection combination already exists for another cell with uuid ----.", Full logs for the job at: https://logs.rdoproject.org/openstack-periodic/periodic-tripleo-ci- centos-7-ovb-1ctlr_1comp-featureset020-master/12230cb To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1744780/+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 1735588] Re: Mock autospec not used, or not used properly
Reviewed: https://review.openstack.org/532619 Committed: https://git.openstack.org/cgit/openstack/os-win/commit/?id=823b162c6a02083f6ae6f6ce27150c039687993d Submitter: Zuul Branch:master commit 823b162c6a02083f6ae6f6ce27150c039687993d Author: Claudiu Belu Date: Wed Jan 10 21:47:21 2018 +0200 tests: Use mock autospec in unit tests Autospecing will ensure that the method signatures are respected during calls. oslotest.mock_fixture contains 2 components, one of them adds the autospec argument to mock.Mock and mock.MagicMock, while the other one fixes the autospec behaviour for mock.patch functions, and sets autospec to True by default, unless otherwise specified. Closes-Bug: #1735588 Change-Id: I5a1dd8571988859b4a14a505fd5e016079582363 ** Changed in: os-win 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/1735588 Title: Mock autospec not used, or not used properly Status in networking-hyperv: In Progress Status in OpenStack Compute (nova): In Progress Status in os-win: Fix Released Status in oslotest: Fix Released Bug description: Description === In typical unit tests, almost all of the dependencies are mocked or patched (mock.patch), without any guarantee that the mocked methods actually exist, or if their signatures are respected (see below). Because of this, actual issues can easily be overlooked and missed, as the unit tests are wrongfully passing. [0] The mock.Mock class accepts a spec as an argument, which only solves half the problem: it only checks if an attribute exists, based on the given spec. It does not guarantee that the given attribute is actually a method, or if its signature is respected [1][2]. Some unit tests may pass the autospec argument, but mock doesn't support it at the moment. mock.patch, mock.patch.object, mock.patch.multiple accept an autospec argument, but because of a bug [3][4], it cannot be used properly. Steps to reproduce == import mock from mock.tests import testmock m = mock.Mock(spec=testmock.Something) # meth has the following signature: # def meth(self, a, b, c, d=None): m.meth() Expected result === TypeError should be raised. Actual result = A mock object is returned. Proposal Bug reports have been issues for the bugs mentioned above, see [1][2][3][4], but until then, the mock library can be patched to include the following changes: - add autospec argument to mock.Mock and mock.MagicMock. Unit test should then pass the autospec argument whenever possible. - fix the mock.patch autospec issue. - enable mock.patch autospec by default, unless otherwise specified. Links = [0] https://review.openstack.org/#/c/461689/ [1] https://github.com/testing-cabal/mock/issues/393 [2] https://bugs.python.org/issue30587 [3] https://github.com/testing-cabal/mock/issues/396 [4] https://bugs.python.org/issue32092 To manage notifications about this bug go to: https://bugs.launchpad.net/networking-hyperv/+bug/1735588/+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 1696866] Re: Cinder LVM driver and ipv6 broken
** Changed in: oslo.config Status: New => Incomplete ** Changed in: oslo.config Status: Incomplete => 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/1696866 Title: Cinder LVM driver and ipv6 broken Status in Cinder: Incomplete Status in OpenStack Compute (nova): Invalid Status in oslo.config: Invalid Status in tripleo: Fix Released Bug description: The following traceback is seen in the cinder volume logs if you deploy with the default LVM driver and ipv6: 2017-06-08 21:50:40.665 38554 CRITICAL cinder [req-a7aff57e-2042-48f2-b1eb-962f79ccda01 - - - - -] ConfigFileValueError: Value for option iscsi_ip_address is not valid: [fd00:fd00:fd00:3000::12] is not a valid host address 2017-06-08 21:50:40.665 38554 ERROR cinder Traceback (most recent call last): 2017-06-08 21:50:40.665 38554 ERROR cinder File "/usr/bin/cinder-volume", line 10, in 2017-06-08 21:50:40.665 38554 ERROR cinder sys.exit(main()) 2017-06-08 21:50:40.665 38554 ERROR cinder File "/usr/lib/python2.7/site-packages/cinder/cmd/volume.py", line 120, in main 2017-06-08 21:50:40.665 38554 ERROR cinder launcher.wait() 2017-06-08 21:50:40.665 38554 ERROR cinder File "/usr/lib/python2.7/site-packages/oslo_service/service.py", line 581, in wait 2017-06-08 21:50:40.665 38554 ERROR cinder self.conf.log_opt_values(LOG, logging.DEBUG) 2017-06-08 21:50:40.665 38554 ERROR cinder File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 2799, in log_opt_values 2017-06-08 21:50:40.665 38554 ERROR cinder _sanitize(opt, getattr(group_attr, opt_name))) 2017-06-08 21:50:40.665 38554 ERROR cinder File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 3277, in __getattr__ 2017-06-08 21:50:40.665 38554 ERROR cinder return self._conf._get(name, self._group) 2017-06-08 21:50:40.665 38554 ERROR cinder File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 2841, in _get 2017-06-08 21:50:40.665 38554 ERROR cinder value = self._do_get(name, group, namespace) 2017-06-08 21:50:40.665 38554 ERROR cinder File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 2884, in _do_get 2017-06-08 21:50:40.665 38554 ERROR cinder % (opt.name, str(ve))) 2017-06-08 21:50:40.665 38554 ERROR cinder ConfigFileValueError: Value for option iscsi_ip_address is not valid: [fd00:fd00:fd00:3000::12] is not a valid host address The problem appears to be that we bracket the value. If I remove the brackets then cinder volume works correctly. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1696866/+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 1744742] [NEW] table:show checkbox when there is no BatchAction
Public bug reported: In the table, the check box in the first column can also be a batch box. The check box is visible when there is at least one batch action in the table, not a bound action ** Affects: horizon Importance: Undecided Assignee: Wangliangyu (wangly) Status: In Progress -- 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/1744742 Title: table:show checkbox when there is no BatchAction Status in OpenStack Dashboard (Horizon): In Progress Bug description: In the table, the check box in the first column can also be a batch box. The check box is visible when there is at least one batch action in the table, not a bound action To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1744742/+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 1427665] Re: AttributeError: 'RequestContext' object has no attribute 'user_id'
** Changed in: oslo.log
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/1427665
Title:
AttributeError: 'RequestContext' object has no attribute 'user_id'
Status in OpenStack Compute (nova):
Invalid
Status in oslo.log:
Invalid
Bug description:
Example from:
http://logs.openstack.org/47/122347/16/check/check-tempest-dsvm-full/e958fa0/logs/screen-n-cpu.txt.gz
Traceback (most recent call last):
File "/usr/lib/python2.7/logging/__init__.py", line 851, in emit
msg = self.format(record)
File "/usr/local/lib/python2.7/dist-packages/oslo_log/handlers.py", line
69, in format
return logging.StreamHandler.format(self, record)
File "/usr/lib/python2.7/logging/__init__.py", line 724, in format
return fmt.format(record)
File "/usr/local/lib/python2.7/dist-packages/oslo_log/formatters.py", line
178, in format
context = _update_record_with_context(record)
File "/usr/local/lib/python2.7/dist-packages/oslo_log/formatters.py", line
56, in _update_record_with_context
d = _dictify_context(context)
File "/usr/local/lib/python2.7/dist-packages/oslo_log/formatters.py", line
31, in _dictify_context
context = context.to_dict()
File "/opt/stack/new/nova/nova/context.py", line 157, in to_dict
values.update({'user_id': self.user_id,
AttributeError: 'RequestContext' object has no attribute 'user_id'
Logged from file context.py, line 97
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1427665/+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 1230360] Re: keystone-all --log-file logs to stdout
The default for use_stderr was changed to False. ** Changed in: oslo.log Status: Triaged => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1230360 Title: keystone-all --log-file logs to stdout Status in OpenStack Identity (keystone): Invalid Status in oslo.log: Fix Released Bug description: The help text for keystone-all says if I set --log-file then logging goes to the output file, otherwise it goes to stdout. But logging goes to stdout whether I set --log-file or not. Here's the output without --log-file: $ tools/with_venv.sh bin/keystone-all 2013-09-25 10:35:40.229 3406 INFO keystone.common.environment [-] Environment configured as: eventlet 2013-09-25 10:35:40.652 3406 WARNING keystone.token.provider [-] keystone.conf [signing] token_format is deprecated in favor of keystone.conf [token] provider 2013-09-25 10:35:40.747 3406 INFO keystone.common.environment.eventlet_server [-] Starting bin/keystone-all on 0.0.0.0:35357 2013-09-25 10:35:40.751 3406 INFO keystone.common.environment.eventlet_server [-] Starting bin/keystone-all on 0.0.0.0:5000 Here's the output with --log-file: $ tools/with_venv.sh bin/keystone-all --log-file /tmp/keystone-log1.txt 2013-09-25 10:35:54.747 3425 INFO keystone.common.environment [-] Environment configured as: eventlet 2013-09-25 10:35:55.168 3425 WARNING keystone.token.provider [-] keystone.conf [signing] token_format is deprecated in favor of keystone.conf [token] provider 2013-09-25 10:35:55.262 3425 INFO keystone.common.environment.eventlet_server [-] Starting bin/keystone-all on 0.0.0.0:35357 2013-09-25 10:35:55.266 3425 INFO keystone.common.environment.eventlet_server [-] Starting bin/keystone-all on 0.0.0.0:5000 I expected that when I used --log-file that there would be no ouput to stdout. Note that it wrote the same thing to the log file so maybe this is expected. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1230360/+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 1743860] Re: allocation candidates db backend can handle traits but the HTTP front end is not turned on
Apparently this was mostly expected, but not fully documented, so going to invalidate the bug. https://review.openstack.org/#/c/535642/ ** 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/1743860 Title: allocation candidates db backend can handle traits but the HTTP front end is not turned on Status in OpenStack Compute (nova): Invalid Bug description: The code for /allocation_candidates is set up to be able to process a 'required' parameter alongside the 'resources' parameter. This results in a collection of RequestGroups which are used by the AllocationCandidates code in nova/objects/resource_provider.py But we can't request traits on /allocation_candidates because the json schema does not allow the 'required' parameter. Adding that results in a system that appears to work modulo at least one issue: * AllocationCandidates._get_by_requests raised ValueError on an unknown trait. It should probably raise TraitNotFound, which should be caught in the allocation_candidates handler. (There's also a raw ValueError related to sharing providers). Of course this doesn't address the nested situation, but that's in progress elsewhere. I have some wip code that demonstrates making it work, others should feel free to leap on this though as I will be out of touch for the next 4 days. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1743860/+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 1744688] [NEW] api-ref: wrong parameter type in server-migrations.inc
Public bug reported: In "Force Migration Complete Action" API(*1), the 'force_complete' parameter in the request is defined as 'string'. This parameter is always 'null'(*2). In the other APIs, it is defined as 'none' (e.g. "Start Server" API (*3)) in that case. So It should be 'none' as well in "Force Migration Complete Action" API. *1: https://developer.openstack.org/api-ref/compute/#force-migration-complete-action-force-complete-action *2: https://github.com/openstack/nova/blob/a40c00957ef4552681c172913bae1135a1614bbc/nova/api/openstack/compute/schemas/server_migrations.py#L21 *3: https://developer.openstack.org/api-ref/compute/#start-server-os-start-action ** Affects: nova Importance: Undecided Assignee: Takashi NATSUME (natsume-takashi) Status: In Progress ** Tags: api-ref ** Changed in: nova Status: New => 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/1744688 Title: api-ref: wrong parameter type in server-migrations.inc Status in OpenStack Compute (nova): In Progress Bug description: In "Force Migration Complete Action" API(*1), the 'force_complete' parameter in the request is defined as 'string'. This parameter is always 'null'(*2). In the other APIs, it is defined as 'none' (e.g. "Start Server" API (*3)) in that case. So It should be 'none' as well in "Force Migration Complete Action" API. *1: https://developer.openstack.org/api-ref/compute/#force-migration-complete-action-force-complete-action *2: https://github.com/openstack/nova/blob/a40c00957ef4552681c172913bae1135a1614bbc/nova/api/openstack/compute/schemas/server_migrations.py#L21 *3: https://developer.openstack.org/api-ref/compute/#start-server-os-start-action To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1744688/+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
