June 2021 - openstack-discuss - lists.openstack.org

[Swift] Object replication failures on newly upgraded servers
by Mark Kirkwood 30 Jun '21

30 Jun '21

HI, I'm in the process of upgrading a Swift cluster from 2.7/Mitaka to 2.23/Train. While in general it seems to be going well, I'm noticing non-zero object replication failures on the upgraded nodes only, e.g: $ curl http://localhost:6000/recon/replication/object {"replication_last": 1622156911.019487, "replication_stats": {"rsync": 40580, "success": 4141229, "attempted": 2081856, "remove": 4083, "suffix_count": 14960481, "failure": 26550, "hashmatch": 4127197, "failure_nodes": {"10.11.18.67": {"obj08": 2348, "obj09": 60, "obj10": 3030, "obj02": 34, "obj03": 25, "obj01": 44, "obj06": 1498, "obj07": 28, "obj04": 69, "obj05": 36}, "10.11.18.68": {"obj03": 6901, "obj01": 293, "obj06": 1901, "obj04": 10281, "obj10": 1}, "10.12.18.76": {"obj10": 1}}, "suffix_sync": 1785, "suffix_hash": 2778}, "object_replication_last": 1622156911.019487, "replication_time": 1094.7836411476135, "object_replication_time": 1094.7836411476135} Examining the logs (/var/log/swift/object.log and /var/log/syslog) these are not throwing up any red flags (i.e no failing rsyncs noted). Any suggesting about how to get more information about what went wrong e.g: "10.11.18.67": {"obj08": 2348}, how to find what those 2348 errors were? regards Mark P.s: basic sanity checking is ok - uploaded objects go where they should and can be retrieved for 2.7 or 2.23 servers ok (the old and new version servers agree about object placement)

2 4

[Interop] board approved our new process
by Arkady Kanevsky 30 Jun '21

30 Jun '21

Team, I would like to share with you that OIF board had approved our https://opendev.org/osf/interop/src/branch/master/doc/source/process/2021A.… process. That includes that co-chairs of the working group are elected by the group. The Board punted back to WG on how to handle human readable form of guidelines. More on it on Friday. Congratulations to all for making it happen. Thanks, -- Arkady Kanevsky, Ph.D. Phone: 972 707-6456 Corporate Phone: 919 729-5744 ext. 8176456

1 0

[kolla][wallaby] OVS drops RARP packets by QEMU upon live-migration
by Gargano Andrea 30 Jun '21

30 Jun '21

Hello all, we have a new kolla-ansible wallaby installation, during live migration we lose a lot of packages as reported on bug 1815989. Could you please give us some advices to fix it? Thank you. Andrea Gargano

3 6

[tc][all] What should we have as community goals for Y series?( Starting community-wide goals ideas)
by Rico Lin 30 Jun '21

30 Jun '21

Dear all, We're now in R-22 week for Xena cycle which sounds like a perfect time to start calling for community-wide goals ideas for Y-series. According to the goal process schedule [1], we need to find potential goals, and champions before Xena milestone-1 and provide proper discussion in the community right after that to give a clear view and detail on each goal. And if we would like to keep up with the schedule, we should start right away to identify potential goals. So please help to provide ideas for Y series community-wide goals in [2]. Community-wide goals are important in terms of solving and improving a technical area across OpenStack as a whole. It has a lot more benefits to be considered from users as well from a developer's perspective. See [3] for more details about community-wide goals and processes. Also, you can refer to the backlogs of community-wide goals from this[4] and victoria cycle goals[5] (also ussuri[6]). We took cool-down cycle goal step for Xena cycle [7], so no selected goals for Xena. [1] https://governance.openstack.org/tc/goals/#goal-selection-schedule [2] https://etherpad.opendev.org/p/y-series-goals [3] https://governance.openstack.org/tc/goals/index.html [4] https://etherpad.openstack.org/p/community-goals [5] https://etherpad.openstack.org/p/YVR-v-series-goals [6] https://etherpad.openstack.org/p/PVG-u-series-goals [7] https://review.opendev.org/c/openstack/governance/+/770616 *Rico Lin* OIF Board director, OpenStack TC, Multi-arch SIG chair, Heat PTL, Senior Software Engineer@EasyStack

10 13

[TripleO] moving stable/stein and stable/queens to End of Life
by Marios Andreou 30 Jun '21

30 Jun '21

Hello TripleO, I am proposing to move to End of Life for stable/stein and stable/queens branches across all TripleO repos (stein [1] and queens [2]). The proposal was introduced and discussed in recent TripleO irc meetings [3] and there have been no objections so far. The main reason is to allow us to focus our resources on the more active branches, train ussuri victoria wallaby and xena (!). We moved the rocky branch to EOL last cycle with [4] for the same reason. I think this move is well justified as these branches are getting relatively few commits lately (so calling into question the resources we are dedicating to running and maintaining the check, gate and 3rd party periodic/promotion lines). Looking at tripleo-common, python-tripleoclient and tripleo-heat-templates I counted 9 commits to stable/stein and 23 commits to stable/queens since November 2020 (details on those numbers at [5][6]). Please speak up if you have any concerns or questions about the proposal. If there are none then the next step is to post a review against the releases repo to make it official. regards, marios [1] https://releases.openstack.org/teams/tripleo.html#stein [2] https://releases.openstack.org/teams/tripleo.html#queens [3] https://meetings.opendev.org/meetings/tripleo/2021/tripleo.2021-06-08-14.00… [4] https://review.opendev.org/c/openstack/releases/+/774244 [5] https://gist.github.com/marios/b3155fe3b1318cc26bfa4bc15c764a26#gistcomment… [6] https://gist.github.com/marios/b3155fe3b1318cc26bfa4bc15c764a26#gistcomment…

2 2

[release][stable] stale old branches probably should be EOL'd
by Előd Illés 30 Jun '21

30 Jun '21

Hi Release Team, now that stable/ocata is mostly tagged with ocata-eol tag it turned out that there are repositories that did not have any deliverables in ocata (not even a yaml under deliverables/ocata in the release repository). In fact, I've checked and there are several examples from the past where repositories have old stable branches open [1] that should be $series-eol tagged and deleted in my understanding. I think these old stable branches were skipped accidentally during the old EOL processing, so I would suggest to tag these with $series-eol and then delete the old branches. I don't see any reason these branches should be kept open. But let me know if I miss anything! If we stick to the tagging + deletion, then the next question is how to achieve this. There are a couple of options: 1. use the existing tools: such as creating a yaml file under deliverables/$series/ and add the $series-eol tag for the given repositories (I understand that these are not 'real' deliverables, but does that cause any issue for us?) 2. implement some new mechanism, similar to option 1, but clearly indicate that the tagging does not create any deliverables 3. manual tagging + deletion I think the 1st option is the easiest and since we already have the whole process there, we can simply use the existing tool. So what do you think? - Is that OK to tag these open old stable branches with $series-eol tag and then delete them? - If yes, which option from the above list is acceptable, or what else can we do? Thanks for the answers/ideas in advance, Előd [1] http://paste.openstack.org/show/806995/

4 5

Question for Openstack installation!!
by dionysa.varvarigou 30 Jun '21

30 Jun '21

Hello, Is it possible that I could have some guidance for making the Horizon for Wallaby working on ubuntu 20.04? I followed all the steps for its installation and configuration, but I cannot make it to work. The problem is that once I put in my browser my <ip address>/horizon/, it gives me the default apache2 page. So, I tried to find the available site for horizon but I cannot find it by any means. I have triple checked the horizon conf file and I have done everything according to the documentation (https://docs.openstack.org/horizon/wallaby/install/install-ubuntu.html) I tried to google and see if there is any troubleshooting but nothing. I do not know what else to do... So, is it possible that I could get some help??? I hope to hear from you soon.. Have a great day, Dionysia

1 0

[Diversity] Diversity and Inclusion July Meeting Update
by Amy Marrich 30 Jun '21

30 Jun '21

Due to most US companies having July 5th off, we will be moving the Jully D&I WG meeting Please join us Monday, July 19th at 17:00 UTC in the #openinfra-diversity channel on OFTC. The agenda can be found at https://etherpad.openstack.org/p/ diversity-wg-agenda. Thanks, Amy (spotz)

1 0

[cinder] Bug deputy report for week of 2021-30-06
by Sofia Enriquez 30 Jun '21

30 Jun '21

Hello, This is a bug report from 2021-16-06 to 2021-23-06. You're welcome to join the Cinder Bug Meeting today. Weekly on Wednesday at 1500 UTC on #openstack-cinder Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- Medium: - https://bugs.launchpad.net/cinder/+bug/1933835 "[storwize svc] In _update_replication_group On failure it should not leave the volume relation in stopped state and RCCG in stopped state". Unassigned Undecided / Invalid - https://bugs.launchpad.net/cinder/+bug/1933443 " Backup deleted but data not deleted". Unassigned Cheers, Sofia 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

[cinder] propose Sofia Enriquez for cinder core
by Brian Rosmaita 30 Jun '21

30 Jun '21

Sofia Enriquez (enriquetaso on IRC) has been active the past few cycles submitting patches, doing reviews, and participating in the Cinder weekly meeting, PTGs, and midcycles. She has also been acting as the Cinder Bug Deputy for Xena and has been running the Bug Squad meeting each week. Something I particularly appreciate is that she has included the cinder-tempest-plugin in her range of patches and reviews. Cinder and its various deliverables make up a large code base. Sofia has demonstrated a willingness and capacity to learn about the code, and I anticipate that she will continue to deepen her cinder knowledge as she continues to work in the project. At the same time, I believe that she is self-aware enough to know the limits of her knowledge and can be trusted not to approve patches that she doesn't understand. Above all, she will bring some much needed review bandwidth to the project. In the absence of objections, I'll add Sofia to the core team just before the next Cinder team meeting (Wednesday, 30 June at 1400 UTC). Please communicate any concerns to me before that time. cheers, brian

10 10