January 2022 - openstack-discuss - lists.openstack.org

[Oslo] IRC meeting.
by Daniel Mats Niklas Bengtsson 20 Jan '22

20 Jan '22

Hi there, There were no more oslo meetings but I will take over the role of facilitator and organize the meetings. I think it's important and help to have a status and follow some topics. The next meeting will be Monday, then we will resume the old rhythm with a meeting on the first and third Monday of the month. Please feel free to update your name in the pinglist[1] if you want to join it or on the contrary if you do not want to. [1] https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_Template

1 0

[heat-tempest-plugin] call for help from plugin's maintainers
by Martin Kopec 19 Jan '22

19 Jan '22

Hello, most of the tests of heat-tempest-plugin have started failing. We noticed that in interop [1], however, we reproduced that in the project's gates as well [2]. I suspect it might be an issue with the new gabbi package - there has been an update recently. Could you please have a look. [1] https://review.opendev.org/c/openinfra/ansible-role-refstack-client/+/824832 [2] https://review.opendev.org/c/openstack/heat-tempest-plugin/+/823794 Thank you, -- Martin Kopec Senior Software Quality Engineer Red Hat EMEA

3 6

[rbac][keystone][kolla][openstack-ansible][tripleo] RBAC in Yoga for deployment projects
by Mark Goddard 19 Jan '22

19 Jan '22

Hi,

1 0

[Ironic][docs] Moving API Documentation closer to code
by Mahnoor Asghar 19 Jan '22

19 Jan '22

Dear all, I am an Outreachy intern, working with OpenStack Ironic on improving their API reference documentation mechanism. Currently, the API documentation is kept separately from the code (in the Ironic repository), which means it diverges from the code, and is difficult to maintain and manage as development progresses. It would be desirable to auto-document our REST API interactions and data structures in code along with the very classes they come from. This way, we can clearly understand the request, the response, and any other important interaction details from a single point of view inside the code. It will also be a lot easier to maintain. The current Ironic API documentation is being generated by Sphinx, using the os-api-ref extension. It would be a viable solution to move the documentation from the separate sub-directory to docstrings within the code files itself, and develop a Sphinx extension that provides essential features to generate the documentation from docstrings. More details about the proposed extension, and its features can be found on the Ironic Storyboard [1]. The wider OpenStack community may be facing similar problems maintaining their documentation, and it would be helpful to understand their perspective and concerns - with respect to using such an extension, their expectations from it, collaborating on it, and whether they have additional ideas about how we may bring API documentation closer to the code. [1]: https://storyboard.openstack.org/#!/story/2009785 Thank you and regards, Mahnoor Asghar

4 6

[ironic] [release] RFC: stop doing bugfix branches for Bifrost?
by Dmitry Tantsur 19 Jan '22

19 Jan '22

Hi team! Some time ago we introduced bugfix/X.Y branches [1] to some of the Ironic projects. This has worked pretty well and has been very helpful in ironic/inspector/IPA, but I have second thoughts about Bifrost. First, maintaining Bifrost branches is tedious enough because of how many distros we support and how quickly they change. Second, our recommended approach to using Bifrost is to git-clone master and work from it. I'm honestly unsure if the regular stable branches are used (outside of the Kolla CI), let alone bugfix branches. (I also doubt that Bifrost releases are very popular or even meaningful, but that's another topic.) As one of few people who is maintaining bugfix branches, I suggest we stop making them for Bifrost and switch Bifrost back to normal cycle-with-intermediaries. We can keep releasing 3x per cycle, just to have checkpoints, but only create "normal" stable branches. Thoughts? Dmitry [1] https://specs.openstack.org/openstack/ironic-specs/specs/approved/new-relea… -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

5 4

[VGPU] Multiple VGPUs on one VM
by Jahson Babel 19 Jan '22

19 Jan '22

Hello folks, I've seen a thread on vGPUs on this mailing list lately and I was wondering if multiple vGPUs are supported on one VM on OpenStack. From the OpenStack's documentation this seems pretty clear that it's not. ( https://docs.openstack.org/nova/latest/admin/virtual-gpu.html) But on Nvidia's side multiple vGPUs should be able to be possible on specific Linux KVM version. (https://docs.nvidia.com/grid/latest/grid-vgpu-release-notes-red-hat-el-kvm/…) Only true for RHEL systems maybe. So which one of those pieces of information should I follow ? Presumably the OpenStack's side is the correct one but I would like to be sure. And does anyone has been able to attach multiples vgpus on one VM ? Another side question that I have in mind despite the fact that I can't see how it could possibly work. Is it possible to over-commit the vGPUs resources ? Via the placement API ? Thanks in advance. Kindly, Jahson Babel

1 0

[neutron] CI meeting agenda
by Slawek Kaplonski 19 Jan '22

19 Jan '22

Hi, Please remember that today at 3pm UTC we will have Neutron CI meeting. It will be on both IRC and video: [1] as meetpad.opendev.org seems that is still disabled. Agenda for the meeting is at [2]. [1] https://meet.jit.si/neutron-ci-meetings [2] https://etherpad.opendev.org/p/neutron-ci-meetings -- Slawek Kaplonski Principal Software Engineer Red Hat

2 3

Problem with ressource provider
by Marc-Antoine Godde (Student at CentraleSupelec) 19 Jan '22

19 Jan '22

Hello, In our cluster, we have 4 computes running and we have an issue with the number 4. We can't create VMs on it, we can't migrate VMs to or from that node. VMs are still perfectly working though. After a first diagnosis, it appears that there's a problem with the ressource provider. Node is declared in the db with: - name: os-compute-4, uuid: d12ea77b-d678-40ce-a813-d8094cabbbd8 Here are the ressource provider: - name: os-compute-4, uuid: a9dc2a56-5b2d-49b1-ac47-6d996d2d029a - name: os-compute-4.openstack.local, uuid: d12ea776-d678-40ce-a813-d8094cabbbd8 In our opinion, os-compute-4.openstack.local shouldn't be there at all. We want to destroy both of the ressource provider and recreate one. I must also precise that os-compute-4 ressource provider has 0 allocation and os-compute-4.openstack.local only 3 (there’s at least 50 VMs running on it…). Moreover, for these 3 allocations, the server uuid doesn't correspond to any existing VMs. Overall, none of the VMs has a ressource allocation on os-compute-4. We found the command nova-manage placement heal_allocations on the Internet but we can't find it in any container, maybe deprecated ? The cluster is running Ussuri installed with Openstack-ansible. If you have any suggestion, any help would be appreciated. Thanks. :) Best, Marc-Antoine Godde

2 4

[horizon] Missing button "create user" in dashboard
by Eugen Block 19 Jan '22

19 Jan '22

Hi *, I have a fresh Victoria installation where the "create user" button is missing in the dashboard. Creating users via CLI works fine, also when I go to https://controller/identity/users/create I see the dialog to create a new user. I see the same in an Ussuri installation. The clouds are deployed manually (we have our own Salt mechanism) on baremetal, the OS is openSUSE Leap 15.2. What I have tried so far is to apply the keystonev3_policy.json from [1], but without success. There are no other custom policies applied, most configs are on default. There are no obvious errors in the dashboard logs, and before I change too much I wanted to ask for your advice. Can anyone help me out? Please let me know if you need more information. Thanks in advance, Eugen [1] https://bugs.launchpad.net/charm-openstack-dashboard/+bug/1775224

1 1

[nova] Instance Even Scheduling
by Ammad Syed 19 Jan '22

19 Jan '22

Hi, I have 5 compute nodes. When I deploy instances, the most of the instances automatically placed in node 1 or node 2. The other compute nodes remain empty or with one or two instances on it. enabled_filters = ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,AggregateInstanceExtraSpecsFilter I have enabled the above filters. How to ensure that instances should be scheduled on compute nodes evenly on all compute hosts based on RAM only ? Like scheduler should schedule the instance on compute host which has a large amount of RAM available then other hosts. - Ammad

3 9