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

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 15 Apr '22

15 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 15 Apr '22

15 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 15 Apr '22

15 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