February 2022 - openstack-discuss

[election][tc] My TC non-candidacy
by Radosław Piliszek 08 Feb '22

08 Feb '22

Dears, I am hereby announcing my TC non-candidacy. It was a great pleasure to work with you but my personal and professional life has shifted away from OpenStack enough to make it hard for me to dedicate the time the TC deserves. Kind regards, -yoctozepto

4 3

[all][elections][ptl][tc] Combined PTL/TC z cycle Election Nominations Kickoff
by Ghanshyam Mann 08 Feb '22

08 Feb '22

Hello Everyone, Nominations for OpenStack PTLs (Project Team Leads) and TC (Technical Committee) positions (5 positions) are now open and will remain open until Feb 15, 2022 23:45 UTC. All nominations must be submitted as a text file to the openstack/election repository as explained at https://governance.openstack.org/election/#how-to-submit-a-candidacy Please make sure to follow the candidacy file naming convention: candidates/z/<Project_Name or "TC">/<email_address> (for example, "candidates/z/TC/stacker(a)example.org"). The name of the file should match an email address for your current OpenStack Foundation Individual Membership. Take this opportunity to ensure that your OSF member profile contains current information: https://www.openstack.org/profile/ Any OpenStack Foundation Individual Member can propose their candidacy for an available, directly-elected seat on the Technical Committee. In order to be an eligible candidate for PTL you must be an OpenStack Foundation Individual Member. PTL candidates must also have contributed to the corresponding team during the Xena to Yoga timeframe, Mar 26, 2021 00:00 UTC - Feb 15, 2022 00:00 UTC. Your Gerrit account must also have a verified email address matching the one used in your candidacy filename. Both PTL and TC elections will be held from Feb 22, 2022 23:45 UTC through to Mar 01, 2022 23:45 UTC. The electorate for the TC election are the OpenStack Foundation Individual Members who have a code contribution to one of the official teams over the Xena to Yoga timeframe, Mar 26, 2021 00:00 UTC - Feb 15, 2022 00:00 UTC, as well as any Extra ATCs who are acknowledged by the TC. The electorate for a PTL election are the OpenStack Foundation Individual Members who have a code contribution over the Xena to Yoga timeframe, Mar 26, 2021 00:00 UTC - Feb 15, 2022 00:00 UTC, in a deliverable repository maintained by the team which the PTL would lead, as well as the Extra ATCs who are acknowledged by the TC for that specific team. The list of project teams can be found at https://governance.openstack.org/tc/reference/projects/ and their individual team pages include lists of corresponding Extra ATCs. Please find below the timeline: PTL + TC nomination starts @ Feb 08, 2022 23:45 UTC PTL + TC nomination ends @ Feb 15, 2022 23:45 UTC TC campaigning starts @ Feb 15, 2022 23:45 UTC TC campaigning ends @ Feb 22, 2022 23:45 UTC PTL + TC elections start @ Feb 22, 2022 23:45 UTC PTL + TC elections end @ Mar 01, 2022 23:45 UTC Shortly after election officials approve candidates, they will be listed on the https://governance.openstack.org/election/ page. The electorate is requested to confirm their email addresses in Gerrit prior to 2022-02-15 00:00:00+00:00, so that the emailed ballots are sent to the correct email address. This email address should match one which was provided in your foundation member profile as well. Gerrit account information and OSF member profiles can be updated at https://review.openstack.org/#/settings/contact and https://www.openstack.org/profile/ accordingly. If you have any questions please be sure to either ask them on the mailing list or to the elections officials: https://governance.openstack.org/election/#election-officials -gmann & The OpenStack Technical Election Officials

1 0

[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