[Yahoo-eng-team] [Bug 1936667] Re: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3
Reviewed: https://review.opendev.org/c/openstack/mistral/+/801078 Committed: https://opendev.org/openstack/mistral/commit/20aa42b75be349e9d8097b598253d74fedf11619 Submitter: "Zuul (22348)" Branch:master commit 20aa42b75be349e9d8097b598253d74fedf11619 Author: Takashi Kajinami Date: Sat Jul 17 00:13:10 2021 +0900 Replace deprecated import of ABCs from collections ABCs in collections should be imported from collections.abc and direct import from collections is deprecated since Python 3.3. Closes-Bug: #1936667 Change-Id: Ide8aa0323d9713c1c2ea0abf3b671ca4dab95ef0 ** Changed in: mistral 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/1936667 Title: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3 Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Shared File Systems Service (Manila): Fix Released Status in Mistral: Fix Released Status in neutron: Fix Released Status in OpenStack Object Storage (swift): Fix Released Status in tacker: Fix Released Status in taskflow: Fix Released Status in tempest: Fix Released Status in zaqar: Fix Released Bug description: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3. For example: >>> import collections >>> collections.Iterable :1: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3, and in 3.10 it will stop working >>> from collections import abc >>> abc.Iterable To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1936667/+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 1525439] Re: Glance V2 API is not backwards compatible and breaks Cinder solidfire driver
** Changed in: puppet-cinder Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1525439 Title: Glance V2 API is not backwards compatible and breaks Cinder solidfire driver Status in Cinder: Won't Fix Status in Glance: Won't Fix Status in puppet-cinder: Won't Fix Bug description: In stable/kilo Glance API V2 change of image-metadata is_public flag to visibility = Public breaks the SolidFire (and maybe other, NetApp?) drivers that depend on is_public flag. Specifically this breaks the ability efficiently handle images by caching images in the SolidFire cluster. Changing the API back to V1 through the cinder.conf file then breaks Ceph which depends on V2 and the image-metadata direct_url and locations to determine if it can clone a image to a volume. So this breaks Ceph's ability to efficiently handle images This version mismatch does not allow for SolidFire and Ceph to both be used efficiently in the same OpenStack cloud. NOTE: openstack/puppet-cinder defaults to glance-api-version = 2 which allows Ceph efficientcy to work and not SolidFire (and others). Mainly Opening this Bug to document this problem since no changes are allowed to Kilo there is probably no way to fix this. Code locations: cinder/cinder/image/glance.py line 250-256 cinder/cinder/volume/drivers/rbd.py line 827 cinder/cinder/volume/drivers/solidfire.py line 647 puppet-cinder/manifests/glance.pp line 59 To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1525439/+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 1963652] [NEW] ToggleSuspend doesn't check an appropriate policy
Public bug reported:
In current Horizon, ToggleSuspend doesn't check an appropriate policy.
The current implementation is:
~~~
def allowed(self, request, instance=None):
if not instance:
return False
self.suspended = instance.status == "SUSPENDED"
if self.suspended:
self.current_present_action = RESUME
policy_rules = (
("compute", "os_compute_api:os-rescue"),)
~~~
However, the action uses server_resume() to resume an instance.
To align the policy to the actual command, it should be
os_compute_api:os-suspend-server:resume
** 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/1963652
Title:
ToggleSuspend doesn't check an appropriate policy
Status in OpenStack Dashboard (Horizon):
New
Bug description:
In current Horizon, ToggleSuspend doesn't check an appropriate policy.
The current implementation is:
~~~
def allowed(self, request, instance=None):
if not instance:
return False
self.suspended = instance.status == "SUSPENDED"
if self.suspended:
self.current_present_action = RESUME
policy_rules = (
("compute", "os_compute_api:os-rescue"),)
~~~
However, the action uses server_resume() to resume an instance.
To align the policy to the actual command, it should be
os_compute_api:os-suspend-server:resume
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1963652/+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
