[Yahoo-eng-team] [Bug 1882072] Re: Quality of Service (QoS) in neutron
Reviewed: https://review.opendev.org/736289 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=8c3441e856407292fa0f0ae2afdbf6eb3a076cb6 Submitter: Zuul Branch:master commit 8c3441e856407292fa0f0ae2afdbf6eb3a076cb6 Author: Rodolfo Alonso Hernandez Date: Wed Jun 17 16:07:33 2020 + Change service_plugins documentation in QoS to steevedore entries Change the service_plugin references in QoS admin document to use only the steevedore names, to be consistent throughout the document. Change-Id: Iebb28e0a68ce580d03851b083add70c79204da1c Closes-Bug: #1882072 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1882072 Title: Quality of Service (QoS) in neutron Status in neutron: Fix Released Bug description: This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [x] This doc is inaccurate in this way: In Configuration section of the page point 1 and point 3 are confusing. As I read it, the settings should be applied to the same configuration option in the same file. So which one is the valid example? --- Release: 13.0.8.dev51 on 2020-05-26 20:43 SHA: daa4737cf3e10650800d8364e524175e40932d7b Source: https://git.openstack.org/cgit/openstack/neutron/tree/doc/source/admin/config-qos.rst URL: https://docs.openstack.org/neutron/rocky/admin/config-qos.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1882072/+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 1879716] Re: Policy is not enforced for network mtu config
Reviewed: https://review.opendev.org/729615 Committed: https://git.openstack.org/cgit/openstack/neutron-lib/commit/?id=cfeee711840ff7a15e4fe0a527225d685ae690fc Submitter: Zuul Branch:master commit cfeee711840ff7a15e4fe0a527225d685ae690fc Author: rajesh.kudaka Date: Wed May 20 09:18:45 2020 -0500 Fix policy enforcement for network mtu Change-Id: I3526d62d8ea9f6d0eadab88472347b35117c7dd4 Closes-Bug: #1879716 ** Changed in: neutron Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1879716 Title: Policy is not enforced for network mtu config Status in neutron: Fix Released Bug description: Policy for network mtu is not enforced. As a result, user with any role is able to alter with the mtu configuration. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1879716/+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 1883907] Re: EC2 data source does not properly return the instance ID when cached data exists
I'm marking this invalid; if you find more information that would indicate that cloud-init is not booting like a new instance after capturing on Ec2, please reopen this bug and include updated information. ** Changed in: cloud-init Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1883907 Title: EC2 data source does not properly return the instance ID when cached data exists Status in cloud-init: Invalid Bug description: When creating an AMI from a running instance without cleaning the cloud-init cache an instance from the new AMI is no properly identified as a new instance and none of the PER_INSTANCE tasks will be executed. The problem is that the Ec2 data source will return the cached instance-id rather than the new instance ID. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1883907/+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 1884127] [NEW] Can't create swapfile on btrfs
Public bug reported: With a userdata definition like such: #cloud-config swap: filename: /swap.img size: 500 maxsize: 500 the swap file cannot be created on btrfs. See https://wiki.archlinux.org/index.php/Swap#Swap_file ** 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/1884127 Title: Can't create swapfile on btrfs Status in cloud-init: New Bug description: With a userdata definition like such: #cloud-config swap: filename: /swap.img size: 500 maxsize: 500 the swap file cannot be created on btrfs. See https://wiki.archlinux.org/index.php/Swap#Swap_file To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884127/+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 1884105] [NEW] [DHCP] IPv6 "addr6_list" change the "host" file format
Public bug reported: This bug could be divided in two: 1) IPv6 tags feature [1] introduces, if supported by the dnsmasq version, a new element in the "host" file, the tag: fa:16:3e:6b:c1:97,tag:dhcpv6,host-fe32-dead-beef--5.localdomain,[fe32:dead:beef::5] That will shift all other parameters and should be considered when parsing this file. 2) The IPv6 registers (lines in "host" file) can have more than one IP address. Each one should be registered as a new item in the set returned in [2] [1]https://review.opendev.org/#/q/I833840e7daed2efa7efaece27cfd1ba28e0feb90 [2]https://github.com/openstack/neutron/blob/7d8f400791707e5db7839dcdf3ef4dbbd1dd39bc/neutron/agent/linux/dhcp.py#L876-L894 NOTE: the fix for this bug should be cherry-picked up to Train. ** Affects: neutron Importance: Undecided Assignee: Rodolfo Alonso (rodolfo-alonso-hernandez) Status: New ** Changed in: neutron Assignee: (unassigned) => Rodolfo Alonso (rodolfo-alonso-hernandez) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1884105 Title: [DHCP] IPv6 "addr6_list" change the "host" file format Status in neutron: New Bug description: This bug could be divided in two: 1) IPv6 tags feature [1] introduces, if supported by the dnsmasq version, a new element in the "host" file, the tag: fa:16:3e:6b:c1:97,tag:dhcpv6,host-fe32-dead-beef--5.localdomain,[fe32:dead:beef::5] That will shift all other parameters and should be considered when parsing this file. 2) The IPv6 registers (lines in "host" file) can have more than one IP address. Each one should be registered as a new item in the set returned in [2] [1]https://review.opendev.org/#/q/I833840e7daed2efa7efaece27cfd1ba28e0feb90 [2]https://github.com/openstack/neutron/blob/7d8f400791707e5db7839dcdf3ef4dbbd1dd39bc/neutron/agent/linux/dhcp.py#L876-L894 NOTE: the fix for this bug should be cherry-picked up to Train. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1884105/+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 1882919] Re: e1000e interface reported as unsupported
Reviewed: https://review.opendev.org/734777 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=644cb5cb8bf44184d9b3f046cc67746b13550dd6 Submitter: Zuul Branch:master commit 644cb5cb8bf44184d9b3f046cc67746b13550dd6 Author: Stephen Finucane Date: Wed Jun 10 10:56:38 2020 +0100 libvirt: Mark e1000e VIF as supported This is supported by the QEMU/KVM backends in libvirt. There's no reason not to support it in nova. This appears to have been an oversight. Change-Id: I12a5d28d75bc32a76a4f3765cb4db4cbc46c0c75 Signed-off-by: Stephen Finucane Closes-Bug: #1882919 ** 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/1882919 Title: e1000e interface reported as unsupported Status in OpenStack Compute (nova): Fix Released Bug description: Per this downstream bug [1], attempting to boot a Windows Server 2012 or 2016 image will fail because libosinfo is attempting to configure an e1000e VIF which nova does not explicitly support. There doesn't appear to be any reason not to support this, since libvirt, and specifically QEMU/KVM, support it. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1839808 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1882919/+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 1884071] [NEW] gzipped and base64 encoded user-data leads to failure
Public bug reported:
Issue is here as well: https://github.com/terraform-providers/terraform-
provider-aws/issues/8244
In /var/log/cloud-init.log this is the only WARNING message (there are
no ERROR messages):
2020-06-18 12:16:59,413 - __init__.py[WARNING]: Unhandled non-multipart
(text/x-not-multipart) userdata: 'b'H4sI/8RV3W4bNxO9'...'
I can even pull the file from the created VM and it can be extracted and
shows to be proper formatting and everything:
curl -L http://169.254.169.254/latest/user-data/ | base64 --decode |
gunzip
Content-Type: multipart/mixed; boundary="MIMEBOUNDARY"
MIME-Version: 1.0
--MIMEBOUNDARY
Content-Transfer-Encoding: 7bit
Content-Type: text/cloud-config
Mime-Version: 1.0
#cloud-config
# set locale
locale: en_GB.UTF-8
# ensure time sync between all nodes
ntp:
enabled: true
ntp_client: chrony
# hides ssh keys in console
ssh_fp_console_blacklist: [ssh-dss, ssh-dsa, ssh-ed25519]
ssh_key_console_blacklist: [ssh-dss, ssh-dsa, ssh-ed25519]
# upgrade all packages and install necessary ones
package_upgrade: true
package_reboot_if_required: true
packages:
- apt-transport-https
- ca-certificates
- curl
- gnupg-agent
- software-properties-common
- build-essential
- libssl-dev
- make
# set random root password and disable password login for ssh
chpasswd:
expire: false
list: |
root:RANDOM
ssh_pwauth: no
# create sre user with sudo privs and set autrhorized key
users:
- name: sre
groups: sudo
lock_passwd: true
ssh_authorized_keys:
- censored
sudo: ['ALL=(ALL) NOPASSWD:ALL']
shell: /bin/bash
--MIMEBOUNDARY
Content-Transfer-Encoding: 7bit
Content-Type: text/cloud-config
Mime-Version: 1.0
#cloud-config
# Configure Floating IP (Ubuntu 20.04 LTS)
# Not required when using https://github.com/costela/hcloud-ip-floater
#write_files:
# - content: |
# network:
# version: 2
# ethernets:
# eth0:
# addresses:
# - ${floating_ip}/32
#path: /etc/netplan/60-floating-ip.yaml
# Install Keepalived
runcmd:
- cd /root/
- wget http://www.keepalived.org/software/keepalived-2.1.2.tar.gz
- tar xvf keepalived-2.1.2.tar.gz
- cd keepalived-2.1.2
- ./configure
- make
- sudo make install
final_message: "The system is finally up, after $UPTIME seconds"
When I use the exact same userdata as above but extracted and passed as
plain text it works without issue.
** Affects: cloud-init
Importance: Undecided
Status: New
** Attachment added: "apport.cloud-init.wby0fvkm.apport"
https://bugs.launchpad.net/bugs/1884071/+attachment/5384975/+files/apport.cloud-init.wby0fvkm.apport
--
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/1884071
Title:
gzipped and base64 encoded user-data leads to failure
Status in cloud-init:
New
Bug description:
Issue is here as well: https://github.com/terraform-providers
/terraform-provider-aws/issues/8244
In /var/log/cloud-init.log this is the only WARNING message (there are
no ERROR messages):
2020-06-18 12:16:59,413 - __init__.py[WARNING]: Unhandled non-
multipart (text/x-not-multipart) userdata:
'b'H4sI/8RV3W4bNxO9'...'
I can even pull the file from the created VM and it can be extracted
and shows to be proper formatting and everything:
curl -L http://169.254.169.254/latest/user-data/ | base64 --decode |
gunzip
Content-Type: multipart/mixed; boundary="MIMEBOUNDARY"
MIME-Version: 1.0
--MIMEBOUNDARY
Content-Transfer-Encoding: 7bit
Content-Type: text/cloud-config
Mime-Version: 1.0
#cloud-config
# set locale
locale: en_GB.UTF-8
# ensure time sync between all nodes
ntp:
enabled: true
ntp_client: chrony
# hides ssh keys in console
ssh_fp_console_blacklist: [ssh-dss, ssh-dsa, ssh-ed25519]
ssh_key_console_blacklist: [ssh-dss, ssh-dsa, ssh-ed25519]
# upgrade all packages and install necessary ones
package_upgrade: true
package_reboot_if_required: true
packages:
- apt-transport-https
- ca-certificates
- curl
- gnupg-agent
- software-properties-common
- build-essential
- libssl-dev
- make
# set random root password and disable password login for ssh
chpasswd:
expire: false
list: |
root:RANDOM
ssh_pwauth: no
# create sre user with sudo privs and set autrhorized key
users:
- name: sre
groups: sudo
lock_passwd: true
ssh_authorized_keys:
- censored
sudo: ['ALL=(ALL) NOPASSWD:ALL']
shell: /bin/bash
--MIMEBOUNDARY
Content-Transfer-Encoding: 7bit
Content-Type: text/cloud-config
Mime-Version: 1.0
#cloud-config
# Configure Floating IP (Ubuntu 20.04 LTS)
# Not required when using https://github.com/costela/hcloud-ip-floater
#write_files:
# - content: |
# network:
# version: 2
# ethernets:
# eth0:
# addresses:
# - ${floating_ip}/32
#path:
[Yahoo-eng-team] [Bug 1884068] [NEW] Instance stuck in build state when some/one compute node is unreachable in an Availability Zone
Public bug reported: Description === Instance stuck in build state when some/one compute node is unreachable in an Availability Zone and this situation arises when the scheduler picks up the compute node which is unreachable and the instance is stuck in the build state not even moving to the error state. NOTE: unreachable means that either the compute node is shutoff or might be some network connectivity issue. Steps to reproduce == * Create instance X by providing an Availability Zone. * where this Availability zone should consist of a group of compute nodes in which I have a single reachable(Power ON) compute node and 3 unreachable(Power OFF) compute nodes. * OR even you can try powering off all the compute nodes in that zone. $ openstack server create --image --flavor --network --availability-zone Expected result === The instance X should fail to build with proper error message if all the compute nodes are unreachable or it should deploy the instance on the reachable compute nodes. Actual result = The instance is in the "BUILD" state forever. Environment === 1. Stein release used. $ rpm -qa | grep nova-compute openstack-nova-compute-19.1.0-1 2. KVM hypervisor version: 1.5.3 2. LVM used as storage backend on the Compute host. lvm2-2.02.185 3. Which networking type did you use? Neutron with OpenVSwitch ** 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/1884068 Title: Instance stuck in build state when some/one compute node is unreachable in an Availability Zone Status in OpenStack Compute (nova): New Bug description: Description === Instance stuck in build state when some/one compute node is unreachable in an Availability Zone and this situation arises when the scheduler picks up the compute node which is unreachable and the instance is stuck in the build state not even moving to the error state. NOTE: unreachable means that either the compute node is shutoff or might be some network connectivity issue. Steps to reproduce == * Create instance X by providing an Availability Zone. * where this Availability zone should consist of a group of compute nodes in which I have a single reachable(Power ON) compute node and 3 unreachable(Power OFF) compute nodes. * OR even you can try powering off all the compute nodes in that zone. $ openstack server create --image --flavor --network --availability-zone Expected result === The instance X should fail to build with proper error message if all the compute nodes are unreachable or it should deploy the instance on the reachable compute nodes. Actual result = The instance is in the "BUILD" state forever. Environment === 1. Stein release used. $ rpm -qa | grep nova-compute openstack-nova-compute-19.1.0-1 2. KVM hypervisor version: 1.5.3 2. LVM used as storage backend on the Compute host. lvm2-2.02.185 3. Which networking type did you use? Neutron with OpenVSwitch To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1884068/+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 1884067] [NEW] [API] Filtering by fields not allowed to see is possible for regular users
Public bug reported:
It seems that regular user, even if can't see binding:host_id field for
the port can filter based on this field:
neutron CLI is deprecated and will be removed in the future. Use openstack CLI
instead.
+--+
| id |
+--+
| 79949e8d-98dc-4fba-8897-c85a2bf89da7 |
| 7b91b484-4a9d-4160-84f7-bf1aed35d42a |
| 92023b4e-11bd-42be-a60d-609dc237873d |
| d987e708-1439-411d-848c-15a918ec3198 |
+--+
[stack@undercloud-0 ~]$ neutron port-list --binding:host_id
compute-1.redhat.local
neutron CLI is deprecated and will be removed in the future. Use openstack CLI
instead.
+--+--+---++
| id | name | mac_address | fixed_ips
|
+--+--+---++
| 7b91b484-4a9d-4160-84f7-bf1aed35d42a | | fa:16:3e:38:fe:b6 |
{"subnet_id": "da9e51d0-a9a5-43ee-8ae1-d79bbfd9ee71", "ip_address":
"192.168.100.151"} |
+--+--+---++
[stack@undercloud-0 ~]$ neutron port-list --binding:host_id
compute-0.redhat.local
neutron CLI is deprecated and will be removed in the future. Use openstack CLI
instead.
** Affects: neutron
Importance: High
Status: Confirmed
** Tags: api
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1884067
Title:
[API] Filtering by fields not allowed to see is possible for regular
users
Status in neutron:
Confirmed
Bug description:
It seems that regular user, even if can't see binding:host_id field
for the port can filter based on this field:
neutron CLI is deprecated and will be removed in the future. Use openstack
CLI instead.
+--+
| id |
+--+
| 79949e8d-98dc-4fba-8897-c85a2bf89da7 |
| 7b91b484-4a9d-4160-84f7-bf1aed35d42a |
| 92023b4e-11bd-42be-a60d-609dc237873d |
| d987e708-1439-411d-848c-15a918ec3198 |
+--+
[stack@undercloud-0 ~]$ neutron port-list --binding:host_id
compute-1.redhat.local
neutron CLI is deprecated and will be removed in the future. Use openstack
CLI instead.
+--+--+---++
| id | name | mac_address | fixed_ips
|
+--+--+---++
| 7b91b484-4a9d-4160-84f7-bf1aed35d42a | | fa:16:3e:38:fe:b6 |
{"subnet_id": "da9e51d0-a9a5-43ee-8ae1-d79bbfd9ee71", "ip_address":
"192.168.100.151"} |
+--+--+---++
[stack@undercloud-0 ~]$ neutron port-list --binding:host_id
compute-0.redhat.local
neutron CLI is deprecated and will be removed in the future. Use openstack
CLI instead.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1884067/+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 1884062] [NEW] Documentation is absent for explicit_domain_id parameter when creating a domain
Public bug reported: Documentation https://docs.openstack.org/api-ref/identity/v3/ lacks mention of the explicit_domain_id parameter when creating a domain. Support for this parameter was added in the Train release: https://review.opendev.org/#/c/605235/ ** 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/1884062 Title: Documentation is absent for explicit_domain_id parameter when creating a domain Status in OpenStack Identity (keystone): New Bug description: Documentation https://docs.openstack.org/api-ref/identity/v3/ lacks mention of the explicit_domain_id parameter when creating a domain. Support for this parameter was added in the Train release: https://review.opendev.org/#/c/605235/ To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1884062/+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] Re: Updating EC2 credential blob can lead to a ec2 credential id / credential id mismatch
Reviewed: https://review.opendev.org/728387 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=252c23b1b80bfbc0e9b54ac31a5b97c117cf3d77 Submitter: Zuul Branch:master commit 252c23b1b80bfbc0e9b54ac31a5b97c117cf3d77 Author: Vishakha Agarwal Date: Fri May 15 14:13:40 2020 +0530 Disable EC2 credentials access_id update Without this patch user can alter EC2 credential access_id and user cannot use it anymore as an ec2 auth token since EC2 credential access ID is used to calculate an ID of the "credential" [1] and it doesn't update the EC2 credential ID with new access ID. This leads to unwanted EC2 credentials stored in database. As per the discussion of keystone team [2] we decided to block patching of "access_id" attribute. [1] https://github.com/openstack/keystone/blob/7bb6314e40d6947294260324e84a58de191f8609/keystone/api/users.py#L363 [2]http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-alt/%23openstack-meeting-alt.2020-05-12.log.html#t2020-05-12T17:45:20 Closes-Bug: #1872753 Change-Id: I1f6ce3927c2881d9a2d7dcda3ccd29e0a82e45a9 ** Changed in: keystone Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1872753 Title: Updating EC2 credential blob can lead to a ec2 credential id / credential id mismatch Status in OpenStack Identity (keystone): Fix Released Bug description: Updating ec2 credential blob field via "openstack credential set --data '***'" 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. This can lead to invalid ec2 credentials. 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
