April 2022 - openstack-discuss - lists.openstack.org

[neutron][nova] port binding fails for existing networks
by Eugen Block 19 Apr '22

19 Apr '22

Hi *, I have a kind of strange case which I'm trying to solve for hours, I could use some fresh ideas. It's a HA cloud (Victoria) deployed by Salt and the 2 control nodes are managed by pacemaker, the third controller will join soon. There are around 16 compute nodes at the moment. This two-node-control plane works well, except if there are unplanned outages. Since the last outage of one control node we struggle to revive neutron (I believe neutron is the issue here). I'll try to focus on the main issue here, let me know if more details are required. After the failed node was back online all openstack agents show as "up" (openstack compute service list, openstack network agent list). Running VMs don't seem to be impacted (as far as I can tell). But we can't create new instances in existing networks, and since we use Octavia we also can't (re)build any LBs at the moment. When I create a new test network the instance spawns successfully and is active within a few seconds. For existing networks we get the famous "port binding failed" from nova-compute.log. But I see the port being created, it just can't be attached to the instance. One more strange thing: I don't see any entries in the nova-scheduler.log or nova-conductor.log for the successfully built instance, except for the recently mentioned etcd3gw message from nova-conductor, but this didn't impact the instance creation yet. We have investigated this for hours, we have rebooted both control nodes multiple times in order to kill any remaining processes. The galera DB seems fine, rabbitmq also behaves normally (I think), we tried multiple times to put one node in standby to only have one node to look at which also didn't help. So basically we restarted everything multiple times on the control nodes and also nova-compute and openvswitch-agent on all compute nodes, the issue is still not resolved. Does anyone have further ideas to resolve this? I'd be happy to provide more details, just let me know what you need. Happy Easter! Eugen

3 5

OPS Meetup Meeting tomorrow
by Amy Marrich 18 Apr '22

18 Apr '22

Just a reminder that the OPS Meetup team will meet tomorrow morning at 13:00 UTC in the #openstack-operators room on OFTC. See you there!

1 0

[TripleO] Final TripleO repos release for stable/victoria - any requests?
by Marios Andreou 18 Apr '22

18 Apr '22

Hello The stable/victoria branch for all tripleo repos will transition to Extended Maintenance in 2 weeks [1]. To prevent delays I have prepared a final victoria release at [2]. That [2] will be updated after its depends-on merges (puppet metadata bump) to pickup the latest victoria commits at that point. If there are any patches you want included then please speak up and I'll wait for and include those commits before updating releases/+/836921 [2]. This is the last ever release to be made from stable/victoria. Once it goes to Extended Maintenance we can no longer release. I'll hold it for a few days.. Unless I hear otherwise I will update [2] on Monday and try to get it merged next week. thanks, marios [1] http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028013.ht… [2] https://review.opendev.org/c/openstack/releases/+/836921

2 3

[Neutron] Bug deputy report April 11 - April 18
by Jakub Libosvar 18 Apr '22

18 Apr '22

Hi all, I was the bug deputy for the previous week. There is one critical bug from Slawek with proposed revert. Here is the report: Critical -------- - Test tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_update_instance_port_admin_state is failing constantly since 7.04.2022 https://bugs.launchpad.net/neutron/+bug/1968896 Revert proposed: https://review.opendev.org/c/openstack/neutron/+/837685 Medium ------ - neutron-dhcp-agent memory leak on network sync failure https://bugs.launchpad.net/neutron/+bug/1969270 Needs an assignee - [L3-DVR]l3-agent arp table will not update https://bugs.launchpad.net/neutron/+bug/1968860 Needs an assignee - network DHCP agent ports status is DOWN in multi network creation simultaneously https://bugs.launchpad.net/neutron/+bug/1968859 Needs an assignee - Importing neutron.common.config module registers config options https://bugs.launchpad.net/neutron/+bug/1968606 Proposed fix: https://review.opendev.org/c/openstack/neutron/+/837392 Incomplete ---------- - unable to attach an interface to an external network https://bugs.launchpad.net/neutron/+bug/1968893 Looks like configuration issue, more logs are needed - too many l3 dvr agents got notifications after a server got deleted https://bugs.launchpad.net/neutron/+bug/1968837 I'm not sure I understand what the issue is Invalid ------- - ovn-controller don't update new flows https://bugs.launchpad.net/neutron/+bug/1969354 It looks like misconfigured environment, provided some tips

1 0

[ironic] Skipping today's upstream meeting
by Iury Gregory 18 Apr '22

18 Apr '22

Hi Ironicers, We will skip the weekly meeting this week, since we have Easter Holidays and other holidays in some countries =) ) -- *Att[]'sIury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Part of the ironic-core and puppet-manager-core team in OpenStack* *Senior Software Engineer at Red Hat Brazil* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory(a)gmail.com <iurygregory(a)gmail.com>*

1 0

[neutron] Mysql FK Errors
by Ammad Syed 18 Apr '22

18 Apr '22

Hi, I am using neutron 19.1 with OVN backend. I am receiving below mentioned errors in my percona xtradb cluster logs for neutron database. 2022-04-04T15:39:17.342175+05:00 187579 [ERROR] [MY-011825] [InnoDB] WSREP: referenced FK check fail: Lock wait index `PRIMARY` table `neutron_ml2`.`portsecuritybindings` 2022-04-05T14:18:19.801183+05:00 275503 [ERROR] [MY-011825] [InnoDB] WSREP: referenced FK check fail: Lock wait index `PRIMARY` table `neutron_ml2`.`ml2_port_binding_levels` Can you guys advice about these errors. Is there anything to worry about? or should I just ignore them ? Ammad

1 0

[Trove][Xena] Error building Trove image
by wodel youchi 17 Apr '22

17 Apr '22

Hi, When trying to build Trove I am getting this error message : 2022-04-10 08:55:25.497 | *+ install_deb_packages install iscsi-initiator-utils* 2022-04-10 08:55:25.497 | + DEBIAN_FRONTEND=noninteractive 2022-04-10 08:55:25.497 | + http_proxy= 2022-04-10 08:55:25.497 | + https_proxy= 2022-04-10 08:55:25.497 | + no_proxy= 2022-04-10 08:55:25.497 | + apt-get --option Dpkg::Options::=--force-confold --option Dpkg::Options::=--force-confdef --assume-yes install iscsi-initiator-utils 2022-04-10 08:55:25.541 | Reading package lists... 2022-04-10 08:55:25.788 | Building dependency tree... 2022-04-10 08:55:25.788 | Reading state information... 2022-04-10 08:55:25.825 | *E: Unable to locate package iscsi-initiator-utils* 2022-04-10 08:55:25.838 | ++ diskimage_builder/lib/img-functions:run_in_target:59 : check_break after-error run_in_target bash 2022-04-10 08:55:25.843 | ++ diskimage_builder/lib/common-functions:check_break:143 : echo '' 2022-04-10 08:55:25.844 | ++ diskimage_builder/lib/common-functions:check_break:143 : egrep -e '(,|^)after-error(,|$)' -q 2022-04-10 08:55:25.851 | + diskimage_builder/lib/img-functions:run_in_target:1 : trap_cleanup 2022-04-10 08:55:25.855 | + diskimage_builder/lib/img-functions:trap_cleanup:36 I am not an Ubuntu person but I think the package's name is open-iscsi. This is the command I used to build the image : ./trovestack build-image ubuntu bionic true ubuntu /home/stack/trove-xena-guest-ubuntu-bionic-dev.qcow2 My OS is a Centos 8 Stream. you can find the whole log of the operation attached. Thanks in advance. Regards.

2 1

Re: [Trove][Xena] Error building Trove image
by Hirotaka Wakabayashi 16 Apr '22

16 Apr '22

Hi Wodel, I think you need to fix DIB element files to build a guest image as CentOS Stream. Officially supported operating system in Trove is currently Ubuntu[1]. I am preparing Installation instructions Fedora/CentOS Stream users[2] but that is not completed. You may not really need to build a guest image as CentOS Stream if you are a mysql or postgresql user, because Trove supports Docker Since Victoria. This means database service can runs as docker container inside the Trove instance. You can define the datastore image by using the "docker_image" config option[4]. --- [1]: https://docs.openstack.org/trove/latest/admin/building_guest_images.html [2]: https://storyboard.openstack.org/#!/story/2009918 [3]: https://opendev.org/openstack/trove/src/branch/master/integration/scripts/f… [4]: https://docs.openstack.org/trove/latest/admin/run_trove_in_production.html#… Regards,Hirotaka On Wednesday, April 13, 2022, 10:04:53 PM GMT+9, <openstack-discuss-request(a)lists.openstack.org> wrote: Send openstack-discuss mailing list submissions to openstack-discuss(a)lists.openstack.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss or, via email, send a message with subject or body 'help' to openstack-discuss-request(a)lists.openstack.org You can reach the person managing the list at openstack-discuss-owner(a)lists.openstack.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openstack-discuss digest..." Today's Topics: 1. [Trove][Xena] Error building Trove image (wodel youchi) ---------------------------------------------------------------------- Message: 1 Date: Wed, 13 Apr 2022 00:16:59 +0100 From: wodel youchi <wodel.youchi(a)gmail.com> To: OpenStack Discuss <openstack-discuss(a)lists.openstack.org> Subject: [Trove][Xena] Error building Trove image Message-ID: <CAJV_UBCZVOKmjvwdDJW0w17g39L8MVHuZNOQJ7yH2DZNFnqZbA(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi, When trying to build Trove I am getting this error message : 2022-04-10 08:55:25.497 | *+ install_deb_packages install iscsi-initiator-utils* 2022-04-10 08:55:25.497 | + DEBIAN_FRONTEND=noninteractive 2022-04-10 08:55:25.497 | + http_proxy= 2022-04-10 08:55:25.497 | + https_proxy= 2022-04-10 08:55:25.497 | + no_proxy= 2022-04-10 08:55:25.497 | + apt-get --option Dpkg::Options::=--force-confold --option Dpkg::Options::=--force-confdef --assume-yes install iscsi-initiator-utils 2022-04-10 08:55:25.541 | Reading package lists... 2022-04-10 08:55:25.788 | Building dependency tree... 2022-04-10 08:55:25.788 | Reading state information... 2022-04-10 08:55:25.825 | *E: Unable to locate package iscsi-initiator-utils* 2022-04-10 08:55:25.838 | ++ diskimage_builder/lib/img-functions:run_in_target:59 : check_break after-error run_in_target bash 2022-04-10 08:55:25.843 | ++ diskimage_builder/lib/common-functions:check_break:143 : echo '' 2022-04-10 08:55:25.844 | ++ diskimage_builder/lib/common-functions:check_break:143 : egrep -e '(,|^)after-error(,|$)' -q 2022-04-10 08:55:25.851 | + diskimage_builder/lib/img-functions:run_in_target:1 : trap_cleanup 2022-04-10 08:55:25.855 | + diskimage_builder/lib/img-functions:trap_cleanup:36 I am not an Ubuntu person but I think the package's name is open-iscsi. This is the command I used to build the image : ./trovestack build-image ubuntu bionic true ubuntu /home/stack/trove-xena-guest-ubuntu-bionic-dev.qcow2 My OS is a Centos 8 Stream. you can find the whole log of the operation attached. Thanks in advance. Regards.

1 0

[Kolla-ansible][Glance] Glance HA deployment with shared file backend
by Rodrigo Lima 16 Apr '22

16 Apr '22

Hi Guys, hope all is well! According with the kolla-ansible documentation, " By default when using file backend only one glance-api container can be running." So my questions is quite simple: Can I deploy multiple glance_api containers in HA mode (like if I used ceph or swift backend) if I use a shared filesystem (eg. NFS) in all glance nodes? If I can do so, what I need to change in deployment files/scripts/yaml?

2 1

[all][tc] What's happening in Technical Committee: summary April 15th, 21: Reading: 10 min
by Ghanshyam Mann 16 Apr '22

16 Apr '22

Hello Everyone, Here is this week's summary of the Technical Committee activities. 1. TC Meetings: ============ * We cancelled this week's meeting. * Next TC weekly meeting will be on April 21st Thursday 15:00 UTC, feel free to add the topic on the agenda[1] by April 20th. 2. What we completed this week: ========================= * Added goal readiness checklist[2] * Retired openstack-health[3] * Retired tempest-lib[4] * Add Ganesha based Ceph NFS Charm[5] * PTG summary sent to ML[6] 3. Activities In progress: ================== TC Tracker for Zed cycle ------------------------------ * With the Zed cycle kickoff[7], I have started the Zed cycle TC tracker by listing all the items we discussed in PTG but we will add more during the cycle also if something important comes up[8] Open Reviews ----------------- * Seven open reviews for ongoing activities[9]. Drop the lower constraints maintenance ------------------------------------------------ This has been going on for many months, if I remember correctly it was first brought up in Dec 2021. During those discussions, we figured out that maintaining and testing the lower constraints has many challenges. TC discussed all those challenges in Zed PTG and agreed to drop lower-constraints.txt file and its testing but keep them in requirements.txt with our best effort. I proposed the TC resolution on this[10], feel free to feedback there if there is any strong objection in this direction. Also sent it on ML[11] Consistent and Secure Default RBAC -------------------------------------------- I summarized the RBAC PTG discussion[12], we did not finish the discussion over the open question and decided to continue it in RBAC meetings later. I will schedule the next meeting soon. If you have any other questions than the current one, please add them to the etherpad[13] Removing the TC tag framework ---------------------------------- In TC tag framework, every TC member used to assign a few projects to check their health, needs from TC etc. It was meant to improve the interaction between TC and PTLs and contact points for any projects when TC needs it. But it did not go that way and even many of us do not know if that still exists or not. With TC weekly meetings and PTG interaction sessions, we anyways are more contacted with leaders and discussed it in PTG and agreed to remove this framework. I have proposed the removal[14] 2021 User Survey TC Question Analysis ----------------------------------------------- Jay has summarized the TC's user survey in PTG and it is up in gerrit for review[15]. Feel free to check and provide feedback. Zed cycle Leaderless projects ---------------------------------- Zaqar PTL assigned is merged[16], with that only Adjutant project is leaderless/maintainer-less. We will check Adjutant's situation again on ML and hope Braden will be ready with their company side permission[17]. Fixing Zuul config error ---------------------------- Requesting projects with zuul config error to look into those and fix them which should not take much time[18]. Project updates ------------------- * Add the cinder-three-par charm to Openstack charms[19] 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[20]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [21] 3. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [2] https://review.opendev.org/c/openstack/governance/+/835102 [3] https://review.opendev.org/c/openstack/governance/+/836706 [4] https://review.opendev.org/c/openstack/governance/+/836704 [5] https://review.opendev.org/c/openstack/governance/+/835429 [6] http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028104.ht… [7] http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028206.ht… [8] https://etherpad.opendev.org/p/tc-zed-tracker [9] https://review.opendev.org/q/projects:openstack/governance+status:open [10] https://review.opendev.org/c/openstack/governance/+/838004 [11] http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028199.ht… [12] http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028103.ht… [13] https://etherpad.opendev.org/p/rbac-zed-ptg [14] https://review.opendev.org/c/openstack/governance/+/837891 [15] https://review.opendev.org/c/openstack/governance/+/836888 [16] https://review.opendev.org/c/openstack/governance/+/831123 [17] http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027626.ht… [18] https://etherpad.opendev.org/p/zuul-config-error-openstack [19] https://review.opendev.org/c/openstack/governance/+/837781 [20] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [21] http://eavesdrop.openstack.org/#Technical_Committee_Meeting -gmann

1 0

[all][tc] Technical Committee Zed cycle Kick-Off
by Ghanshyam Mann 16 Apr '22

16 Apr '22

Hello Everyone, In PTG, we decided to continue the TC per-cycle-tracker which help us to finish the things within the timeframe of one cycle. During PTG week (TC+leader interaction and TC-related sessions), we had a lot of productive discussions[1] and collected many working items for TC. The Technical Committee's main goal is to drive more technical work to solve the OpenStack existing technical challenges. This is the main feedback from the community to TC working and I am happy to have that feedback, as well as TC, started working on it in a more productive way. Of course, we will continue doing the governance part too which does not take much bandwidth of TC members and we will also try to minimize such process-related tasks as per the current situation and needs of the community. In the Zed cycle also, we will continue to focus on the Technical works. I have created the Zed cycle TC tracker and we will be targeting 7 Technical items + 4 process/governance-focused items. Also, we will be open to taking more items if anything important comes up in between the cycle. - https://etherpad.opendev.org/p/tc-zed-tracker With that, let's continue to work together and have another successful cycle. Feel free to reach out to TC at any time (does not need to wait for the weekly meeting) for your queries or help. Also, you can find all the cycle wise trackers on this wiki page[2] [1] http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028104.ht… [2] https://wiki.openstack.org/wiki/Technical_Committee_Tracker -gmann

1 0

[TripleO][Ceph] Zed PTG Summary
by Francesco Pantano 15 Apr '22

15 Apr '22

Hello everyone, Here are a few highlights on the TripleO Ceph integration status and the plans for the next cycle. *1. Deployed ceph as a separate step* TripleO now provides a different stage (with a new cli set of commands) to bootstrap the Ceph cluster before reaching the overcloud deployment phase. This is the new default approach since Wallaby, and the short term plan is to work on the upstream CI consolidation to make sure we run this stage on the existing TripleO standalone scenarios, extending the coverage to both phases (before the overcloud deployment, when the Ceph cluster is created, and during the overcloud deployment, when the cluster is finalized according to the enabled services). It's worth mentioning that great progress in this direction has been made, and the collaboration with the tripleo-ci is one of the key points here, as they're helping on the automation aspect to test upstream pending bits with daily jobs. The next step will be working together on the automation of the promotion mechanism, which is supposed to make this process less error-prone. *2. Decouple Ceph Upgrades* Nautilus to Pacific is still managed by ceph-ansible but the stage of upgrading the cluster has been moved before the overcloud upgrade, resulting in a different maintenance window. Once the cluster is moved to Pacific, cephadm is enabled, and from this moment onwards, the upgrade process, as well as minor updates, will be managed by cephadm and can be seen as a day2 operation. The operator can now perform these kinds of tasks without any interaction with TripleO, which is still used to pull the new containers (unless another registry reachable from the overcloud is used), but the scope has been limited. *3. Ganesha transitioning to Ceph orchestrator and Ingress migration* This has been the main topic for this first ptg session: the feature it's tracked by two already approved upstream specs and the goal is to support a Ganesha service managed by cephadm instead of a tripleo-managed one. The TripleO conversation impacted many areas: *a.* the networkv2 flow has been improved and it's now possible to reserve more than 1 VIP per network, but it applies only to the ceph services; *b.* a new TripleO resource, the CephIngress daemon, has been added, and it's a key component (provided by Ceph) that is supposed to provide HA for the ceph-nfs managed daemon *c.* The tripleo cli is extended and the ceph-nfs daemon can be deployed during the bootstrap of the ceph cluster *d.* This feature depends on the manila driver development [1], which represents an effort to implement a driver that can interact with the Ceph orch cli (and the layer it provides for nfs) instead of using dbus. Further information about this conversation can be found here [1]. Part of this conversation (and really good input here actually) was about the migration plan for already existing environments where operators would like to move from a TripleO managed Ganesha to a highly available ceph-nfs managed by cephadm. The outcome here is: *1.* It's possible to move to the cephadm managed ingress daemon during the upgrade under certain constraints, but we should provide tools to finalize the migration because there's an impact not only on the server-side (and the manila service itself) but also on the clients where the shares are mounted; *2.* We might want to have options to keep the PCS managed VIP for Ganesha and avoid forcing people to migrate, and this flow should be consistent at tripleo heat templates level; For those who are interested, here's the etherpad [2] and the recording of the session [3]. Thanks, Francesco [1] https://etherpad.opendev.org/p/zorilla-ptg-manila-planning [2] https://etherpad.opendev.org/p/tripleo-zed-ceph [3] https://slagle.fedorapeople.org/tripleo-zed-ptg/tripleo-zed-ptg-ceph.mp4 -- Francesco Pantano GPG KEY: F41BD75C

1 0

[tacker] Zed PTG summary
by Yasufumi Ogawa 15 Apr '22

15 Apr '22

Hi, Thank you for joining the PTG. Here is a summary of Zed PTG of Tacker. We discussed 17 proposals through three days and agreed to whole topics. The details of proposals are on the PTG's etherpad [1]. - heat-translator maintenance - Ayumu Ueha proposed himself as a core of heat-translator from Tacker team and approved by the team. - Enhance security of APIs from Tacker for validating the certificate of a destination server. - Enhancement of Tacker-horizon Dashboard for enabling some Day2 operations (might include a part of Day0/1 operations), such as manual heal, modify VNF, change the configuration of VNFM, etc, and monitoring through GUI This blueprint proposes to extend the tacker-horizon dashboard with some new interfaces and functionalities. - Support VNF using Hardware Acceleration such as GPU, FPGA, ASIC. - Remove restrictions of using Helm Chart. - v1 API Refactoring in order to maintain and extend Tacker continuously, it's important to improve the maintainability of the v1 API. - CLI support for paging query results to improve usability of the cli tool. - We still need to discuss how we provide the pagination of the results. - Support multi artifact of ansible driver. It's already to be under reviewing. https://review.opendev.org/c/openstack/tacker/+/836107 - Enhance Multi tenant policy in LCM for enhancing of the multi-tenant policy in the VNF lifecycle management. It enables a non-admin role user to instantiate VNF, and defines tenancy isolation between admin and the non-admin role users. - Enhancement of CNF operations for k8s usecases. - https://blueprints.launchpad.net/tacker/+spec/database synchronization - https://blueprints.launchpad.net/tacker/+spec/enhance-cnf-lcm - https://blueprints.launchpad.net/tacker/+spec/enhancement-container-update - https://blueprints.launchpad.net/tacker/+spec/suport-openid-k8s-vim - https://blueprints.launchpad.net/tacker/+spec/support-instantiationlevel-cnf - Support of automatic operations - https://blueprints.launchpad.net/tacker/+spec/support-auto-lcm - https://blueprints.launchpad.net/tacker/+spec/support-autoheal-queue - Improve V2 code's UT Coverage and refactoring Tacker from caishuwen. - Enhance VNF Update functionality. - https://blueprints.launchpad.net/tacker/+spec/enhance-change-package - https://blueprints.launchpad.net/tacker/+spec/individual-vnfc-management - Support HA-cluster for high availability is an important requirement to apply Tacker to commercial systems. HA cluster such as ACT-SBY or N-ACT will be supported. - Enhance vnflcm API (hirofumi-noguchi) - https://blueprints.launchpad.net/tacker/+spec/enhance-placement - https://blueprints.launchpad.net/tacker/+spec/enhance-utils-extmanagedvl - https://blueprints.launchpad.net/tacker/+spec/multi-version-vnfd - https://blueprints.launchpad.net/tacker/+spec/sol004-package-management - https://blueprints.launchpad.net/tacker/+spec/support-subscription-cli - https://blueprints.launchpad.net/tacker/+spec/vim-management-reorganization - https://blueprints.launchpad.net/tacker/+spec/abolish-default-vim - Tacker's new requirements for commercial systems (hirofumi-noguchi) - https://blueprints.launchpad.net/tacker/+spec/enhance-system-management - https://blueprints.launchpad.net/tacker/+spec/command-conflict-handling - https://blueprints.launchpad.net/tacker/+spec/system-performance-management [1] https://etherpad.opendev.org/p/tacker-zed-ptg Thanks, Yasufumi

1 0

[largescale-sig] Large Scale SIG Forum session in Berlin?
by Thierry Carrez 15 Apr '22

15 Apr '22

Hi everyone, The CFP for Forum sessions is open until Wednesday next week at: https://cfp.openstack.org/app/berlin-2022/18/presentations Should we file a session for the Large Scale SIG? Could be a generic session ("Meet the Large Scale SIG") or a more precise topic. -- Thierry Carrez (ttx)

1 0

client authentication - ? gui okey but cli fails
by lejeczek 14 Apr '22

14 Apr '22

Hi guys. An end user here thus please tailor your advice according - meaning that I have no admin access. With GUI in a web browser I do log in but with CLI I get "usual": The request you have made requires authentication. (HTTP 401) (Request-ID:.... (rc file downloaded off the GUI) What can be the issue? many thanks, L.

2 1

[all][tc] Dropping the lower constraints maintenance
by Ghanshyam Mann 14 Apr '22

14 Apr '22

Hello Everyone, In zed cycle PTG, TC discussed the lower constraints maintenance again and after considering all the existing and current issues (discussed any times in the ML thread[1]), we agreed to drop the lower-constraints.txt file, x env, and its testing on master as well as on stable branches. But for reference to anyone using them (Debian as we know), we will keep them as it is in the requirements.txt file with our best effort to keep them up to date. I have proposed the TC resolution for this, if you have any feedback please add it on Gerrit patch: - https://review.opendev.org/c/openstack/governance/+/838004 [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019659.… http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019390… http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019672.… -gmann

1 0

[cyborg][zun][masakari][freezer-api][heat][tacker][oslo] Pending removal of 'oslo_db.sqlalchemy.enginefacade.LegacyEngineFacade'
by Stephen Finucane 14 Apr '22

14 Apr '22

o/ This is a heads up to the maintainers of the aforementioned projects that the oslo team are planning to remove the 'oslo_db.sqlalchemy.enginefacade.LegacyEngineFacade' class and related 'get_legacy_facade' helpers this cycle. The legacy engine facade pattern has been deprecated since 2015 and we want to get rid of it to reduce load on the overburdened oslo maintainers. The prefered alternative is to rely on oslo.context RequestContext-based session management. The work required to migrate can be quite significant depending on how large your DB API is but it is pretty trivial. This issue has already been fixed in a couple of projects. These can be used as blueprints for fixing the remaining affected projects: * cinder (https://review.opendev.org/q/topic:remove-legacyfacade) * nova (https://review.opendev.org/q/topic:bp%252Fnew-oslodb-enginefacade) We expect this one to take affected projects a while to resolve, so we won't remove this module until near the end of the cycle. However, this thing really needs to be removed sooner rather than later. Please let us know if you have any concerns or if the above changes are not sufficient as a guide for how to address these issues. Cheers, Stephen

1 0

[neutron] Drivers meeting - Friday 15.4.2022 - cancelled
by Lajos Katona 14 Apr '22

14 Apr '22

Hi Neutron Drivers! We have Good Friday this week, so let's cancel the drivers meeting for this week. See you at the meeting next week. Lajos Katona (lajoskatona)

1 0

[all] Devstack jobs are failing due to a git security fix
by Michael Johnson 14 Apr '22

14 Apr '22

tldr: All devstack based jobs are going to fail with newer versions of git - don't bother rechecking git has released a security fix [1] that is starting to roll out in distributions (Ubuntu focal for example) that will cause pbr to be unable to access the package metadata for packages checked out locally due to the directory ownership used in devstack. We have opened a devstack bug to track this issue: https://bugs.launchpad.net/devstack/+bug/1968798 Please see the bug for the details and example error. Michael P.S. Thanks to clarkb, fungi, and ianw for helping track down the root cause! [1] https://github.com/git/git/commit/8959555cee7ec045958f9b6dd62e541affb7e7d9

7 11

[puppet] How to disable installation of mysql::server and only create databases?
by Christian Rohmann 14 Apr '22

14 Apr '22

Hey openstack-discuss, is there any intended way of using e.g cinder::db::mysql (which is using puppet-openstacklib) to create databases, but not also run / include mysql::server which apparently happens at https://github.com/openstack/puppet-openstacklib/blob/33fb90326fadd59759d4a… ? In short I already have a running database server and only want the databases to be created. Thanks, Christian

2 2

[manila] Zed PTG summary
by Carlos Silva 14 Apr '22

14 Apr '22

Hello, zorillas and interested stackers! Thank you for attending the PTG over the last week. We had a good audience and a lot of good discussions over the proposed topics. On the official etherpad [9] you will find the notes we took during the discussions, as well as links to additional etherpads or other references. The YouTube playlist [14] holds all the recordings we had over the week. Every video corresponds to one PTG day, and their description contains the exact time frame of the discussions. *== Xena cycle retrospective ==* * We agreed and were happy with the events we have been doing in the community (collaborative review sessions, bugsquashes and some other). They help us to understand the changes that are coming in every cycle, and also get to share knowledge with the contributors. For this cycle we will define different themes for our bugsquashes. Some dates are already defined. * We agreed on the importance of the reviews from different affiliations and we decided on a few practices to involve more community members in the review process. * We brought up the enhancements we need to do in the Manila UI, and mentioned some features that we are lacking for feature parity compared to the Manila core code. * We decided to host a hackathon in the beginning of the cycle, as we had a very positive output from the last one we had. This one can focus on the functional testing of the OSC for Manila, which we are lacking. * During the Z cycle we will host the first code walkthrough for Manila. (kudos for gouthamr for the idea). The intention of this event is to help the new contributors to better understand the code and allow them to ask questions, as well as explain the structure of our repositories and go over some key parts of Manila. * We discussed the difficulties we are facing with ethercalc and we got to a point where we saw there was no alternative way to replace it. More details about the retrospective available in [1]. *== Thin Provisioning and Oversubscription improvements ==* * haixin and gouthamr brought up this topic after a few discussions on how the oversubscription issue should be solved in Manila. * Storage pools that support thin provisioning are open to an "oversubscription". * We have a ratio for allowing oversubscriptions and it also influences the way the manila scheduler filters acts. We currently have issues with that calculation. * If the backends do not report their allocated_capacity_gb, it will be inaccurate. * We can have the share manager to have a more precise calculation. * Action Items: ** haixin will write a spec with more details on how this issue is going to be addressed. *== NetApp ONTAP - migration from ZAPI to REST API ==** nahimsouza and fabioaurelio talked about the NetApp ONTAP drivers that are currently using ZAPI for communication with NetApp hardware. * NetApp is now planning to deprecate ZAPI in favor of REST. This means that if they find issues within the ZAPI calls, NetApp won't fix them anymore. * The side effect of this is that NetApp wants to migrate their driver calls from ZAPI to rest, but it will impact pretty much all operations the driver performs. * These are going to be huge changes and they intend to backport it to the oldest maintained release. * They have lots of customers using the latest versions of ONTAP but those customers do not often upgrade their OpenStack deployments. * They are looking for approaches on how to backport these changes even further. *== Add support for automatic snapshot creation and removal ==** Kiran brought up the solution proposed with a spec [2], which intends to add an automatic snapshot creation policy and automatic snapshot deletion policy for a share, considering an interval defined by an administrator. * We've asked for possible alternatives such as automating the snapshots creation via manilaclient/REST API, and also raised a few questions that would help us to enforce the need of enhancing the API. * Action Items: ** Kiran will come back with updates on the discussion points. *== Manila UI updates ==** vkmc discussed the updates for Manila UI alongside the NDSU students. * They talked about the plans we have for the UI in this cycle, as well as bringing up the feature-parity issue we currently have. * We started by filing blueprints and identifying the scope of necessary changes to get feature parity. * A taiga board [3] was created to track the progress. * We also have a few blueprints [4] for that. *== Consistent and Secure RBAC changes ==** gouthamr, gmann and vhari brought up the plans for the Z cycle, which would be continuing the plans highlighted on [5] So for Z, the idea is to: * Harden Phase 1 by re-evaluating the use of "admin" at system scope, disallowing system scope users from creating/manipulating project resources * Continue working on tempest protection tests. Liron has a patch pending reviews that starts this work [6] * Test existing tempest API/scenario tests with the new RBAC defaults and adjust any credential use or API expectations by the end of the cycle * Start working on the phase 2 per the community goal in [5] Beyond Z: * A release - Phase 3: System Reader and System Member in the default RBAC * B release: Remove deprecated policies * == OpenStack Client updates for Manila ==** maaritamm presented the progress we had so far for the OSC integration. * We are quite close to feature parity. The idea is to reach feature parity in the Z cycle and add a deprecation warning to the native client shell in python-manilaclient. * We are lacking functional tests and we came up with a plan of organizing a hackathon to be hosted close to the z-3 milestone. * This hackathon will be focused on addressing the functional tests for the client and wrapping it up. * As enforced in the past cycle, maintainers implementing new functionalities to python-manilaclient must _only_ implement them for OSC. * New features in the python-manilaclient shell will actively be discouraged. * A more detailed version is available in [7]. *== Support for highly available NFS Ganesha in the CephFS driver ==** vkmc, fmount and gouthamr presented the the Ceph orchestrator tooling that now natively supports deploying nfs-ganesha gateway servers as "ceph-nfs" cluster daemons in active/active configurations. * The Ceph community has also added support for nfs APIs to create and manipulate exports on such ceph-nfs daemons. * We discussed the changes needed to support these in Manila and how users can migrate their workloads. To provide adequate control to deployers and end users, we agreed to introduce a new protocol helper layer that will live alongside the current DBUS API helper. * When the deployment supports new NFS clusters, deployers would be able to configure "alternate" server IPs in manila which can aid a slow transition for end users to migrate to newer "preferred" servers. * We're planning to automate this transition in Triple-O while also documenting this for developers of other deployment tools. *== Devstack-plugin-ceph changes ==* * vkmc and fmount presented the changes they are implementing in order to install/deploy the ceph cluster using cephadm. There is an open change for review [8]. We are also testing the Manila CephFS job in [9]. * Native CephFS scenario tests concerning ceph-fuse are failing sporadically with timeouts while mounting. * There are few issues with testing and there is more information about them in [9]. As next steps we have: * Testing with CentOS as the devstack host and Manila's client, so we have different approaches of testing and can ensure that ubuntu testing isn't compromising the VMs and causing the possible lack of resources we are experiencing. * Splitting CI changes into different test sets focusing on different services * Turning on cephadm based deployment in the multi-node job *== Topic #Bug updates ==** vhari has shown some bug analytics and the progress we have been making over the past cycles. * We have a bunch of bugs that are old and no one has been touching them in a while (at least 2 years). * Maintainers should check launchpad and evaluate those bugs we created and/or are assigned to us and see if they are still relevant. If they are, we should keep active on them, otherwise we can just let it fall into the auto-expiry policy. * Bugsquashes have been efficient for us, we should keep doing them. ** fabioaurelio suggested a bugsquash theme that would double up as a review jam. We'd be focusing on looking at the lingering changes that are closing bugs and getting closure for them. * When we don't have the time to do the bug triaging during the Manila meeting, we will do the triaging in #openstack-manila after. * We will be hosting our bugsquashes in Z-1 and the other one between Z-2 and 3. * Action items: ** carloss will update the change with manila specific milestones to reflect our scheduled events *== Metadata API status update ==** This is an effort that started some cycles ago. We intend to allow metadata on more user facing resources in Manila [10], and do that in a generic way. * Over the Yoga cycle that was accomplished for shares, and there is a change to also permit that for share snapshots. What's next: * Getting the share snapshots changes merged over the Z cycle (M-1) * Getting the new metadata mechanism also implemented for * Share Export Locations - Target: M3 (at least API + CLI) * Share Access Rules - Target: M3 (at least API + CLI) * Share Groups - Target: M3 (at least API + CLI) *== NetApp CI Zuul v3 Migration - Challenges and lessons learned ==** Building and maintaining a stable CI system has been a huge pain point to Manila's "third party" vendor storage developers for the past few releases. * NetApp contributors have talked about their Zuul v3 setup using Software Factory. They brought up some information on their Zuul v3 CI setup and talked about some difficulties they faced during the setup. * The recording is on Manila's YouTube channel [11]. There were questions asked and raised and the discussion documented in [9]. * Action items: * Through the release cycle, we hope to offer more venues for more knowledge sharing regarding third party CI maintenance. *== FIPS compliance ==** carloss ashrod98 and ade_lee talked the attendance through the challenges and testing for FIPS * We've been through the next steps and what has been done so far in Manila ** Few changes were proposed and merged ** Our CI job is working fine with CentOS 8 but we decided we should already have it on CentOS 9 * We needed to monkey patch paramiko for some drivers ** gouthamr is concerned that if this patching paramiko change is merged, this could break older branches in the future ** A discussion in openstack-discuss will be started to ensure if this is the best approach for this issue. * At the moment, we should stick with testing using CentOS but testing with Ubuntu is under way. * Compliance steps will start on Z release * ade_lee started an audit in OpenStack services to identify non FIPS compliant libraries * Goal should be completed on AA cycle * Action Items: ** Start a discussion on patching paramiko or switching to other lib ** Submit the jobs for python-manilaclient, manila-ui and manila-tempest-plugin *== Tech Debt ==*These are a few items we would like to get moving for Manila in the next cycles. They usually involve a community goal, a request for enhancement or recommendations from the community: * Migrating from privsep to rootwrap: In progress, few changes were merged over Y cycle and we intend to have even more progress over Z. * Dropping python-keystoneclient from python-manilaclient: this is also in progress and we got a few related changes merged. We will bring this up again in the upcoming manila meetings. * Cinder/Nova online extensions support with the generic driver: this hasn't started yet and we are looking for an owner. This is more of a request for enhancement that would benefit those using the generic driver. * 26 volumes limit in the generic driver: this is something that was called out in the generic driver documentation. We agreed to try an approach where we would update the manila image and check the output for it. * Publish the container driver image on tarballs.openstack.org (or quay.io): we had few changes to the container driver in the past cycles. One functionality was implemented on it (add/update security services in share networks that are used), and for that change to be tested, the container must have OpenLDAP installed. We have a way to publish new artifacts and we could benefit from reusing that. Action items: ** carloss will work on having the new image proposed ** Bring the keystoneclient change in the upcoming manila meetings. ** Update the manila image setting hw_scsi_model=virtio-scsi and investigate if the 26 volumes limit will be solved ** Work on finding people interested to contribute in the Cinder/Nova online extensions support with the generic driver *== Manila CSI updates ==** gman0, gouthamr and vkmc talked us through some of the updates in the Manila CSI since the last PTG [12]. * We don't currently test using RWO volumes with manila-csi in cloud-provider-openstack, so we could add an "external-attacher" sidecar to ensure RWO-ness * Doing backups with manila-csi and velero/restic * Action items: ** open an issue against the CPO repo and work on testing with RWO ** open a redmine tracker to call the limitation of giving huge names to snapshots in the docs *== Community Hour ==** gouthamr brought up some details about the release cadency adjustment [13] * Also, mentioned a few implications of this and how deprecations, testing and upgrades will work * Few details in the deprecation windows and how we should be working and targeting changes in the next few cycles. * A job was recently merged in Manila to test the upgrade from tick to tick releases * Action items: ** Update the tick release job to the Xena branch [1] https://etherpad.opendev.org/p/manila-yoga-retrospective [2] https://review.opendev.org/c/openstack/manila-specs/+/823165 [3] https://review.opendev.org/c/openstack/manila-specs/+/823165 [4] https://blueprints.launchpad.net/manila-ui/+spec/api-version-features [5] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rb… [6] https://review.opendev.org/c/openstack/manila-tempest-plugin/+/805938 [7] https://etherpad.opendev.org/p/zorilla-ptg-manila-osc [8] https://review.opendev.org/c/openstack/devstack-plugin-ceph/+/826484 [9] https://etherpad.opendev.org/p/zorilla-ptg-manila [10] https://specs.openstack.org/openstack/manila-specs/specs/yoga/metadata-for-… [11] https://www.youtube.com/watch?v=Pn1ZEnlHE7A [12] https://etherpad.opendev.org/p/zorilla-ptg-manila#L413 [13] https://governance.openstack.org/tc/resolutions/20220210-release-cadence-ad… [14] https://www.youtube.com/watch?v=AIqrLdprkaE&list=PLnpzT0InFrqCjifjP1OzFgnfi…

1 0

[blazar][requirements] setuptools and python_version in upper constraints
by Pierre Riteau 14 Apr '22

14 Apr '22

Hello, In the blazar project, we have been seeing a job timeout failure in openstack-tox-py39 affecting master and stable/yoga. tox starts the "lockutils-wrapper python setup.py testr --slowest --testr-args=" process which doesn't show progress until job timeout. It started happening sometime between 2022-03-10 16:01:39 (last success on master) and 2022-03-24 16:35:15 (first timeout occurrence) [1], with no change in blazar itself and few changes in requirements. I resumed debugging today and managed to reproduce it using Ubuntu 20.04 (it doesn't happen on macOS). Here is the traceback after interrupting it if anyone wants to take a look [2]. The python process is using 100% of the CPU until interrupted. I tracked down the regression to the upper constraint on setuptools. For example, stable/yoga has: setuptools===59.6.0;python_version=='3.6' setuptools===60.9.3;python_version=='3.8' It appears this is ignored in the py39 job so the job runs with the latest setuptools. Indeed, there were some releases between March 10 and March 24. I still have to figure out what changed in setuptools to cause this behaviour. Question for requirements maintainers: is this expected behaviour, or should upper constraints also include lines for python_version=='3.9' on yoga? Thanks, Pierre Riteau (priteau) [1] https://zuul.openstack.org/builds?job_name=openstack-tox-py39&project=opens… [2] https://paste.opendev.org/show/bZO7ELmTvfMUGJPdlQ4k/

5 5

[cinder][PTG] Summary of Zed PTG
by Rajat Dhasmana 14 Apr '22

14 Apr '22

Hi All, Here is a summary of Cinder Zed PTG[1] conducted from 05th April - 8th April, 2022 from 1300 to 1700 UTC each day. Please look at the topic summary and the action items if you were the author for any topic. [1] https://wiki.openstack.org/wiki/CinderZedPTGSummary Thanks and regards Rajat Dhasmana

1 0

R: [devstack] Not able to install devstack on ubuntu 20.04
by Molka Gharbaoui 13 Apr '22

13 Apr '22

Thank you Jeremy for your prompt reply! Changing the directories ownership definetly does not work for me. Other many errors are generated. I will follow the threads to check if hopefully a better solution is suggested. ________________________________ Da: Jeremy Stanley Inviato: Mercoledì, 13 Aprile, 2022 18:53 A: openstack-discuss(a)lists.openstack.org Oggetto: Re: [devstack] Not able to install devstack on ubuntu 20.04

1 0

[devstack] Not able to install devstack on ubuntu 20.04
by Molka Gharbaoui 13 Apr '22

13 Apr '22

Hi all, I am trying to install devstack by downloading the cose through the following link: git clone https://opendev.org/openstack/devstack and then executing ./stack command which I used to use several times without any error. However, today I am getting the following error (I only changed the VM): Obtaining file:///opt/stack/keystone Preparing metadata (setup.py) ... error error: subprocess-exited-with-error × python setup.py egg_info did not run successfully. │ exit code: 1 ╰─> [16 lines of output] Error parsing Traceback (most recent call last): File "/usr/local/lib/python3.8/dist-packages/pbr/core.py", line 111, in pbr attrs = util.cfg_to_args(path, dist.script_args) File "/usr/local/lib/python3.8/dist-packages/pbr/util.py", line 272, in cfg_to_args pbr.hooks.setup_hook(config) File "/usr/local/lib/python3.8/dist-packages/pbr/hooks/__init__.py", line 25, in setup_hook metadata_config.run() File "/usr/local/lib/python3.8/dist-packages/pbr/hooks/base.py", line 27, in run self.hook() File "/usr/local/lib/python3.8/dist-packages/pbr/hooks/metadata.py", line 25, in hook self.config['version'] = packaging.get_version( File "/usr/local/lib/python3.8/dist-packages/pbr/packaging.py", line 872, in get_version raise Exception("Versioning for this project requires either an sdist" Exception: Versioning for this project requires either an sdist tarball, or access to an upstream git repository. It's also possible that there is a mismatch between the package name in setup.cfg and the argument given to pbr.version.VersionInfo. Project name keystone was given, but was not able to be found. error in setup command: Error parsing /opt/stack/keystone/setup.cfg: Exception: Versioning for this project requires either an sdist tarball, or access to an upstream git repository. It's also possible that there is a mismatch between the package name in setup.cfg and the argument given to pbr.version.VersionInfo. Project name keystone was given, but was not able to be found. [end of output] note: This error originates from a subprocess, and is likely not a problem with pip. error: metadata-generation-failed × Encountered error while generating package metadata. ╰─> See above for output. note: This is an issue with the package mentioned above, not pip. hint: See above for details. +inc/python:pip_install:1 exit_trap +./stack.sh:exit_trap:523 local r=1 ++./stack.sh:exit_trap:524 jobs -p +./stack.sh:exit_trap:524 jobs= +./stack.sh:exit_trap:527 [[ -n '' ]] +./stack.sh:exit_trap:533 '[' -f '' ']' +./stack.sh:exit_trap:538 kill_spinner +./stack.sh:kill_spinner:433 '[' '!' -z '' ']' +./stack.sh:exit_trap:540 [[ 1 -ne 0 ]] +./stack.sh:exit_trap:541 echo 'Error on exit' Error on exit +./stack.sh:exit_trap:543 type -p generate-subunit +./stack.sh:exit_trap:544 generate-subunit 1649867885 63 fail +./stack.sh:exit_trap:546 [[ -z /opt/stack/logs ]] +./stack.sh:exit_trap:549 /usr/bin/python3.8 /opt/stack/devstack/tools/worlddump.py -d /opt/stack/logs World dumping... see /opt/stack/logs/worlddump-2022-04-13-163909.txt for details +./stack.sh:exit_trap:558 exit 1 Changing the owner of the directories using the following commands allows to go further in the installation process: sudo chown -R root:root /opt/stack/horizon/ sudo chown -R root:root /opt/stack/nova/ sudo chown -R root:root /opt/stack/cinder/ etc. However, then I am getting other errors related to permissions issues so I guess changing the directories ownership is not the solution. Could you please help me in resolving this. Thank you in advance!

2 1