[Yahoo-eng-team] [Bug 1868246] Re: No network after subiquity LPAR installation on s390x with VLAN
** Changed in: initramfs-tools (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1868246 Title: No network after subiquity LPAR installation on s390x with VLAN Status in cloud-init: Invalid Status in subiquity: Fix Released Status in Ubuntu on IBM z Systems: Fix Released Status in initramfs-tools package in Ubuntu: Fix Released Bug description: I tried today an subiquity LPAR installation using the latest ISO (March 19) that includes the latest 20.03 subiquity. The installation itself completed fine, but after the post-install reboot the system didn't had a network active - please note that the LPAR is connected to a VLAN. $ ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group defaul t qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: encc000: mtu 1500 qdisc noop state DOWN group default q len 1000 link/ether a2:8d:91:85:12:e3 brd ff:ff:ff:ff:ff:ff 3: enP1p0s0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 82:0c:2d:0c:b8:70 brd ff:ff:ff:ff:ff:ff 4: enP1p0s0d1: mtu 1500 qdisc noop state DOWN group defaul t qlen 1000 link/ether 82:0c:2d:0c:b8:71 brd ff:ff:ff:ff:ff:ff 5: enP2p0s0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 82:0c:2d:0c:b7:00 brd ff:ff:ff:ff:ff:ff 6: enP2p0s0d1: mtu 1500 qdisc noop state DOWN group defaul t qlen 1000 link/ether 82:0c:2d:0c:b7:01 brd ff:ff:ff:ff:ff:ff Wanting to have a look at the netplan config it turned out that there is no yaml file: $ ls -l /etc/netplan/ total 0 Adding one manually and applying it worked fine. So looks like the installer does not properly generate or copy a 01-netcfg.yaml to /etc/netplan. Please see below the entire steps as well as a compressed file with the entire content of /var/log To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1868246/+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 1854041] Re: Keystone should propagate redirect exceptions from auth plugins
** Changed in: keystone Status: Expired => Confirmed -- 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/1854041 Title: Keystone should propagate redirect exceptions from auth plugins Status in OpenStack Identity (keystone): Confirmed Bug description: When a developer is implementing an Authentication plugin [1] they can only return None and setup the relevant information in the auth context or raise an Unauthorized exception. However, in some cases (like an OpenID Connect plugin) it is needed to perform a redirect to the provider to complete the flow. IIRC this was possible in the past (before moving to Flask) by raising an exception with the proper HTTP code set, but with the current implementation this is impossible. [1]: https://docs.openstack.org/keystone/latest/contributor/auth- plugins.html To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1854041/+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 1854041] Re: Keystone should propagate redirect exceptions from auth plugins
[Expired for OpenStack Identity (keystone) because there has been no activity for 60 days.] ** Changed in: keystone Status: Incomplete => Expired -- 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/1854041 Title: Keystone should propagate redirect exceptions from auth plugins Status in OpenStack Identity (keystone): Expired Bug description: When a developer is implementing an Authentication plugin [1] they can only return None and setup the relevant information in the auth context or raise an Unauthorized exception. However, in some cases (like an OpenID Connect plugin) it is needed to perform a redirect to the provider to complete the flow. IIRC this was possible in the past (before moving to Flask) by raising an exception with the proper HTTP code set, but with the current implementation this is impossible. [1]: https://docs.openstack.org/keystone/latest/contributor/auth- plugins.html To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1854041/+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 1857468] Re: Unable to set apt_preferences(5) parameter during maas-enlisting-node phase
[Expired for cloud-init because there has been no activity for 60 days.] ** Changed in: cloud-init Status: Incomplete => Expired -- 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/1857468 Title: Unable to set apt_preferences(5) parameter during maas-enlisting-node phase Status in cloud-init: Expired Status in MAAS: Expired Bug description: During the maas-enlisting-node phase, cloud init tries to run an 'apt- get update' and it fails because of an error as given below: 2019-12-18T06:08:39+00:00 maas-enlisting-node cloud-init[2655]: Get:4 http:///ubuntu bionic-security InRelease [10.1 kB] 2019-12-18T06:08:39+00:00 maas-enlisting-node cloud-init[2655]: Err:5 http:///ubuntu bionic-backports Release 2019-12-18T06:08:39+00:00 maas-enlisting-node cloud-init[2655]: 404 Not Found [IP: 32.68.226.74 80] 2019-12-18T06:08:40+00:00 maas-enlisting-node cloud-init[2655]: Reading package lists... 2019-12-18T06:08:40+00:00 maas-enlisting-node cloud-init[2655]: E: The repository 'http:///ubuntu bionic-backports Release' does not have a Release file. 2019-12-18T06:08:40+00:00 maas-enlisting-node cloud-init[2655]: E: Repository 'http:///ubuntu bionic InRelease' changed its 'Label' value from 'Ubuntu' to 'ubuntu bionic' 2019-12-18T06:08:40+00:00 maas-enlisting-node cloud-init[2655]: E: Repository 'http:///ubuntu bionic-updates InRelease' changed its 'Label' value from 'Ubuntu' to 'ubuntu bionic-updates' 2019-12-18T06:08:40+00:00 maas-enlisting-node cloud-init[2655]: E: Repository 'http:///ubuntu bionic-updates InRelease' changed its 'Codename' value from 'bionic' to 'bionic-updates' 2019-12-18T06:08:40+00:00 maas-enlisting-node cloud-init[2655]: E: Repository 'http:///ubuntu bionic-security InRelease' changed its 'Label' value from 'Ubuntu' to 'ubuntu bionic-security' 2019-12-18T06:08:40+00:00 maas-enlisting-node cloud-init[2655]: E: Repository 'http:///ubuntu bionic-security InRelease' changed its 'Codename' value from 'bionic' to 'bionic-security' apt has an option to to ignore this error by providing a parameter -"--allow-releaseinfo-change", however I am unable to set this parameter in maas. Is there a place in the code or in the cloud init phase where we can set this option to avoid the above error? If not then would it make sense to add such functionality? To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1857468/+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 1857468] Re: Unable to set apt_preferences(5) parameter during maas-enlisting-node phase
[Expired for MAAS because there has been no activity for 60 days.] ** Changed in: maas Status: Incomplete => Expired -- 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/1857468 Title: Unable to set apt_preferences(5) parameter during maas-enlisting-node phase Status in cloud-init: Expired Status in MAAS: Expired Bug description: During the maas-enlisting-node phase, cloud init tries to run an 'apt- get update' and it fails because of an error as given below: 2019-12-18T06:08:39+00:00 maas-enlisting-node cloud-init[2655]: Get:4 http:///ubuntu bionic-security InRelease [10.1 kB] 2019-12-18T06:08:39+00:00 maas-enlisting-node cloud-init[2655]: Err:5 http:///ubuntu bionic-backports Release 2019-12-18T06:08:39+00:00 maas-enlisting-node cloud-init[2655]: 404 Not Found [IP: 32.68.226.74 80] 2019-12-18T06:08:40+00:00 maas-enlisting-node cloud-init[2655]: Reading package lists... 2019-12-18T06:08:40+00:00 maas-enlisting-node cloud-init[2655]: E: The repository 'http:///ubuntu bionic-backports Release' does not have a Release file. 2019-12-18T06:08:40+00:00 maas-enlisting-node cloud-init[2655]: E: Repository 'http:///ubuntu bionic InRelease' changed its 'Label' value from 'Ubuntu' to 'ubuntu bionic' 2019-12-18T06:08:40+00:00 maas-enlisting-node cloud-init[2655]: E: Repository 'http:///ubuntu bionic-updates InRelease' changed its 'Label' value from 'Ubuntu' to 'ubuntu bionic-updates' 2019-12-18T06:08:40+00:00 maas-enlisting-node cloud-init[2655]: E: Repository 'http:///ubuntu bionic-updates InRelease' changed its 'Codename' value from 'bionic' to 'bionic-updates' 2019-12-18T06:08:40+00:00 maas-enlisting-node cloud-init[2655]: E: Repository 'http:///ubuntu bionic-security InRelease' changed its 'Label' value from 'Ubuntu' to 'ubuntu bionic-security' 2019-12-18T06:08:40+00:00 maas-enlisting-node cloud-init[2655]: E: Repository 'http:///ubuntu bionic-security InRelease' changed its 'Codename' value from 'bionic' to 'bionic-security' apt has an option to to ignore this error by providing a parameter -"--allow-releaseinfo-change", however I am unable to set this parameter in maas. Is there a place in the code or in the cloud init phase where we can set this option to avoid the above error? If not then would it make sense to add such functionality? To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1857468/+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 1872836] [NEW] Swap file creation broken due to incorrect format specifiers
Public bug reported: Swap file creation currently fails with the following error: cc_mounts.py[WARNING]: failed to setup swap: %d format: a number is required, not str This appears to be fallout from changes from this commit: https://github.com/canonical/cloud-init/commit/6603706 https://github.com/canonical/cloud-init/pull/70 It appears several '%d' format specifiers are being incorrectly paired with a string type variable instead of number type variable. ** Affects: cloud-init Importance: Undecided Status: New -- 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/1872836 Title: Swap file creation broken due to incorrect format specifiers Status in cloud-init: New Bug description: Swap file creation currently fails with the following error: cc_mounts.py[WARNING]: failed to setup swap: %d format: a number is required, not str This appears to be fallout from changes from this commit: https://github.com/canonical/cloud-init/commit/6603706 https://github.com/canonical/cloud-init/pull/70 It appears several '%d' format specifiers are being incorrectly paired with a string type variable instead of number type variable. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1872836/+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 1872813] Re: cloud-init fails to detect iSCSI root on focal Oracle instances
** Also affects: open-iscsi (Ubuntu) Importance: Undecided Status: New ** Changed in: cloud-init Status: In Progress => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1872813 Title: cloud-init fails to detect iSCSI root on focal Oracle instances Status in cloud-init: Invalid Status in open-iscsi package in Ubuntu: New Bug description: Currently focal images on Oracle are failing to get data from the Oracle DS with this traceback: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 772, in find_source if s.update_metadata([EventType.BOOT_NEW_INSTANCE]): File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 661, in update_metadata result = self.get_data() File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 279, in get_data return_value = self._get_data() File "/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceOracle.py", line 195, in _get_data with dhcp.EphemeralDHCPv4(net.find_fallback_nic()): File "/usr/lib/python3/dist-packages/cloudinit/net/dhcp.py", line 57, in __enter__ return self.obtain_lease() File "/usr/lib/python3/dist-packages/cloudinit/net/dhcp.py", line 109, in obtain_lease ephipv4.__enter__() File "/usr/lib/python3/dist-packages/cloudinit/net/__init__.py", line 1019, in __enter__ self._bringup_static_routes() File "/usr/lib/python3/dist-packages/cloudinit/net/__init__.py", line 1071, in _bringup_static_routes util.subp( File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2084, in subp raise ProcessExecutionError(stdout=out, stderr=err, cloudinit.util.ProcessExecutionError: Unexpected error while running command. Command: ['ip', '-4', 'route', 'add', '0.0.0.0/0', 'via', '10.0.0.1', 'dev', 'ens3'] Exit code: 2 Reason: - Stdout: Stderr: RTNETLINK answers: File exists In https://github.com/canonical/cloud-init/blob/46cf23c28812d3e3ba0c570defd9a05628af5556/cloudinit/sources/DataSourceOracle.py#L194-L198, we can see that this path is only taken if _is_iscsi_root returns False. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1872813/+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 1872813] [NEW] cloud-init fails to detect iSCSI root on focal Oracle instances
Public bug reported: Currently focal images on Oracle are failing to get data from the Oracle DS with this traceback: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 772, in find_source if s.update_metadata([EventType.BOOT_NEW_INSTANCE]): File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 661, in update_metadata result = self.get_data() File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 279, in get_data return_value = self._get_data() File "/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceOracle.py", line 195, in _get_data with dhcp.EphemeralDHCPv4(net.find_fallback_nic()): File "/usr/lib/python3/dist-packages/cloudinit/net/dhcp.py", line 57, in __enter__ return self.obtain_lease() File "/usr/lib/python3/dist-packages/cloudinit/net/dhcp.py", line 109, in obtain_lease ephipv4.__enter__() File "/usr/lib/python3/dist-packages/cloudinit/net/__init__.py", line 1019, in __enter__ self._bringup_static_routes() File "/usr/lib/python3/dist-packages/cloudinit/net/__init__.py", line 1071, in _bringup_static_routes util.subp( File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2084, in subp raise ProcessExecutionError(stdout=out, stderr=err, cloudinit.util.ProcessExecutionError: Unexpected error while running command. Command: ['ip', '-4', 'route', 'add', '0.0.0.0/0', 'via', '10.0.0.1', 'dev', 'ens3'] Exit code: 2 Reason: - Stdout: Stderr: RTNETLINK answers: File exists In https://github.com/canonical/cloud-init/blob/46cf23c28812d3e3ba0c570defd9a05628af5556/cloudinit/sources/DataSourceOracle.py#L194-L198, we can see that this path is only taken if _is_iscsi_root returns False. ** Affects: cloud-init Importance: Undecided Assignee: Dan Watkins (daniel-thewatkins) Status: In Progress ** Changed in: cloud-init Assignee: (unassigned) => Dan Watkins (daniel-thewatkins) -- 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/1872813 Title: cloud-init fails to detect iSCSI root on focal Oracle instances Status in cloud-init: In Progress Bug description: Currently focal images on Oracle are failing to get data from the Oracle DS with this traceback: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 772, in find_source if s.update_metadata([EventType.BOOT_NEW_INSTANCE]): File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 661, in update_metadata result = self.get_data() File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 279, in get_data return_value = self._get_data() File "/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceOracle.py", line 195, in _get_data with dhcp.EphemeralDHCPv4(net.find_fallback_nic()): File "/usr/lib/python3/dist-packages/cloudinit/net/dhcp.py", line 57, in __enter__ return self.obtain_lease() File "/usr/lib/python3/dist-packages/cloudinit/net/dhcp.py", line 109, in obtain_lease ephipv4.__enter__() File "/usr/lib/python3/dist-packages/cloudinit/net/__init__.py", line 1019, in __enter__ self._bringup_static_routes() File "/usr/lib/python3/dist-packages/cloudinit/net/__init__.py", line 1071, in _bringup_static_routes util.subp( File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2084, in subp raise ProcessExecutionError(stdout=out, stderr=err, cloudinit.util.ProcessExecutionError: Unexpected error while running command. Command: ['ip', '-4', 'route', 'add', '0.0.0.0/0', 'via', '10.0.0.1', 'dev', 'ens3'] Exit code: 2 Reason: - Stdout: Stderr: RTNETLINK answers: File exists In https://github.com/canonical/cloud-init/blob/46cf23c28812d3e3ba0c570defd9a05628af5556/cloudinit/sources/DataSourceOracle.py#L194-L198, we can see that this path is only taken if _is_iscsi_root returns False. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1872813/+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 1872792] [NEW] Feature request: Toggle required fields in angular launch instance workflow
Public bug reported: Nn Project -> instances -> Launch instance wizard, would like the ability to toggle the required fields, e.g. an ability to flag the 'Configuration' widget with a * so that a user would have to fill this form out and enter a metadata customization script ** Affects: horizon Importance: Undecided 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/1872792 Title: Feature request: Toggle required fields in angular launch instance workflow Status in OpenStack Dashboard (Horizon): New Bug description: Nn Project -> instances -> Launch instance wizard, would like the ability to toggle the required fields, e.g. an ability to flag the 'Configuration' widget with a * so that a user would have to fill this form out and enter a metadata customization script To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1872792/+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 1869697] Re: The instance supports USB devices.
Nova handles new feature request through launchpad blueprints. Please follow the process described in[1], e.g. open a blueprint in launchpad and push a specification according the the spec template to the openstack/nova-specs repository. [1]https://docs.openstack.org/nova/latest/contributor/blueprints.html ** 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/1869697 Title: The instance supports USB devices. Status in OpenStack Compute (nova): Invalid Bug description: Description === OpenStack instance can realize the USB transmission function of the server and realize the data transmission.Realize the support of virtual machine to usb device, that is, add, delete and check the function of usb device. Rebuild, resize, delete, migrate/live-migrate, and evacuate operations on the virtual machine will also require additional processing logic. The number of connected usb devices and compatibility with different usb protocols (1.0/2.0/3.0) are also considered. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1869697/+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 1869674] Re: Unit Test test_no_migrations_have_downgrade failing execution
I feel this is part of a bigger development effort (supporting usb for
nova instances?). Please propose a blueprint / spec for your feature
first where we can discuss the general idea of your feature. Then when
you need actual development help please propose the actual coded, where
you got stuck, to gerrit. Then join the #openstack-nova IRC channel on
freenode where the nova developers hang and ask for help.
** 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/1869674
Title:
Unit Test test_no_migrations_have_downgrade failing execution
Status in OpenStack Compute (nova):
Invalid
Bug description:
Description
===
Nova_api newly added a table, but when performing unit tests' tox - epy27
'methods' test_no_migrations_have_downgrade' error.
instance_usb.py
# def downgrade(migrate_engine):
# meta = MetaData(migrate_engine)
# meta.reflect(migrate_engine)
#
# table_names = ['instance_usb']
# for t in table_names:
# table = Table(t, meta)
# table.drop(checkfirst=True)
def upgrade(migrate_engine):
meta = MetaData()
meta.bind = migrate_engine
instance_usb = Table('instance_usb', meta,
Column('instance_uuid',
String(length=36),
nullable=False),
Column('vendor_id',
String(length=255)),
Column('product_id',
String(length=255)),
Column('id',
Integer,
primary_key=True,
autoincrement=True),
Column('created_at',
DateTime),
Column('updated_at',
DateTime),
Column('deleted_at',
DateTime),
Column('deleted',
Boolean),
PrimaryKeyConstraint(
'id',
name="uniq_instance_usb0id"),
mysql_engine='InnoDB',
mysql_charset='utf8')
instance_usb.create(checkfirst=True)
Environment
===
openstack-Rocky
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1869674/+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 1872753] [NEW] Updating EC2 credential blob can lead to a ec2 credential id / credential id mismatch
Public bug reported: Updating ec2 credential blob field via "openstack credential update" allows to update the EC2 credential access ID. Considering that EC2 credential access ID is used to calculate an ID of the "credential" (https://github.com/openstack/keystone/blob/7bb6314e40d6947294260324e84a58de191f8609/keystone/api/users.py#L363, https://github.com/openstack/keystone/blob/7bb6314e40d6947294260324e84a58de191f8609/keystone/common/utils.py#L101), the update action doesn't update the actual credential ID using a new access ID sha256sum. It can lead to orphaned ec2 credentials in the database. ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1872753 Title: Updating EC2 credential blob can lead to a ec2 credential id / credential id mismatch Status in OpenStack Identity (keystone): New Bug description: Updating ec2 credential blob field via "openstack credential update" allows to update the EC2 credential access ID. Considering that EC2 credential access ID is used to calculate an ID of the "credential" (https://github.com/openstack/keystone/blob/7bb6314e40d6947294260324e84a58de191f8609/keystone/api/users.py#L363, https://github.com/openstack/keystone/blob/7bb6314e40d6947294260324e84a58de191f8609/keystone/common/utils.py#L101), the update action doesn't update the actual credential ID using a new access ID sha256sum. It can lead to orphaned ec2 credentials in the database. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1872753/+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 1766485] Re: Support locking user password
Reviewed: https://review.opendev.org/630663 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=7f849239eadfe3d97c088b77eae4d4852c0ab842 Submitter: Zuul Branch:master commit 7f849239eadfe3d97c088b77eae4d4852c0ab842 Author: vmarkov Date: Tue May 15 17:04:47 2018 +0300 Support for Keystone password_lock option This feature was added in Keystone V3 API. Proposed patch adds support to Horizon Co-Authored-By: Ivan Kolodyazhny Closes-bug: #1766485 Change-Id: Ic20a58c76826d703b43fa6a2d77ae5f77dcda1f4 ** Changed in: horizon Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1766485 Title: Support locking user password Status in OpenStack Dashboard (Horizon): Fix Released Bug description: Change https://review.openstack.org/#/c/559438/ (related bug 1755874) introduced concept of locking user password from changing via self service in Keystone V3 API. Horizon should implement support for changing this user option too. Sibling story for python-openstackclient https://storyboard.openstack.org/#!/story/2001906 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1766485/+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 1872747] [NEW] Unexpected API Error
Public bug reported: HI Team, I just finished my minimum openstack Train installation on virtual box by taking step by step help from https://docs.openstack.org/install-guide/ When I reached at creating a VM with cirros image, got below error: Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. (HTTP 500) (Request-ID: req-e99b1405-5a96-4842-bd7a-2a6c8f5c6b46) Storage type: LVM Network type: Neutron with OpenVSwitch ** Affects: nova Importance: Undecided Status: New ** Tags: api ** Attachment added: "logs.zip" https://bugs.launchpad.net/bugs/1872747/+attachment/5353872/+files/logs.zip -- 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/1872747 Title: Unexpected API Error Status in OpenStack Compute (nova): New Bug description: HI Team, I just finished my minimum openstack Train installation on virtual box by taking step by step help from https://docs.openstack.org/install-guide/ When I reached at creating a VM with cirros image, got below error: Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. (HTTP 500) (Request-ID: req-e99b1405-5a96-4842-bd7a-2a6c8f5c6b46) Storage type: LVM Network type: Neutron with OpenVSwitch To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1872747/+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 1871806] Re: The information about auth type (Internal, External auth) is not available when rendering openrc files in horizon
Reviewed: https://review.opendev.org/718379 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=086c6607ef7834c308dcc58e74349293b7685ac1 Submitter: Zuul Branch:master commit 086c6607ef7834c308dcc58e74349293b7685ac1 Author: Ivan Kolodyazhny Date: Wed Apr 8 13:23:29 2020 +0300 Add auth_type to template context for openrc file rendering We need to path auth_type value to the template because different templates could be rendered for credentials and websso auth_type. Closes-Bug: #1871806 Change-Id: If218813e0b4a8cc51c4e590081c5f3c50b35b8a7 ** Changed in: horizon Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1871806 Title: The information about auth type (Internal, External auth) is not available when rendering openrc files in horizon Status in OpenStack Dashboard (Horizon): Fix Released Bug description: The authorization method might be checked during horizon login, however this info is not available when rendering openrc templates [1]. Without ths information we can't customize templates [1] to get them working both for websso and login/password authenticated users [1] https://opendev.org/openstack/horizon/src/branch/master/openstack_dashboard/dashboards/project/api_access/views.py#L72 [2] https://docs.openstack.org/horizon/latest/configuration/settings.html#openstack-clouds-yaml-custom-template To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1871806/+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 1808814] Re: admin docs: interoperable image import revision for stein
Reviewed: https://review.opendev.org/717873 Committed: https://git.openstack.org/cgit/openstack/glance/commit/?id=30f821c62416aa79d98c0c79b81bb981eb49155f Submitter: Zuul Branch:master commit 30f821c62416aa79d98c0c79b81bb981eb49155f Author: khashf Date: Mon Apr 6 15:20:13 2020 -0700 Revise admin interoperable image import docs This patch revises the documentation of the interoperable image import feature available to admin operators to concisely describe Stein and later releases. Changes include: - Remove enable_image_import option because it is no longer available since the release of Stein - Simplify the language of the v1 API being deprecated Change-Id: Ic155afd6de5b37a25743457e9a7ddd5a45dac4e8 Closes-Bug: #1808814 ** 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/1808814 Title: admin docs: interoperable image import revision for stein Status in Glance: Fix Released Bug description: https://docs.openstack.org/glance/latest/admin/interoperable-image- import.html The image import docs need a revision. I noticed these, there may be more: * remove mention of enable_image_import option and its effect on the v2.6 API * probably leave in the mention of the v1 copy-from (so it's clear that the OSSN doesn't apply to web-download), but change language of the v1 API being deprecated to simply, "Additionally, the Image API v1 was removed in Glance 17.0.0 (Rocky)." To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1808814/+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 1870336] Re: Update 'common image properties' doc
Reviewed: https://review.opendev.org/718287 Committed: https://git.openstack.org/cgit/openstack/glance/commit/?id=984e844c6ab3b365f5104e36429bda0ebd5e9a9d Submitter: Zuul Branch:master commit 984e844c6ab3b365f5104e36429bda0ebd5e9a9d Author: khashf Date: Tue Apr 7 17:44:39 2020 -0700 Update 'common image properties' doc Update doc/source/user/common-image-properties.rst (live link [1]) to be in sync with etc/schema-image.json This patch does 2 actions: 1. Add the missing properties that are in etc/schema-image.json to the doc 2. Rearrange the order of appearance of properties in the doc to be the same as they appear in etc/schema-image.json [1] docs.openstack.org/glance/latest/user/common-image-properties.html Change-Id: I840f3cbeda28da8b02dd141fde582c9110aeb21e Closes-bug: #1870336 ** 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/1870336 Title: Update 'common image properties' doc Status in Glance: Fix Released Bug description: This doc: https://opendev.org/openstack/glance/src/branch/master/doc/source/user /common-image-properties.rst has gotten out of sync with the actual list of properties: https://opendev.org/openstack/glance/src/branch/master/etc/schema- image.json To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1870336/+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 1872730] [NEW] Delete ARQs for an instance when the instance is deleted only delete bound arqs
Public bug reported: During development of the cyborg integration with nova the patch that Delete ARQs for an instance when the instance is deleted Icb95890d8f16cad1f7dc18487a48def2f7c9aec2 failed to do so in some cases as noted in https://review.opendev.org/#/c/673735/46/nova/conductor/manager.py@1632 if the arq are successfully created in the conductor and then the binding fails those arqs would be leaked as they never entered the bound state. As a result if the instance was deleted the ARQs that were created for the instance but not bound would not be deleted when the instance bound ARQs are clean up. This bug tracks addressing that edge case. ** Affects: nova Importance: High Status: Triaged ** Affects: nova/ussuri Importance: High Status: Triaged ** Tags: conductor cyborg ussuri-backport-potential ** Also affects: nova/ussuri Importance: High Status: Triaged -- 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/1872730 Title: Delete ARQs for an instance when the instance is deleted only delete bound arqs Status in OpenStack Compute (nova): Triaged Status in OpenStack Compute (nova) ussuri series: Triaged Bug description: During development of the cyborg integration with nova the patch that Delete ARQs for an instance when the instance is deleted Icb95890d8f16cad1f7dc18487a48def2f7c9aec2 failed to do so in some cases as noted in https://review.opendev.org/#/c/673735/46/nova/conductor/manager.py@1632 if the arq are successfully created in the conductor and then the binding fails those arqs would be leaked as they never entered the bound state. As a result if the instance was deleted the ARQs that were created for the instance but not bound would not be deleted when the instance bound ARQs are clean up. This bug tracks addressing that edge case. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1872730/+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 1872732] [NEW] no user limit of ec2 credentials
Public bug reported: Hi, similar to application credentials, I would like to have the possibility to limit the maximum number of ec2 credentials a user can have to avoid a bloat in the keystone database or open keystone to a DoS attack. Thanks, Maurice ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1872732 Title: no user limit of ec2 credentials Status in OpenStack Identity (keystone): New Bug description: Hi, similar to application credentials, I would like to have the possibility to limit the maximum number of ec2 credentials a user can have to avoid a bloat in the keystone database or open keystone to a DoS attack. Thanks, Maurice To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1872732/+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 1869184] Re: Poor LUKSv1 performance when using native QEMU decryption and RBD volumes
Reviewed: https://review.opendev.org/708029 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=7c7a25aa1eda9b1815f12cce25dda0a840d562f1 Submitter: Zuul Branch:master commit 7c7a25aa1eda9b1815f12cce25dda0a840d562f1 Author: Lee Yarwood Date: Sat Feb 15 12:24:11 2020 + workarounds: Add option to locally attach RBD volumes on compute hosts Building on the ``[workarounds]/disable_native_luksv1`` configurable introduced in Ia500eb614cf575ab846f64f4b69c9068274c8c1f this change introduces another workaround configurable that when enabled will connect RBD volumes to the compute host as block devices using os-brick. When used togther both options allow operators to workaround recently discovered performance issues in the libgcrypt library used by QEMU when natively decrypting LUKSv1 encrypted disks. For now the extend_volume method raises a NotImplemented error in-line with the underlying method in os-brick. Future work will be required to both support this in os-brick and wire up the required calls in the volume driver. This workaround is temporary and will be removed during the W release once all impacted distributions have been able to update their versions of the libgcrypt library. Finally os-brick 3.0.1 is now required as it provides the Id507109df80391699074773f4787f74507c4b882 fix when attempting to diconnect locally attached RBD volumes. Closes-Bug: #1869184 Change-Id: Ied3732042738a6194b635c55e0304d71a6fb66e3 ** 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/1869184 Title: Poor LUKSv1 performance when using native QEMU decryption and RBD volumes Status in OpenStack Compute (nova): Fix Released Bug description: Description === This bug specifically covers the RBD use case when dealing with bug #1869182. In addition to allowing operators to switch to the os-brick encryptors when decrypting LUKSv1 volumes RBD users will also need to use the RBD connector also provided by os-brick. This will connect the RBD volume to the host and provide it as a host block device, allowing the os-brick encryptors to be layered on top of it as with other volume types. Steps to reproduce == * Attach a LUKSv1 RBD encrypted volume to an instance * Test I/O performance within the instance to the volume. Expected result === Performance is close to baremetal performance using dm-crypt. Actual result = Performance is severely degraded if the libgcrypt issue [1] is not resolved on the host. Environment === 1. Exact version of OpenStack you are running. See the following list for all releases: http://docs.openstack.org/releases/ Master. 2. Which hypervisor did you use? (For example: Libvirt + KVM, Libvirt + XEN, Hyper-V, PowerKVM, ...) What's the version of that? libvirt + QEMU/KVM 2. Which storage type did you use? (For example: Ceph, LVM, GPFS, ...) What's the version of that? RBD - LUKSv1 encryption used. 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/1869184/+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 1872713] [NEW] Windows library "wmi" is imported but not installed
Public bug reported: Windows library "wmi" is imported in agent.windows.utils but is not present in requirements.txt. ** Affects: neutron Importance: Undecided Assignee: Rodolfo Alonso (rodolfo-alonso-hernandez) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1872713 Title: Windows library "wmi" is imported but not installed Status in neutron: In Progress Bug description: Windows library "wmi" is imported in agent.windows.utils but is not present in requirements.txt. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1872713/+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 1869182] Re: Poor LUKSv1 performance when using native QEMU decryption
Reviewed: https://review.opendev.org/708030 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=dbb58e964ad1821e96f3e6758b3add747339d052 Submitter: Zuul Branch:master commit dbb58e964ad1821e96f3e6758b3add747339d052 Author: Lee Yarwood Date: Sat Feb 15 11:33:48 2020 + workarounds: Add option to disable native LUKSv1 decryption by QEMU Recently discovered performance issues with the libgcrypt library [1] mean that operators may wish to avoid the now default native decryption of LUKSv1 volumes as of I5a0de814f2868f1a4980a69b72b45ee829cedb94. This change introduces a ``[workarounds]/disable_native_luksv1`` option to disable this native decryption by QEMU, allowing Nova to fallback to the dm-crypt based os-brick encryptors. This workaround is temporary and will be removed during the W release once all impacted distributions have been able to update their versions of the libgcrypt library. The _is_luks_v1 method previously used to confirm if a LUKSv1 encryption provider is being used has been renamed _allow_native_luksv1 and repurposed to determine if native LUKSv1 decryption by QEMU is allowed. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1762765 Closes-Bug: #1869182 Change-Id: Ia500eb614cf575ab846f64f4b69c9068274c8c1f ** Changed in: nova Status: In Progress => Fix Released ** Bug watch added: Red Hat Bugzilla #1762765 https://bugzilla.redhat.com/show_bug.cgi?id=1762765 -- 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/1869182 Title: Poor LUKSv1 performance when using native QEMU decryption Status in OpenStack Compute (nova): Fix Released Bug description: Description === LUKSv1 encrypted volumes have been natively decrypted by QEMU since I5a0de814f2868f1a4980a69b72b45ee829cedb94. This behaviour is not optional at present. Recently discovered performance issues within the libgcrypt library [1] used by QEMU to decrypt LUKSv1 disks mean that some users may wish to disable this feature within the libvirt driver. Disabling native decryption by QEMU should result in the original dm- crypt approach being taken using encryptors provided from os-brick. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1762765 Steps to reproduce == * Attach a LUKSv1 encrypted volume to an instance * Test I/O performance within the instance to the volume. Expected result === Performance is close to baremetal performance using dm-crypt. Actual result = Performance is severely degraded if the libgcrypt issue [1] is not resolved on the host. Environment === 1. Exact version of OpenStack you are running. See the following list for all releases: http://docs.openstack.org/releases/ Master. 2. Which hypervisor did you use? (For example: Libvirt + KVM, Libvirt + XEN, Hyper-V, PowerKVM, ...) What's the version of that? libvirt + QEMU/KVM 2. Which storage type did you use? (For example: Ceph, LVM, GPFS, ...) What's the version of that? N/A - LUKSv1 encryption used. 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/1869182/+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 1872693] [NEW] Timeout exception in scenario tests with advanced image
Public bug reported:
It seems that sometimes on slow nodes, tests which requires advanced image,
like e.g.
neutron_tempest_plugin.scenario.test_multicast.MulticastTestIPv4.test_multicast_between_vms_on_same_network
or
neutron_tempest_plugin.scenario.test_trunk.TrunkTest.test_subport_connectivity
may fail due to global timeout reach.
So we should give some more time for such tests, just to make sure that cleanup
after test can perform fine and test will not fail in that last phase.
Examples of failure:
Body: None
Response - Headers: {'date': 'Tue, 24 Mar 2020 19:34:39 GMT', 'server':
'Apache/2.4.29 (Ubuntu)', 'content-type': 'application/json',
'openstack-api-version': 'compute 2.1', 'x-openstack-nova-api-version': '2.1',
'vary': 'OpenStack-API-Version,X-OpenStack-Nova-API-Version',
'x-openstack-request-id': 'req-f6803ed4-cd44-4aaf-852b-9642166f66fd',
'x-compute-request-id': 'req-f6803ed4-cd44-4aaf-852b-9642166f66fd',
'connection': 'close', 'status': '204', 'content-location':
'https://158.69.70.109/compute/v2.1/servers/6d8abb96-e8de-4833-86f0-2307493e42f9'}
Body: b''
2020-03-24 19:34:41,164 19073 INFO [tempest.lib.common.rest_client] Request
(MulticastTestIPv4:_run_cleanups): 200 GET
https://158.69.70.109/compute/v2.1/servers/6d8abb96-e8de-4833-86f0-2307493e42f9
0.664s
2020-03-24 19:34:41,164 19073 DEBUG[tempest.lib.common.rest_client] Request
- Headers: {'Content-Type': 'application/json', 'Accept': 'application/json',
'X-Auth-Token': ''}
Body: None
Response - Headers: {'date': 'Tue, 24 Mar 2020 19:34:40 GMT', 'server':
'Apache/2.4.29 (Ubuntu)', 'content-length': '1636', 'content-type':
'application/json', 'openstack-api-version': 'compute 2.1',
'x-openstack-nova-api-version': '2.1', 'vary':
'OpenStack-API-Version,X-OpenStack-Nova-API-Version', 'x-openstack-request-id':
'req-9e05c04f-d73f-410e-a593-9732cd0d368b', 'x-compute-request-id':
'req-9e05c04f-d73f-410e-a593-9732cd0d368b', 'connection': 'close', 'status':
'200', 'content-location':
'https://158.69.70.109/compute/v2.1/servers/6d8abb96-e8de-4833-86f0-2307493e42f9'}
Body: b'{"server": {"id": "6d8abb96-e8de-4833-86f0-2307493e42f9",
"name": "tempest-multicast-server-968193459", "status": "ACTIVE", "tenant_id":
"1247c419c0bd41bb948eacb87e8bf8e3", "user_id":
"3b79839ed47d4c95b8f363497a767ff2", "metadata": {}, "hostId":
"9ee32c342fa222fa161f31fa44b4ad381d7a977bf32d6c6db0070294", "image": {"id":
"3a21d3c5-44f2-4543-97cd-aee290e1a6a8", "links": [{"rel": "bookmark", "href":
"https://158.69.70.109/compute/images/3a21d3c5-44f2-4543-97cd-aee290e1a6a8"}]},
"flavor": {"id": "d1", "links": [{"rel": "bookmark", "href":
"https://158.69.70.109/compute/flavors/d1"}]}, "created":
"2020-03-24T19:24:33Z", "updated": "2020-03-24T19:34:40Z", "addresses":
{"tempest-test-network--2075552321": [{"version": 4, "addr": "10.1.0.12",
"OS-EXT-IPS:type": "fixed", "OS-EXT-IPS-MAC:mac_addr": "fa:16:3e:e2:f4:69"},
{"version": 4, "addr": "172.24.5.147", "OS-EXT-IPS:type": "floating",
"OS-EXT-IPS-MAC:mac_addr": "fa:16:3e:e2:f4:69"}]}, "accessIPv4": "",
"accessIPv6": "", "links": [{"rel": "self", "href":
"https://158.69.70.109/compute/v2.1/servers/6d8abb96-e8de-4833-86f0-2307493e42f9"},
{"rel": "bookmark", "href":
"https://158.69.70.109/compute/servers/6d8abb96-e8de-4833-86f0-2307493e42f9"}],
"OS-DCF:diskConfig": "MANUAL", "progress": 0, "OS-EXT-AZ:availability_zone":
"nova", "config_drive": "", "key_name": "tempest-keypair-test-913711661",
"OS-SRV-USG:launched_at": "2020-03-24T19:24:40.00",
"OS-SRV-USG:terminated_at": null, "security_groups": [{"name":
"secgroup_mtu"}], "OS-EXT-STS:task_state": "deleting", "OS-EXT-STS:vm_state":
"active", "OS-EXT-STS:power_state": 1, "os-extended-volumes:volumes_attached":
[]}}'
2020-03-24 19:34:41,762 19073 INFO [tempest.lib.common.rest_client] Request
(MulticastTestIPv4:_run_cleanups): 204 DELETE
https://158.69.70.109/compute/v2.1/servers/fde7c8ae-7fea-4aa9-9f3b-e2d8ac864d4f
0.322s
2020-03-24 19:34:41,762 19073 DEBUG[tempest.lib.common.rest_client] Request
- Headers: {'Content-Type': 'application/json', 'Accept': 'application/json',
'X-Auth-Token': ''}
Body: None
Response - Headers: {'date': 'Tue, 24 Mar 2020 19:34:41 GMT', 'server':
'Apache/2.4.29 (Ubuntu)', 'content-type': 'application/json',
'openstack-api-version': 'compute 2.1', 'x-openstack-nova-api-version': '2.1',
'vary': 'OpenStack-API-Version,X-OpenStack-Nova-API-Version',
'x-openstack-request-id': 'req-06f636f8-ebd2-4974-979b-cf7a81e1f29f',
'x-compute-request-id': 'req-06f636f8-ebd2-4974-979b-cf7a81e1f29f',
'connection': 'close', 'status': '204', 'content-location':
'https://158.69.70.109/compute/v2.1/servers/fde7c8ae-7fea-4aa9-9f3b-e2d8ac864d4f'}
Body: b''
2020-03-24 19:34:42,583 19073 INFO [tempest.lib.common.rest_client] Request
(MulticastTestIPv4:_run_cleanups): 200 GET
[Yahoo-eng-team] [Bug 1872663] [NEW] Failing to terminate Windows processes
Public bug reported: The neutron Windows exec call helper doesn't properly handle the situation in which the process that it's trying to kill was already terminated, in which case using WMI to fetch the process can raise an exception. Trace: http://paste.openstack.org/raw/790116/ ** Affects: neutron Importance: Undecided Assignee: Lucian Petrut (petrutlucian94) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1872663 Title: Failing to terminate Windows processes Status in neutron: In Progress Bug description: The neutron Windows exec call helper doesn't properly handle the situation in which the process that it's trying to kill was already terminated, in which case using WMI to fetch the process can raise an exception. Trace: http://paste.openstack.org/raw/790116/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1872663/+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
