June 2023 - openstack-discuss - lists.openstack.org

[neutron] Neutron drivers meeting cancelled
by Rodolfo Alonso Hernandez 23 Jun '23

23 Jun '23

Hello Neutrinos: Due to the lack of agenda [1], today's meeting is cancelled. Have a nice weekend! [1]https://wiki.openstack.org/wiki/Meetings/NeutronDrivers

1 0

[kolla] help working config cinder and cinder-backup on different nfs servers and exports
by garcetto 23 Jun '23

23 Jun '23

good morning, i am having trouble understanding how to config different nfs shares on different nfs servers, one for cinder and ANOTHER one for use for cinder-backup, this is my files: (already check both nfs export are reachable and works fine in rw inside openstack) (kolla latest version on ubuntu 22 hosts, all-in-one-deploy) [globals.yaml] ... enable_cinder: "yes" enable_cinder_backend_nfs: "yes" enable_cinder_backup: "yes" cinder_backup_driver: "nfs" cinder_backup_share: "192.168.100.100:/exports/backup" cinder_backup_mount_options_nfs: "vers=3" [config/nfs_shares] 192.168.100.100:/exports/backup 192.168.200.200:/exports/volumes thank you.

1 0

DRaaS question
by KK CHN 22 Jun '23

22 Jun '23

List, Looking for solutions using OpenStack Similar to 1. VMWare VCDR( VMware Cloud Disaster Recovery) as a Pilot Light DR Solution hassle free Failover and Failback. 2. AWS Cloud Replication Agent( Cloud Endurance ) Operational DR solution in Cloud ( Both 1 and 2 have capabilities of acting as an Operational DR in Cloud and serving both from AWS demonstrated as a PoC ). Any solution/directives to achieve a similar to better solution using OpenStack techniques and components? Please enlighten with your ideas. Thank you Krishane.

7 9

[all][ops][rbac] RBAC discussion summary from Vancouver summit
by Ghanshyam Mann 22 Jun '23

22 Jun '23

Hello Everyone, Most of you know we had the RBAC discussion at the Vancouver summit on Tuesday. - https://etherpad.opendev.org/p/rbac-operator-feedback-vancouver2023 This forum session started providing the current progress for RBAC work which you can find in Etherpad - https://etherpad.opendev.org/p/rbac-operator-feedback-vancouver2023#L46 After the progress updates, we started the feedback from operators. I am writing the summary and feel free to add anything I missed to capture here: Admin Access: =========== * Keep current Admin (legacy admin means admin in any project) untouched. * There is a need for second-level support along with the current admin, and this can be done with the project manager * Public Cloud use case: ---------------------------- ** Currently defined RBAC goal does not solve the public cloud use case of having a domain admin manage the specific domain's user/project/role. ** If the domain admin can assign an admin role to any user under their domain, then that user gets admin access across all the projects on the service side (even projects are in different domains as the service side does not have domain boundaries) ** We do not have any better solution for now, but one idea is to have the Domain manager allow managing the user/project/ role in their domain except 'Admin' role assignment. Current legacy admin (admin across all domains) can handle the 'Admin' role assignment. I mean, domain manager behaves as domain-level admin and legacy admin as a global admin. Feel free to write other solutions if you have? Member Access: ============ * Project Member is a good fix and useful to enforce 'member' roles actually Reader Access: ============ * Project Reader is one of the most useful roles in this change. * There is an ask for a global reader, which was nothing but a system reader in past. This can be useful for performing the audit of the complete cloud. One idea is to do this with a special role _role in Keystone. I will write the spec for it, and we can talk about it there. -gmann

2 2

[ironic] Summit PTG Summary
by Jay Faulkner 22 Jun '23

22 Jun '23

Hey all, As indicated before the summit, the Ironic PTG was dedicated to in-person collaboration, hacking, and design chats but were not intended for any final decision making due to not all of our community being present. Full, contemporaneous notes taken are at https://etherpad.opendev.org/p/ironic-openinfra-2023 -- this is meant to be a high level summary. For the summit, there were several extremely well-attended Ironic talks. Thank you to all of those who gave talks! In addition, I, and other members of the Ironic community, were able to connect with many people using Ironic quietly in production with a large amount of success. As always, the Ironic community strongly encourages people with success stories to loudly communicate about them :D. Ironic did have a single forum session, where we met with several operators, answering questions and in some places providing solutions to people struggling with a problem. The full notes from the session, primarily consisting of a census of Ironic installs, are accessible from the above linked etherpad. As for the PTG sessions, there were a few topics. These are extremely rough outlines of what was discussed; but again, no specific decisions were made. - networking-generic-switch -- Several contributors, including Baptise Jonglez and John Garbutt, discussed options for scaling NGS further up in the future, including enhancing it to support other protocols, such as VXLAN. Some of these discussions have already moved to the list; and I encourage folks to engage with Baptise to make our network tooling scale even more. - Future of Ironic -- We spoke for a while about the Ironic vision document created in Rocky, targeting approximately now: https://docs.openstack.org/ironic/latest/contributor/vision.html -- we've accomplished many of the items on the list, but what's next? -- Possibilities brainstormed included: --- Enhanced network interfaces that use SDN or DPU orchestration to configure baremetal networks --- more distinct support for composible hardware --- expanding Ironic standalone use cases --- getting more directly connected with communities like Metal3 integrating into Ironic --- scaling down Ironic into a tool useful at smaller scale (that a tool like cobbler has a strong hold on today) --- terraform driver designed to call Ironic directly -- I think we should update the vision document with some of these ideas so we can use it as a measuring stick in 5-6 years, like we were able to use the Rocky vision document this time. Finally, we closed up the summit with an Ironic dinner, with 16 attendees from various companies, use cases, and backgrounds with one thing in common: we all need bare metal servers :). If you're wondering who the faces of Ironic are, here are some of us https://twitter.com/jayofdoom/status/1669531671937384449 :). I'll say, on a personal note, it was extremely nice to get to see many of my old and new friends in the OpenInfra community face to face for the first time in years. The absence of those unable to travel was felt deeply as well, and I hope we'll be able to reconnect in person in the future. Thanks, Jay Faulkner Ironic PTL

3 3

[neutron] - OVN heartbead - short agent_down_time
by Roberto Bartzen Acosta 22 Jun '23

22 Jun '23

Hello Neutron folks, We discussed in the Operators feedback session about OVN heartbeat and the use of "infinity" values for large-scale deployments because we have a significant infrastructure impact when a short 'agent_down_time' is configured. The merged patch [1] limited the maximum delay to 10 seconds. I understand the requirement to use random values to avoid load spikes, but why does this fix limit the heartbeat to 10 seconds? What is the goal of the agent_down_time parameter in this case? How will it work for someone who has hundreds of compute nodes / metadata agents? Regards, Roberto [1] - https://review.opendev.org/c/openstack/neutron/+/883687 -- _‘Esta mensagem é direcionada apenas para os endereços constantes no cabeçalho inicial. Se você não está listado nos endereços constantes no cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa mensagem e cuja cópia, encaminhamento e/ou execução das ações citadas estão imediatamente anuladas e proibidas’._ * **‘Apesar do Magazine Luiza tomar todas as precauções razoáveis para assegurar que nenhum vírus esteja presente nesse e-mail, a empresa não poderá aceitar a responsabilidade por quaisquer perdas ou danos causados por esse e-mail ou por seus anexos’.*

3 5

[all] PyCharm/JetBrains licenses renewed
by Daniel Mellado 22 Jun '23

22 Jun '23

Hi all o/ This is just to inform you that the open source licenses for PyCharm/JetBrains have been renewed for 1 extra year until Aug 2024. Best! Daniel Mellado

1 0

Experience with VGPUs
by Oliver Weinmann 22 Jun '23

22 Jun '23

Dear All, we are planning to have a POC on VGPUs in our Openstack cluster. Therefore I have a few questions and generally wanted to ask how well VGPUs are supported in Openstack. The docs, in particular: https://docs.openstack.org/nova/zed/admin/virtual-gpu.html explain quite well the general implementation. But I am more interested in general experience with using VGPUs in Openstack. We currently have a small YOGA cluster, planning to upgrade to Zed soon, with a couple of compute nodes. Currently our users use consumer cards like RTX 3050/3060 on their laptops and the idea would be to provide VGPUs to these users. For this I would like to make a very small POC where we first equip one compute node with an Nvidia GPU. Gladly also a few tips on which card would be a good starting point are highly appreciated. I know this heavily depends on the server hardware but this is something I can figure out later. Also do we need additional software licenses to run this? I saw this very nice presentation from CERN on VGPUs: https://indico.cern.ch/event/776411/contributions/3345183/attachments/18516… In the table they are listing Quadro vDWS licenses. I assume we need these in order to use the cards? Also do we need something like Cyborg for this or is VGPU fully implemented in Nova? Best Regards, Oliver

17 36

[nova][tempest] Hold your rechecks
by Sylvain Bauza 21 Jun '23

21 Jun '23

As far as I can tell, all nova-live-migration job runs are getting a FAILURE [1] due to [2] so please hold your rechecks. Thanks to Rodolfo, we have a workaround for it https://review.opendev.org/c/openstack/tempest/+/886496* so please wait until this change is merged.* Tempest cores, it would be nice if you can look at the above change quickly :) Thanks, -Sylvain [1] https://zuul.openstack.org/builds?job_name=nova-live-migration&skip=0 [2] https://bugs.launchpad.net/nova/+bug/2024160

2 1

[keystone] Updates to core reviewers
by Nikolla, Kristi 21 Jun '23

21 Jun '23

Hi all, Some updates to the core reviewers in Keystone repos. Dave Wilde (d34dh0r53) has been Keystone PTL for the Antelope and Bobcat cycle and has done an amazing work. Dave is now a core reviewer in Keystone. Artem Goncharov (gtema) is the PTL of OpenStack SDK, he is willing to help out with the Keystoneauth library, that being a core part of the SDK and CLI. Thank you Artem, you are now a core reviewer of Keystoneauth. Lance Bragstad (lbragstad) has been inactive for a bit over a year now and I believe doesn't work on OpenStack anymore. Due to that I am removing as a core reviewer from Keystone. Lance has been a contributor to Keystone and OpenStack for a really really long time and was an essential part of the Keystone team, serving as its PTL too. Best, Kristi Nikolla

3 2