July 2021 - openstack-discuss - lists.openstack.org

[Kolla] [Kayobe] Is Kayobe release dependent on Kolla-Ansible Release
by Anirudh Gupta 13 Jul '21

13 Jul '21

Hi Team, Whenever a new version of openstack is released in the market, Kayobe also updates its release accordingly. I was going through the installation guide and found Kayobe is dependent on Kolla-Ansible as well. The link https://docs.openstack.org/kayobe/latest/contributor/releases.html suggests that kayobe needs to Synchronise with Kolla Ansible feature flags Synchronise with Kolla Ansible inventory¶ <https://docs.openstack.org/kayobe/latest/contributor/releases.html#synchron…> So in case openstack releases it's newer version, does kayobe wait for kolla-ansible to update to the new release and then starts upgrading its release? Regards Anirudh Gupta

2 3

[Openstack][kolla] updates check
by Ignazio Cassano 13 Jul '21

13 Jul '21

Hello, I am new user for openstack kolla because I installed openstack writing my ansible Playbooks. I wonder if it is a method to check if new images has been released . For example: I installed kolla wallaby 2 weeks ago, and now I want to check if new images could be updated. I want to check if new images solve some bugs. Is it possibile without trying to pull all images.? Thanks Ignazio

3 6

[docs][openstackdocstheme][oslo] - can deprecated-badge-container be added to the pre-pike docs
by Walsh, Helen 13 Jul '21

13 Jul '21

Hi all, Pike seems to be the first project to have a notification of its current support status https://docs.openstack.org/cinder/pike/drivers.html This is in extended maintenance and not the current release. The current supported release is Wallaby.<https://docs.openstack.org/wallaby/> Is there any way to get a similar status for Ocata and Newton e.g. This project is End of Life and not the current release. The current supported release is Wallaby.<https://docs.openstack.org/wallaby/> https://docs.openstack.org/ocata/config-reference/dashboard.html https://docs.openstack.org/newton/config-reference/dashboard.html Kind regards, Helen

2 1

[cinder][stable] proposing Rajat Dhasmana for cinder-stable-maint team
by Brian Rosmaita 13 Jul '21

13 Jul '21

Rajat Dhasmana (whoami-rajat on IRC) has been organizing the cinder project's stable releases for a while now, and has also been active reviewing backports. He has a good understanding of the OpenStack stable maintenance policy and has been a reliable cinder core reviewer since January 2019. I hereby propose that he be included as a member of the cinder-stable-maint team. cheers, brian

7 8

[all][tc] Technical Committee next weekly meeting on July 15th at 1500 UTC
by Ghanshyam Mann 13 Jul '21

13 Jul '21

Hello Everyone, Technical Committee's next weekly meeting is scheduled for July 15th at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, June 14th, at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann

1 0

[tripleo][ci] master is promoting
by Wesley Hayutin 13 Jul '21

13 Jul '21

FYI... Heads up, master is promoting. If you see master jobs failing in a few hours, it may be due to the proxies ttl and sync. You can double check them w/ this WIP patch https://review.rdoproject.org/r/c/rdo-infra/ci-config/+/34441/2/ci-scripts/…

1 0

[cinder] Block Storage API v2 removal
by Brian Rosmaita 13 Jul '21

13 Jul '21

Cinder community members, especially cinder-core: First, thanks to Rajat, who has reviewed this patch carefully, as evidenced by his 32 comments on patch set 4 and his re-review of patch set 6. We need to get https://review.opendev.org/c/openstack/cinder/+/792299/ reviewed and merged. It's holding up some feature work, as people rightly don't want to touch v2 if it's going to be removed, but aren't sure how serious we are that there will be no v2 in the Xena release, so they're not sure what to submit. The v2 API has been deprecated since Pike [0], and at this point it looks like all consuming projects have switched to using v3. But we need to get this change merged and released now at M-2 so we can discover whether there's anything we missed while it's still relatively early in the cycle. So please look at https://review.opendev.org/c/openstack/cinder/+/792299/ . If you are pressed for time, be creative and make a deal with another reviewer or two so that each of you reivews half (or a third, or whatever). But it's important that this be reviewed now! cheers, brian [0] https://docs.openstack.org/releasenotes/cinder/pike.html#deprecation-notes

1 0

[OSSA-2021-001] Neutron: Anti-spoofing bypass for Open vSwitch networks (CVE-2021-20267)
by Jeremy Stanley 13 Jul '21

13 Jul '21

============================================================= OSSA-2021-001: Anti-spoofing bypass for Open vSwitch networks ============================================================= :Date: July 12, 2021 :CVE: CVE-2021-20267 Affects ~~~~~~~ - Neutron: <16.3.3, >=17.0.0 <17.1.3, =18.0.0 Description ~~~~~~~~~~~ David Sinquin with Gandi.net reported a vulnerability in Neutron's default Open vSwitch firewall rules. By sending carefully crafted packets, anyone in control of a server instance connected to the virtual switch can impersonate the IPv6 addresses of other systems on the network, resulting in denial of service or in some cases possibly interception of traffic intended for other destinations. Only deployments using the Open vSwitch driver are affected. Patches ~~~~~~~ - https://review.opendev.org/777873 (Queens) - https://review.opendev.org/791470 (Queens) - https://review.opendev.org/777786 (Rocky) - https://review.opendev.org/791469 (Rocky) - https://review.opendev.org/777872 (Stein) - https://review.opendev.org/791500 (Stein) - https://review.opendev.org/777785 (Train) - https://review.opendev.org/791468 (Train) - https://review.opendev.org/777784 (Ussuri) - https://review.opendev.org/791467 (Ussuri) - https://review.opendev.org/777783 (Victoria) - https://review.opendev.org/791465 (Victoria) - https://review.opendev.org/776599 (Wallaby) - https://review.opendev.org/791464 (Wallaby) - https://review.opendev.org/783743 (Xena) Credits ~~~~~~~ - David Sinquin from Gandi.net (CVE-2021-20267) References ~~~~~~~~~~ - https://launchpad.net/bugs/1902917 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-20267 Notes ~~~~~ - The stable/train, stable/stein, stable/rocky, and stable/queens branches are under extended maintenance and will receive no new point releases, but patches for them are provided as a courtesy. -- Jeremy Stanley

1 0

placement service issue (placement-status upgrade check failure)
by Deepak Mohanty 13 Jul '21

13 Jul '21

I need your help with installation of placement service on Ubuntu 20.04. I have followed the steps in: https://docs.openstack.org/placement/wallaby/install/install-ubuntu.html I am facing the following issue when I try to verify the installation: $ placement-status upgrade check Error: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/oslo_upgradecheck/upgradecheck.py", line 196, in run return conf.command.action_fn() File "/usr/lib/python3/dist-packages/oslo_upgradecheck/upgradecheck.py", line 104, in check result = func_name(self, **kwargs) File "/usr/lib/python3/dist-packages/oslo_upgradecheck/common_checks.py", line 41, in check_policy_json policy_path = conf.find_file(conf.oslo_policy.policy_file) File "/usr/lib/python3/dist-packages/oslo_config/cfg.py", line 2543, in find_file raise NotInitializedError() oslo_config.cfg.NotInitializedError: call expression on parser has not been invoked I did a bit of debugging and found that the policy file is: policy.json. I could not find any policy.json on my machine. I created an empty policy.json at: /etc/placement/policy.json (user and group = placement). That too did not work. I have followed the steps in the install guide twice, deleting the placement database and other resources and recreating them. I continue to see the same issue. Thank you for your time.

5 6

[ patrole ] Understanding RBAC Permission Exceptions
by darumaseye 13 Jul '21

13 Jul '21

Hello, I am a researcher studying security of the Openstack's Policies. I'm very interested in the Patrole project and I would like to ask you some questions. In the documentation it is stated that Patrole compares two different types of results: - an expected one ( derived from oslo.policy ) - an actual one ( derived from an actual request to the API ). Given that, Patrole's tests can return 3 different values: 1) "Success" if actual result and expected result are both True or both False; 2) "RbacOverPermissionException" if actual result is True but expected result is False; 3) "RbacUnderPermissionException" in the other case. I can't understand in which cases the tests can return a value different from "Success". As far as I know, an API call should always be validated internally by oslo.policy's rules, before being allowed. So, in order for an API call to be accepted, oslo.policy's rules must allow that API call. It seems to me that the "expected" result ( derived from oslo.policy ) is always included in the actual result. Hoping that everything I said is correct, I would like to ask you: What issue is allowing such a strange behavior in Openstack APIs ? Why the expected results can be different from the actual ones? Are there publicly available examples showing "Failure" values? In general, are there any publicly available test cases that i can study to understand this? I Would like to thank you very much in advance; Best Regards, Jacopo

3 3