February 2022 - openstack-discuss

[stable] sphinx docs jobs fail on old stable branches (no more py2 support)
by Előd Illés 08 Feb '22

08 Feb '22

Hi stable maintainers, This mail is about to get some attention to build-openstack-sphinx-docs job that recently started to fail on old stable branches (Queens and Pike) and block gates for about ~30 repositories. (The failures are also visible in periodic stable jobs). This is because py27 support from sphinx jobs were removed [1] recently. (Python 3 (py35) support was mostly done in Rocky so that branch is not affected) To unblock the gates I see the following options: 1. fix sphinx jobs to work with py35 (most probably requires some patches to backport - in a squashed patch - and maybe some resolution of requirement conflicts) 2. set sphinx jobs to non-voting (even better to remove them to do not use resources unnecessarily) 3. revert the patch [1] that removed the py2 support of sphinx (maybe the easiest thing to do, though i understand that py2 support is something that shouldn't be kept forever) 4. teams examine their old branches and if they are not really maintained, haven't merged patches recently, then probably it is a good time to propose their EOL transition according to the EOL process [1] Some additional thoughts: - When Extended Maintenance was introduced the community agreed that certain CI jobs can be removed, CI coverage can be reduced as time goes. - To keep open an old branch in Extended Maintenance helps the cooperation between vendors / users as instead of maintaining it by themselves it can be done with a common effort, which could be beneficial for everyone. On the other hand, if there are no maintainers or invested efforts to keep the branch and CI alive, then it is a reasonable decision to transition the branch to End of Life. Please consider the above options and act to eliminate the gate failures / periodic stable job failures. [1] https://review.opendev.org/c/zuul/zuul-jobs/+/827588 <https://review.opendev.org/#/q/I98c3da5b02a4ac7fb9d7bd8e00170762e77b9f40>[2] https://docs.openstack.org/project-team-guide/stable-branches.html#end-of-l… Thanks, Előd

2 1

[election][ptl][cinder] PTL non-candidacy
by Brian Rosmaita 08 Feb '22

08 Feb '22

Hello Argonauts, With the election season rapidly approaching [0], I want to communicate my intentions to the team, to wit, I will not be standing for PTL for the Z cycle. I've served as PTL for five cycles, which conflicts with my belief that it's good for open source projects to rotate leadership. I think the Cinder project is fairly healthy, but it will be good to have someone take the Cinder helm who has a fresh perspective and who will be as excited to be PTL as I was way back in Ussuri. We have an excellent project team, and I have no doubt that whoever steps up will have plenty of support from the Cinder community (including me, I don't have any intention of going anywhere in the near term). cheers, brian [0] http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027070…

7 6

Floating IP issue regarding Latest upgrade to XENA
by Adivya Singh 08 Feb '22

08 Feb '22

Hi Team, We have the latest upgrade to XENA, and we are facing an issue with XENA release , where a few times, even Floating IP attached to the instance are not reachable. I tried various ways to troubleshoot the issue, Regarding The IP is reachable from the router Namespace, The router IP is reachable, L3 agent is working Fine, as other Floating IP are reachable which are hosted through router on L3 agent, All ports are up, Interfaces are up, SNAT and DNAT are working Fine, But as soon as i dissociate and associate the Floating IP , it started working Fine Any Idea, why this Happening , and later on Fixed when Floating IP is dissociate and associate again, and later again starts happening Regards Adivya Singh

1 0

[ironic] Each deploy overwrites the entire target disk
by Radosław Piliszek 08 Feb '22

08 Feb '22

Dears, I have a question regarding the default behaviour of Ironic Python Agent - it seems that each deploy causes the entire target disk to be overwritten. I have noticed this after replacing disks with larger ones, the deployment process started taking considerably longer and I observed that each sector is rewritten on the target device. Is that expected? Can I somehow avoid it? I am using whole-disk, qcow2 images that are much smaller than the disk size (even in raw form). I am running Ironic Wallaby. The deployment method is direct. Kind regards, -yoctozepto

2 4

[openstack-helm] No Meeting Tomorrow
by Gage Hugo 08 Feb '22

08 Feb '22

Hey team, Since there's nothing on the agenda for tomorrow's meeting, it has been cancelled. We will meet again next week.

1 0

[nova][ops] Problem with nova policies for resume operation
by Massimo Sgaravatto 07 Feb '22

07 Feb '22

Dear all I am running a Xena installation I have modified the nova policy fail so that certain operations can be done only by the user who created the instance, or by the administrator This [*] is my policy.yaml file. While the suspend operation works as intended (I can suspend only my instances and I am not allowed to suspend an instance created by another user) I am not able to resume an instance that I own and that I have previously suspended. I get this error: ERROR (Forbidden): Policy doesn't allow os_compute_api:os-suspend-server:suspend to be performed. (HTTP 403) (Request-ID: req-c57458bc-b1ea-4b40-a1d2-0f67608ef673) Only removing the line: "os_compute_api:os-suspend-server:suspend": "rule:admin_api or user_id:%(user_id)s" from the policy file, I am able to resume the instance. I am not able to understand what is wrong with that policy. Any hints ? Thanks, Massimo [*] # Pause a server # POST /servers/{server_id}/action (pause) # Intended scope(s): system, project "os_compute_api:os-pause-server:pause": "rule:admin_api or user_id:%(user_id)s" # Delete a server # DELETE /servers/{server_id} # Intended scope(s): system, project "os_compute_api:servers:delete": "rule:admin_api or user_id:%(user_id)s" # Resize a server # POST /servers/{server_id}/action (resize) # Intended scope(s): system, project "os_compute_api:servers:resize": "rule:admin_api or user_id:%(user_id)s" # Rebuild a server # POST /servers/{server_id}/action (rebuild) # Intended scope(s): system, project "os_compute_api:servers:rebuild": "rule:admin_api or user_id:%(user_id)s" # Stop a server # POST /servers/{server_id}/action (os-stop) # Intended scope(s): system, project "os_compute_api:servers:stop": "rule:admin_api or user_id:%(user_id)s" # Resume suspended server # POST /servers/{server_id}/action (resume) # Intended scope(s): system, project "os_compute_api:os-suspend-server:resume": "rule:admin_api or user_id:%(user_id)s" # Suspend server # POST /servers/{server_id}/action (suspend) # Intended scope(s): system, project "os_compute_api:os-suspend-server:suspend": "rule:admin_api or user_id:%(user_id)s"

4 8

[kolla-ansible][mariadb]error (galera cluster problem ?)
by Franck VEDEL 07 Feb '22

07 Feb '22

Hello, I am in an emergency situation, quite catastrophic situation because I do not know what to do. I have an Openstack cluster with 3 servers (serv1, serv2, serv3). He was doing so well… A network admin came to me and told me to change an MTU on the cards. I knew it shouldn't be done...I shouldn't have done it. I did it. Of course, it didn't work as expected. I went back to my starting configuration and there I have a big problem with mariadb which is set up on serv1 and serv2. Here are my errors: 2022-02-04 17:40:36 0 [ERROR] WSREP: failed to open gcomm backend connection: 110: failed to reach primary view: 110 (Connection timed out) at gcomm/src/pc.cpp:connect():160 2022-02-04 17:40:36 0 [ERROR] WSREP: gcs/src/gcs_core.cpp:gcs_core_open():209: Failed to open backend connection: -110 (Connection timed out) 2022-02-04 17:40:36 0 [ERROR] WSREP: gcs/src/gcs.cpp:gcs_open():1475: Failed to open channel 'openstack' at 'gcomm://10.0.5.109:4567,10.0.5.110:4567': -110 (Connection timed out) 2022-02-04 17:40:36 0 [ERROR] WSREP: gcs connect failed: Connection timed out 2022-02-04 17:40:36 0 [ERROR] WSREP: wsrep::connect(gcomm://10.0.5.109:4567,10.0.5.110:4567) failed: 7 2022-02-04 17:40:36 0 [ERROR] Aborting I do not know what to do. My installation is done with kolla-ansible, mariadb docker restarts every 30 seconds. Can the "kolla-ansible reconfigure mariadb" command be a solution? Could the command "kolla-ansible mariadb recovery" be a solution? Thanks in advance if you can help me. Franck

3 6

[ops][cinder] resource count survey
by Brian Rosmaita 07 Feb '22

07 Feb '22

Hello operators, The Cinder project is working on the cinder quotas system in an effort to improve its accuracy and remove the necessity for operators to go through and clean it up occasionally when it gets out of sync with reality. One way to do this is to use dynamic database counting (instead of storing the usage info in a table where it can become outdated). Whether this will be a good change depends on how many records the database has to process during a transaction, which in turn depends on how many Cinder resources a project has. So we need to get some information from you. Please take this brief survey: https://rosmaita.wufoo.com/forms/cinder-resource-count-survey/ The survey closes on Wednesday 30 March at 1200 UTC, so that we can have data to discuss during the "Z" PTG. But please don't procrastinate, it's only 6 questions and the answers are all positive integers. It shouldn't take long to fill out! Thanks! brian

1 0

Re: Recently Upgraded to XENA and getting this error
by Mohammed Naser 07 Feb '22

07 Feb '22

The fix hasn’t landed yet since then. On Fri, Feb 4, 2022 at 8:38 AM Adivya Singh <adivya1.singh(a)gmail.com> wrote: > hi Mohammed, > > This is for pike release, I am talking about Xena > > Regards > Adivya Singh > > On Thu, Feb 3, 2022 at 4:37 AM Mohammed Naser <mnaser(a)vexxhost.com> wrote: > >> I think you're running into this which has been broken for a hot minute: >> >> https://review.opendev.org/c/openstack/horizon/+/808102 >> >> that patch works for us locally. >> >> On Wed, Feb 2, 2022 at 10:37 AM Adivya Singh <adivya1.singh(a)gmail.com> >> wrote: >> > >> > Hello, >> > >> > We have recently upgraded to XENA release of Openstack, and getting >> this error while trying to Resize instance using GUI, it is telling "Danger >> , Please try Later" >> > Same is working properly from CLI without any issue >> > >> > Any thoughts on this >> > >> > Regards >> > Adivya Singh >> >> >> >> -- >> Mohammed Naser >> VEXXHOST, Inc. >> > -- Mohammed Naser VEXXHOST, Inc.

2 1

[baremetal-sig][ironic] Tue Feb 8, 2022, 2pm UTC: Scaling Ironic
by Arne Wiebalck 07 Feb '22

07 Feb '22

Dear all, The Bare Metal SIG will meet tomorrow Tue Feb 8, 2022, at 2pm UTC on zoom. The meeting will feature a "topic-of-the-day" presentation by Julia Kreger on "Scaling Ironic" providing details on the massive performance and scaling improvements Ironic has seen in the latest releases. Come along and bring your questions, everyone is welcome! As usual, all details on https://etherpad.opendev.org/p/bare-metal-sig Cheers, Arne

1 0