June 2022 - openstack-discuss - lists.openstack.org

[neutron] Drivers meeting agenda - 01.07.2022.
by Lajos Katona 30 Jun '22

30 Jun '22

Hi Neutron Drivers, The agenda for tomorrow's drivers meeting is at [1]. * [RFE] Adding the "rekey" parameter to the api for strongswan like "dpd_action" (#link https://bugs.launchpad.net/neutron/+bug/1979044) * [RFE] Firewall Group Ordering on Port Association (#link https://bugs.launchpad.net/neutron/+bug/1979816) [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers#Agenda See you at the meeting tomorrow. Lajos Katona (lajoskatona)

1 0

[all][tc] Technical Committee next weekly meeting on 30 June 2022 at 1500 UTC
by Ghanshyam Mann 29 Jun '22

29 Jun '22

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

1 1

[tc][policy][ptl][operator] OpenSatck RBAC goal is to focus on project personas first (postpone the 'scope' implementation)
by Ghanshyam Mann 29 Jun '22

29 Jun '22

Hello Everyone, We have received a good amount of feedback from the operator. In ops meetup Berlin as well as from KDDI (Japanese telco). I have summarized the feedback in etherpad[1]. From feedback, it is clear that 'scope' enable will break heat so do NFV operators and even other operators are also confused with the 'scope' concept. Most operators want legacy admin to work as it is (able to do everything in deployment). We discussed this feedback in the policy popup meeting[2] and based on feedback and our outstanding issue of 'scope enable break heat create_stack', we decided to postpone the `scope` implementation. That is the way forward to at least implement the project personas which is asked by many operators. Basically the below direction: * Finish delivering project personas This is to introduce the `member` and `reader` roles to operate things within their project. By default, any other project role like `foo` will not be allowed to do anything in the project. * Postpone the `scope` implementation for later Some standalone services like Ironic can still have the `scope` implementation as long as it does not break any cross-service communication. Other services will make sure they work for project scope personas even with enforce_scope enabled. We are not saying 'scope' things are not good or we will never do it but at the same time, I am not sure when we will do it in future. At least moving this giant goal to focus on the project personas first will help us to deliver one good feature (project personas) for operators otherwise we are stuck. Complete details about the reason to postpone the 'scope' implementation and projects persons detail are proposed in community-wide goal, please review there. - https://review.opendev.org/c/openstack/governance/+/847418 [1] https://etherpad.opendev.org/p/rbac-operator-feedback#L45 [2] https://etherpad.opendev.org/p/rbac-zed-ptg#L171

4 5

Rocky? Stream?
by Ken D'Ambrosio 29 Jun '22

29 Jun '22

Hey, all. My company's looking for the path forward, after the switcheroo with CentOS, and we're wondering what seems to be solidly supported now and in the future. Any ideas? Thanks! -Ken

1 0

[PTG] [All] [Ops] [PTL] October 2022 Team Signup
by Kendall Nelson 29 Jun '22

29 Jun '22

Hi Everyone, At the Berlin Summit, we announced the next PTG will be held from Monday, October 17th to Thursday, October 20th, 2022 in Columbus, OH! To signup your team, you must complete the survey[1] by August 12th at 7:00 UTC. We NEED accurate contact information for the moderator of your team’s sessions. This is because the survey information will be used to organize the schedule signups which will be done via the PTGBot. If you are not on IRC, please get setup[2] on the OFTC network and join #openinfra-events. You are also encouraged to familiarize yourself with the PTGBot documentation[3] as well. If you have any questions, please reach out! Information about signing up for timeslots will be sent to moderators mid to late August. Registration will open soon! A discounted room block at the PTG venue will be available. Continue to visit openinfra.dev/ptg for updates. -Kendall (diablo_rojo) [1] Team Survey: https://openinfrafoundation.formstack.com/forms/oct2022_ptg_team_signup [2] Setup IRC: https://docs.openstack.org/contributors/common/irc.html [3] PTGBot README: https://opendev.org/openstack/ptgbot/src/branch/master/README.rst

1 0

Kolla Train deliverables are going EOL
by Radosław Piliszek 29 Jun '22

29 Jun '22

Dear Fellow OpenStackers, Kolla Train deliverables (Kolla, Kolla-Ansible, Kayobe) are going EOL. [1] Ussuri and Victoria remain in extended maintenance. Wallaby, Xena and Yoga are our current stable releases. The primary reason for EOLing is that the branch's CI is badly broken by Python2 and CentOS7 issues and there is no interest in fixing the issues. [1] https://review.opendev.org/c/openstack/releases/+/848148 Kind regards, -yoctozepto

1 0

Glance folder to store images
by A Monster 29 Jun '22

29 Jun '22

I noticied in the glance configuration file after deploying openstack that filesystem_store_datadir=/var/lib/glance/images/ however, upon inspection, I found that images weren't stored in that folder, instead all images where located in this folder */var/lib/docker/volumes/glance/_data/images/.* So I'm thinking if actually filesystem_store_datadir is not used to store images but maybe something else.

3 2

What is the best configuration of network interfaces to deploy openstack
by A Monster 29 Jun '22

29 Jun '22

So I'm deploying openstack xena using kolla ansible, and i've used infiniband network to connect between the serves of my cluster, however I was wondering whether it is advisable to use a single interface for for " *api_interface*" and "*storage_interface*" and " *tunnel_interface*" or maybe using separate interfaces would be better? Furthermore, I want to ask if using *ipoib *for the infiniband network is a better option than a regular ethernet rg45 network. Thank you all.

1 0

[cinder] Bug deputy report for week of 06-29-2022
by Sofia Enriquez 29 Jun '22

29 Jun '22

This is a bug report from 06-22-2022 to 06-29-2022. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- Medium - https://bugs.launchpad.net/cinder/+bug/1979826 "devstack-plugin-nfs-tempest-full CI job failing." Unassigned. - https://storyboard.openstack.org/#!/story/2009287 "Unexpected exception on “image create --volume.” Fix proposed to master. Low - https://bugs.launchpad.net/cinder/+bug/1979666 "Dell PowerMax - inconsistency in SG names." Fix proposed to master. - https://bugs.launchpad.net/cinder/+bug/1979667 "Dell PowerMax - creating async bootable volume fails." Fix proposed to master. - https://bugs.launchpad.net/cinder/+bug/1979668 "Dell PowerMax - Volume in multiple SG remains visible as manageable." No fix proposed to master yet. Cheers, Sofia -- Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

[all][foundation][ecosystem] External projects under the foundation hat
by Artem Goncharov 28 Jun '22

28 Jun '22

Hi all, During the summit we had some nice conversations and I wanted to actually use the chance and try to formalise the discussion to gather broad opinions and ideally solutions. Sidenotes:>>>>> - I enjoy opendev - I really enjoy gerrit and find it an ultimate code review system - I can understand people not able to cope with additional complexity and prefer pull request pattern to the change pattern - I use PR change pattern for relatively simple projects (and lot of other huge projects do it this way) - I am not blaming and not going to blame anybody here End sidenotes>>>>>> - Some month ago gophercloud folks came to us and wanted to give source code under the foundation. Feedback from us was more or less: you either host on opendev and use gerrit or not at all. Members of gopher cloud rejected proceeding this way with detailed reasoning. I can fully understand reasonings and I also observe similar issues with auto-closed GitHub PRs (for SDK or OSC) and the fact that those changes in most of the cases never really reach gerrit. Especially in the SDK area it would have been very useful to get various SDKs under single team to spread the know how and synchronise their feature sets. Maybe even use shared credentials to public OpenStack clouds to verify and publish their coverage. - Some software solutions (especially those based on Golang) were designed with GitHub in mind and are actually not really working outside. For example in order to publish provider for HashiCorp Terraform into their registry your product must be hosted on GitHub (particularly you must upload build artifacts as release on GH). There is sadly no other possibility. - My company has created HashiCorp secretstore plugin for OpenStack and we are willing to donate this under the foundation to have proper ownership of the software (not to have our company name in the hosting path since it is pretty confusing). From features point of view there is still place to evolve and it would be cool to get other interested parties to participate. We would be able to OpenDev without conceptual issues and are going to request projects for that, but that still has one issue: publishing of binary artifacts - not immediately available in opendev (afaik). On GitHub we publish it as GH Release. As such the point I am trying to address is that we as a very big project should be bit more open to the world of tools around OpenStack (I mean explicitly **not** the OpenStack itself) and allow easy integration for those who want to extend OpenStack ecosystem. Depending on the particular application this may set certain limitations on the solution (i.e. must be on GitHub, must use Jira, whatever) which might be not compatible out of box with the OpenDev scheme. Do we as a open community want to set strict boundaries or can we ease some of those for the ecosystem around of OpenStack? - Would it be possible for the project hosted outside opendev be governed by OIF and somehow visually belong to OpenStack? (As a user I would definitely choose to use GitHub.com/openstack/project_x rather then GitHub.com/some_crappy_nic/project_x) - Can such project enjoy Zuul integration not being part of opendev git hosting? Technically it is surely possible (Ansible modules were tested this way), but requires in my eyes precise definition. P.S. For the case when zuul/github integration (management) is the only limiting factor I will be gladly supporting the integration and maintenance, since we have created an Ansible collection for managing of GitHub organisations/projects/teams/members (in the project-config spirit) which we use to manage our deployment (and I know others are using it as well). Tell me what you think and let us, please, focus on how to cope with different expectations rather which one is right and which is wrong. Thanks a lot, Artem

13 46