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

Fwd: [TRIPLEO] - ZUN Support in TripleO
by Lokendra Rathour 01 Jul '21

01 Jul '21

Hello Everyone, We are curious in understanding the usage of ZUN Sevice in TripleO with respect to which we have questions as below: 1. Does TripleO Support ZUN? 2. If not then, is there any alternative to deploy containerize services in TripleO? Any support with respect to the questions raised will definitely help us in deciding the tripleO usage. -- ~ Lokendra skype: lokendrarathour

6 7

[openstack] [DC-DC Setup] [Replication] Correct approach to a DC-DC setup for Openstack (victoria)
by Swogat Pradhan 01 Jul '21

01 Jul '21

Hi, I am trying to setup a DC-DC setup in openstack victoria, I have 2 numbers of all in one setup (controller, compute) with shared mysql and rabbitmq cluster and am using ceph image replication and configuring cinder replication on top of it. So when the 1st node goes down then i will perform a 'cinder failover-host node1' and then do a nova-evacuate to failover to the 2nd DC setup and once the node 1 comes up i will use cinder failback and live migration from node2 to node1. **i am facing some minor issues in this setup which I will ask once I know this is the right approach to the DC-DC concept. Can you please shed some light on this being the right approach or not and if not then how can i improve it? With regards Swogat pradhan

1 1

[all][tc] Technical Committee next weekly meeting on July 1st at 1500 UTC
by Ghanshyam Mann 01 Jul '21

01 Jul '21

Hello Everyone, Technical Committee's next weekly meeting is scheduled for July 1st at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, June 30th, at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann

1 1

[Swift] Object replication failures on newly upgraded servers
by Mark Kirkwood 01 Jul '21

01 Jul '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 01 Jul '21

01 Jul '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