March 2021 - openstack-discuss - lists.openstack.org

[election][manila] PTL Candidacy for Xena
by Goutham Pacha Ravi 08 Mar '21

08 Mar '21

Greetings Zorillas & other Stackers, This is my candidacy to be the PTL for the OpenStack Manila team through the Xena cycle. I've had the great privilege of leading this unique team for the past three releases. During this time, we've had an enviable momentum and some fantastic achievements while building impactful software. I have enjoyed being a catalyst and an advocate for this motivated team, and I wish to do this a bit longer. In Wallaby, we harnessed our diverse strengths to mentor five new contributors through our student project internships, two of who were sponsored through Outreachy funding. They have all expressed their desire to become long term contributors. I am very proud of the manila team for their sincerity and enthusiasm in aiding new Stackers. I seek to further this outreach through the Xena release cycle. Testing and project quality will remain a top personal priority. The team was able to get new interop guidelines published last cycle, and we will focus on adding more test coverage under these guidelines, alongside addressing test gaps and innovating on more test scenarios. We have continued to implement the pro-active backport policy to get bug fixes back to stable branches and request timely releases of these stable branches. In the Xena cycle, I intend to codify this policy based on our learning and spread the release responsibility and know-how around the team. We split project maintenance into sub-teams during the Wallaby cycle, and recruited sub-team core reviewers. An increase in focus and velocity ensued across project code repositories. I intend to propose more additions to these sub-teams in the Xena cycle and encourage more contributors to take on project maintenance responsibilities. So, if you will have me, I wish to serve you through Xena and get things done. Thank you for your support, Goutham Pacha Ravi <gouthampravi(a)gmail.com> IRC: gouthamr

1 0

[horizon][i18n][infra] Renaming Chinese locales in Django from zh-cn/zh-tw to zh-hans/zh-hant
by Akihiro Motoki 08 Mar '21

08 Mar '21

Hi, The horizon team is planning to switch Chinese language codes in Django codes from zh-cn/zh-tw to zh-hans/zh-hant. Django, a framework used in horizon, recommends to use them since more than 5 years ago [1][2]. This change touches Chinese locales in the dashbaord codes of horizon and its plugins only. It does not change Chinese locales in other translations like documentations and non-Django python codes. This is to minimize the impact to other translations and the translation platform. ### What are/are not changed in repositories * horizon and horizon plugins * locales in the dashboard codes are renamed from zh-cn/zh-tw to zh-hans/zh-hant * locales in doc/ and releasenotes/ are not changed * other repositories * no locale change happens NOTE: * This leads to a situation that we have two different locales in horizon and plugin repositories (zh-hans/hant in the code folders and zh-cn/tw in doc and releasenotes folders), but it affects only developers and does not affect horizon consumers (operators/users) and translators. * In addition, documentations are translated in OpenStack-wide (not only in horizon and plugins). By keeping locales in docs, locales in documentation translations will be consistent. ### Impact on Zanata In Zanata (the translation platform), zh-cn/zh-tw continue to be used, so no change is visible to translators. The infra job proposes zh-cn/zh-tw GUI translatoins as zh-hans/zh-hant translations to horizon and plugin repositories. NOTE: The alternative is to create the corresponding language teams (zh-hans/zh-hant) in Zanata, but it affects Chinese translators a lot. They need to join two language teams to translate horizon (zh-hans/zh-hant) and docs (zh-cn/zh-tw). It makes translator workflow complicated. The proposed way has no impact on translators and they can continue the current translation process and translate both horizon and docs under a single language code. ### Changes in the infra scripts Converting Chinese locales of dashboard translations from zh-cn/zh-tw to zh-hans/zh-hant is handled by the periodic translation job. propose_translation_update job is responsible for this. [propose_translation_update.sh] * Move zh-cn/zh-tw translations related to Django codes in horizon and its plugins from zanata to zh-hans/hant directory. * This should happen in the master branch (+ future stable branhces such as stable/wallaby). ### Additional Remarks I18n SIG respects all language team coordinators & members, and is looking forward to seeing discussions and/or active contributions from the language teams. Currently all language codes follow the ISO 639-1 standard (language codes with relevant country codes), but the change introduces new language code forms like zh-hans/zh-hant. This follows IETF BCP 47 which recommends a combination of language codes and ISO 15924 script code (four letters). We now have two different language codes in OpenStack world. This is just to minimize the impact on the existing translations. It is not ideal. We are open for further discussion on language codes and translation support. ### References [1] https://code.djangoproject.com/ticket/18419 [2] https://www.djbook.ru/rel1.7/releases/1.7.html#language-codes-zh-cn-zh-tw-a… Thanks, Akihiro Motoki (irc: amotoki)

1 1

[all][tc][goals] Migrate RBAC Policy Format from JSON to YAML: Week R-6 Update
by Ghanshyam Mann 08 Mar '21

08 Mar '21

Hello Everyone, Please find the week's R-6 updates on 'Migrate RBAC Policy Format from JSON to YAML' wallaby community-wide goals. Gerrit Topic: https://review.opendev.org/q/topic:%22policy-json-to-yaml%22+(status:open%2… Progress Summary: =============== Tracking: https://etherpad.opendev.org/p/migrate-policy-format-from-json-to-yaml * Projects completed: 21 * Projects required to merge the patches: 8 * Projects required to push the patches: 2 (horizon and Openstackansible) * Projects do not need any work: 16 Patches ready to merge: ================== * Octavia: https://review.opendev.org/c/openstack/octavia/+/764578 * Magnum: https://review.opendev.org/c/openstack/magnum/+/767242 * Murano: https://review.opendev.org/c/openstack/murano/+/768520 * Panko: https://review.opendev.org/c/openstack/panko/+/768498 * Solum: https://review.opendev.org/c/openstack/solum/+/768381 * Zaqar: https://review.opendev.org/c/openstack/zaqar/+/768488 Updates: ======= * Fixed the lower constraints failure for all the current open patches. * Few project patches are failing on config object initialization, I am debugging those and will fix them soon. * It is important to merge all the service side patches so that JSON format deprecation happens in the Wallaby release. -gmann

2 2

[neutron-dynamic-routing] Support for multiple BGP speaker
by Manu B 07 Mar '21

07 Mar '21

Hi, As understood from the code, currently the neutron dynamic routing supports only one BGP speaker per host *# os-ken can only support One *speaker if* self.cache.get_hosted_bgp_speakers_count() == 1: raise bgp_driver_exc.BgpSpeakerMaxScheduled(count=1) * Could you please let me know if this is due to some limitation of the os-ken driver? Or are there any other reasons for this limitation? Thanks, Manu

1 0

[Neutron][Nova][Ironic][Cinder][Keystone][Glance][Swift] OVN as the default network backend for DevStack
by Lucas Alvares Gomes 06 Mar '21

06 Mar '21

Hi all, As part of the Victoria PTG [0] the Neutron community agreed upon switching the default backend in Devstack to OVN. A lot of work has been done since, from porting the OVN devstack module to the DevStack tree, refactoring the DevStack module to install OVN from distro packages, implementing features to close the parity gap with ML2/OVS, fixing issues with tests and distros, etc... We are now very close to being able to make the switch and we've thought about sending this email to the broader community to raise awareness about this change as well as bring more attention to the patches that are current on review. Note that moving DevStack to ML2/OVN does not mean that ML2/OVS is discontinued and/or not supported anymore. The ML2/OVS driver is still going to be developed and maintained by the upstream Neutron community. Below is a e per project explanation with relevant links and issues of where we stand with this work right now: * Keystone: Everything should be good for Keystone, the gate is happy with the changes. Here is the test patch: https://review.opendev.org/c/openstack/keystone/+/777963 * Glance: Everything should be good for Glace, the gate is happy with the changes. Here is the test patch: https://review.opendev.org/c/openstack/glance/+/748390 * Swift: Everything should be good for Swift, the gate is happy with the changes. Here is the test patch: https://review.opendev.org/c/openstack/swift/+/748403 * Ironic: Since chainloading iPXE by the OVN built-in DHCP server is work in progress, we've changed most of the Ironic jobs to explicitly enable ML2/OVS and everything is merged, so we should be good for Ironic too. Here is the test patch: https://review.opendev.org/c/openstack/ironic/+/748405 * Cinder: Cinder is almost complete. There's one test failure in the "tempest-slow-py3" job run on the "test_port_security_macspoofing_port" test. This failure is due to a bug in core OVN [1]. This bug has already been fixed upstream [2] and the fix has been backported down to the branch-20.03 [3] of the OVN project. However, since we install OVN from packages we are currently waiting for this fix to be included in the packages for Ubuntu Focal (it's based on OVN 20.03). I already contacted the package maintainer which has been very supportive of this work and will work on the package update, but he maintain a handful of backports in that package which is not yet included in OVN 20.03 upstream and he's now working with the core OVN community [4] to include it first in the branch and then create a new package for it. Hopefully this will happen soon. But for now we have a few options moving on with this issue: 1- Wait for the new package version 2- Mark the test as unstable until we get the new package version 3- Compile OVN from source instead of installing it from packages (OVN_BUILD_FROM_SOURCE=True in local.conf) What do you think about it ? Here is the test patch for Cinder: https://review.opendev.org/c/openstack/cinder/+/748227 * Nova: There are a few patches waiting for review for Nova, which are: 1- Adapting the live migration scripts to work with ML2/OVN: Basically the scripts were trying to stop the Neutron agent (q-agt) process which is not part of an ML2/OVN deployment. The patch changes the code to check if that system unit exists before trying to stop it. Patch: https://review.opendev.org/c/openstack/nova/+/776419 2- Explicitly set grenade job to ML2/OVS: This is a temporary change which can be removed one release cycle after we switch DevStack to ML2/OVN. Grenade will test updating from the release version to the master branch but, since the default of the released version is not ML2/OVN, upgrading from ML2/OVS to ML2/OVN as part of the grenade job is not supported. Patch: https://review.opendev.org/c/openstack/nova/+/776934 3- Explicitly set nova-next job to ML2/OVS: This job uses the QoS minimum bandwidth feature which is not yet supported by ML2/OVN [5][6] therefore we are temporarily enabling ML2/OVS for this job until that feature lands in core OVN. Patch: https://review.opendev.org/c/openstack/nova/+/776944 I also spoke briefly with Sean Mooney (irc: sean-k-mooney) about these changes and he suggested keeping all the Nova jobs on ML2/OVS for now because he feels like a change in the default network driver a few weeks prior to the upstream code freeze can be concerning. We do not know yet precisely when we are changing the default due to the current patches we need to get merged but, if this is a shared feeling among the Nova community I can work on enabling ML2/OVS on all jobs in Nova until we get a new release in OpenStack. Here's the test patch for Nova: https://review.opendev.org/c/openstack/nova/+/776945 * DevStack: And this is the final patch that will make this all happen: https://review.opendev.org/c/openstack/devstack/+/735097 It changes the default in DevStack from ML2/OVS to ML2/OVN. It's been a long and bumpy road to get to this point and I would like to say thanks to everyone involved so far and everyone that read the whole email, please let me know your thoughts. [0] https://etherpad.opendev.org/p/neutron-victoria-ptg [1] https://bugs.launchpad.net/tempest/+bug/1728886 [2] https://patchwork.ozlabs.org/project/openvswitch/patch/20200319122641.47377… [3] https://github.com/ovn-org/ovn/commit/0c26bc03064f2c21d208f0f860b48d8ab3938… [4] https://mail.openvswitch.org/pipermail/ovs-discuss/2021-February/050961.html [5] https://github.com/openstack/nova/blob/ded25f33c734ebff963f06984707a99fe76a… [6] https://docs.openstack.org/neutron/latest/ovn/gaps.html Cheers, Lucas

8 16

[manila] Wallaby Collab Review - CephFS drivers updates (Mar 8th)
by Victoria Martínez de la Cruz 06 Mar '21

06 Mar '21

Hi everyone, Next Monday (March 8th) we will hold a Manila collaborative review session in which we'll go through the code and review the latest changes introduced in the CephFS drivers [0][1] This meeting is scheduled to last one hour, starting at 5.00pm UTC. It might extend a bit, but the most important should be covered within the hour. Meeting notes and relevant links are available in [2] Your feedback will be truly appreciated. Cheers, V [0] https://review.opendev.org/q/topic:%22bp%252Fupdate-cephfs-drivers%22+(stat… [1] https://review.opendev.org/q/topic:%22bp%252Fcreate-share-from-snapshot-cep… [2] https://etherpad.opendev.org/p/update-cephfs-drivers-collab-review

1 1

Re: [openstack-community] Keystone deprecated policies problem
by Amy 06 Mar '21

06 Mar '21

Adding the OpenStack discuss list. Thanks, Amy (spotz) > On Mar 5, 2021, at 3:19 PM, meberhardt(a)unl.edu.ar wrote: > > Hi, > > my installation complains about deprecated policies and throw errors when I try to run specific commands in cli as admin user(list projects or list users, for example). > > "You are not authorized to perform the requested action: identity:list_users." > > I tried to fix this by upgrading the keystone policies using oslopolicy-policy-generator and oslopolicy-policy-upgrade. Just found two places where I have those keystone policy files in my sistem: /etc/openstack_dashboard/keystone_policy.json and cd /lib/python3.6/site-packages/openstack_auth/tests/conf/keystone_policy.json > > I regenerated & upgraded it but Keystone still complains about the old polices. Where are it placed? How I shoud fix it? > > OS: CentOS 8 > Openstack version: Ussuri > Manual installation > > Thanks, > > Matias > > /* --------------------------------------------------------------- */ > /* Matías A. Eberhardt */ > /* */ > /* Centro de Telemática */ > /* Secretaría General */ > /* UNIVERSIDAD NACIONAL DEL LITORAL */ > /* Pje. Martínez 2652 - S3002AAB Santa Fe - Argentina */ > /* tel +54(342)455-4245 - FAX +54(342)457-1240 */ > /* --------------------------------------------------------------- */ > > > _______________________________________________ > Community mailing list > Community(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/community

1 0

[cinder] final patches for wallaby os-brick release need reviews
by Brian Rosmaita 05 Mar '21

05 Mar '21

Hello members of the cinder community: Please direct your attention to the following patches at your earliest convenience (i.e., right now): https://review.opendev.org/c/openstack/os-brick/+/777086 "NVMeOF connector driver connection information compatibility fix" - this fixes the regression in the nvmeof connector - patch has passed CI: Zuul, Mellanox SPDK (to detect the regression), and Kioxia (which uses the mdraid feature) - looks pretty much ready to go https://review.opendev.org/c/openstack/os-brick/+/778810 "Add release note for nvmeof connector" - the title says it all https://review.opendev.org/c/openstack/os-brick/+/778807 "Update requirements for wallaby release" - raises the minimum versions in the various requirements files to reflect what we're actually testing with right now - nothing major because of the adjustments made back in January to deal with the upgraded pip dependency resolver Happy reviewing! brian

2 2

[TripleO] Wallaby cycle highlights
by Marios Andreou 05 Mar '21

05 Mar '21

Hello all o/ Before you have a heart attack ;) Wallaby is still ~1 month away (and more like ~1.5 months+ for TripleO as we always trail the release) :) As mentioned in the last tripleo irc meeting [1] the deadline for wallaby cycle highlights is next Friday 12th March [2]. I had a go at and posted the proposal to https://review.opendev.org/c/openstack/releases/+/778971 . Please comment on the review or here if you want to update the wording and especially if I have forgotten to include something please accept my apologies if you let me know I can fix it :) thanks, marios [1] http://eavesdrop.openstack.org/meetings/tripleo/2021/tripleo.2021-03-02-14.… [2] http://lists.openstack.org/pipermail/openstack-discuss/2021-February/020714…

1 0

[glance] Doc about swift as backend
by Cristina Mayo Sarmiento 05 Mar '21

05 Mar '21

Hi everyone, Are there any specific documentation about how to configure Swift as backend of Glance service? I've found this: https://docs.openstack.org/glance/latest/configuration/configuring.html but I'm not sure what are the options I need. Firstly, I follow the installation guides of glance: https://docs.openstack.org/glance/latest/install/install-ubuntu.html and I have now file as store but I'rather change it. Thanks!

3 2