- openstack-discuss - lists.openstack.org

Pack Stack Install Issue on CentOS 7.
by Ken.Germann＠L3Harris.com 30 May '21

30 May '21

I removed mariadb-server, mariadb-client, mariadb-compat and mariadb-common. I run packstack -answer-file=answer.conf I get this error message: ERROR : Error appeared during Puppet run: 192.245.72.101_controller.pp Error: Execution of '/usr/bin/yum -d 0 -e 0 -y install mariadb-server-galera' returned 1: Package 3:mariadb-server-10.3.20-3.el7.0.0.rdo1.x86_64 is obsoleted by MariaDB-server-10.5.10-1.el7.centos.x86_64 which is already installed You will find full trace in log /var/tmp/packstack/20210527-170042-RiVtzU/manifests/192.245.72.101_controller.pp.log Any ideas how I work around this issue? Thank You, Ken Germann UNAP IRAD System Administrator Lead Aviation Systems / l3HARRIS Technologies Office: +1-954-732-0391 / Mobile: +1-954-732-0391 l3harris.com<mailto:l3harris.com> / kgermann(a)l3harris.com<mailto:kgermann@l3harris.com> MS F-11A / 1025 W. Nasa Dr. / Melbourne, FL 32919 / USA [rsz_1harriswebpage_rotator] CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient and may contain material that is proprietary, confidential, privileged or otherwise legally protected or restricted under applicable government laws. Any review, disclosure, distributing or other use without expressed permission of the sender is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies without reading, printing, or saving.

3 2

[all][tc] What's happening in Technical Committee: summary 28th May, 21: Reading: 5 min
by Ghanshyam Mann 28 May '21

28 May '21

Hello Everyone, Here is last week's summary of the Technical Committee activities. 1. What we completed this week: ========================= * Community Infra ELK services help has been added in 2021 Upstream Investment Opportunity[1]. * It is decided to move the IRC network from Freenode to OFTC[2]. 2. TC Meetings: ============ * TC held this week meeting on Thursday; you can find the full meeting logs in the below link: - http://eavesdrop.openstack.org/meetings/tc/2021/tc.2021-05-27-15.00.log.html * We will have next week's meeting on June 3rd, Thursday 15:00 UTC[3]. 3. Activities In progress: ================== TC Tracker for Xena cycle ------------------------------ TC is using the etherpad[4] for Xena cycle working item. We will be checking and updating the status biweekly in the same etherpad. Open Reviews ----------------- * Three open reviews for ongoing activities[5]. Nomination is open for the 'Y' release naming ------------------------------------------------------ * Y release naming process is started[6]. Nomination is open until June 10th feel free to propose names in below wiki ** https://wiki.openstack.org/wiki/Release_Naming/Y_Proposals Replacing ATC terminology with AC (Active Contributors) ------------------------------------------------------------------- * As UC is merged into TC, this is to include the AUC into ATC so that they can be eligible for TC election voting. We are having a good amount of discussion on Gerrit[7], feel free to review the patch if you have any points regarding this. * In the last TC meeting, we will write a TC resolution to map the ATC with the new term AC from Bylaws' perspective. Retiring sushy-cli -------------------- * Ironic project is retiring the sushy-cli[8] MIgration from Freenode to OFTC ----------------------------------------- * TC held an emergency meeting on Wednesday, May 26th, 2021 and decided to move the IRC network from Freenode to OFTC[9]. You can find the detailed discussion in etherpad[10]. * We are also adding it as TC resolution[11]. * Next step will be communicated on ML thread, please join the channel on OFTC network. * We updated the minimum guide for how to join in OFTC in the contributor guide[12] 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[13]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [14] 3. Office hours: The Technical Committee offers a weekly office hour every Tuesday at 0100 UTC [15] 4. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://governance.openstack.org/tc/reference/upstream-investment-opportuni… [2] http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022718.html [3] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [4] https://etherpad.opendev.org/p/tc-xena-tracker [5] https://review.opendev.org/q/project:openstack/governance+status:open [6] http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022383.html [7] https://review.opendev.org/c/openstack/governance/+/790092 [8] https://review.opendev.org/c/openstack/governance/+/792348 [9] http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022718.html [10] https://etherpad.opendev.org/p/openstack-irc [11] https://review.opendev.org/c/openstack/governance/+/793260 [12] https://docs.openstack.org/contributors/common/irc.html [13] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [14] http://eavesdrop.openstack.org/#Technical_Committee_Meeting [15] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours -gmann

1 0

[interop] Interop Testing Guidelines
by Jimmy McArthur 28 May '21

28 May '21

Hi all - I noticed that the most recent testing guidelines [1] are from 2016. Is there a plan to update those to the 2020 guidelines? They still mention Chris Hoge, who is no longer in the community, and I'm assuming the guidelines there are outdated as well. Cheers, Jimmy https://opendev.org/osf/interop/src/branch/master/2016.08/procedure.rst

4 8

[ops] ops meetups team resuming meetings **NEW LOCATION**
by Chris Morgan 28 May '21

28 May '21

We'll meet briefly next Tuesday 2021-6-6 on irc.oftc.net at 10am EST in #openstack-operators Agenda https://etherpad.opendev.org/p/ops-meetups-team Chris -- Chris Morgan <mihalis68(a)gmail.com>

2 2

[requirements][keystone] sqlalchemy-1.4 update seems to impact keystone gate
by Matthew Thode 28 May '21

28 May '21

If someone from the keystone team can take a look that'd be helpful, thanks :D review is at https://review.opendev.org/788339 -- Matthew Thode

2 1

[ussuri][tripleo]
by Ruslanas Gžibovskis 28 May '21

28 May '21

Hi all, I am running deployment with TripleO. receiving error: Stack rsw/88b97419-3db1-4dac-b104-44544a044a59 UPDATE_FAILED rsw.Compute.0.Compute: resource_type: OS::TripleO::ComputeServer physical_resource_id: 613f907a-450a-48b5-995f-aa33f46d2092 status: CREATE_FAILED status_reason: | ResourceInError: resources.Compute: Went to status ERROR due to "Message: No valid host was found. , Code: 500" real 26m6.790s user 4m9.877s sys 0m32.829s meanwhile, while it is running, I see that it is booting up, loading pxe image successfully, later undercloud initiates communication on 9999 port to ironic agent listening on compute. after that it just fails deployment. I have checked containers/nova/nova-conductor.log and found interesting line, which I have preformated to see error: http://paste.openstack.org/show/idc7RcrUuMuNMkvoopxF/ which refers me to image building... Now I am building images with: http://paste.openstack.org/show/805786/ previously, I was facing this error with misconfigured elements of image, but now it should be set according to default files. does anyone have an idea, where I could try looking at to fix this issue? thank you -- Ruslanas Gžibovskis +370 6030 7030

1 1

[requirements][keystone] Werkzeug major update has gate implications
by Matthew Thode 27 May '21

27 May '21

Werkzeug had a major update that seems to break keystone gating. I'd appreciate it if someone from the keystone team could take a look at https://review.opendev.org/793022 Thanks, -- Matthew Thode

1 1

server/instance and ssh keys
by Mauricio Tavares 27 May '21

27 May '21

Is there a way to query openstack about which ssh pubkey was used with a given server?

2 3

[simplification] Making ask.openstack.org read-only
by Thierry Carrez 27 May '21

27 May '21

Hi everyone, This has been discussed several times on this mailing list in the past, but we never got to actually pull the plug. Ask.openstack.org was launched in 2013. The reason for hosting our own setup was to be able to support multiple languages, while StackOverflow rejected our proposal to have our own openstack-branded StackExchange site. The Chinese ask.o.o side never really took off. The English side also never really worked perfectly (like email alerts are hopelessly broken), but we figured it would get better with time if a big community formed around it. Fast-forward to 2020 and the instance is lacking volunteers to help run it, while the code (and our customization of it) has become more complicated to maintain. It regularly fails one way or another, and questions there often go unanswered, making us look bad. Of the top 30 users, most have abandoned the platform since 2017, leaving only Bernd Bausch actively engaging and helping moderate questions lately. We have called for volunteers several times, but the offers for help never really materialized. At the same time, people are asking OpenStack questions on StackOverflow, and sometimes getting answers there[1]. The fragmentation of the "questions" space is not helping users getting good answers. I think it's time to pull the plug, make ask.openstack.org read-only (so that links to old answers are not lost) and redirect users to the mailing-list and the "OpenStack" tag on StackOverflow. I picked StackOverflow since it seems to have the most openstack questions (2,574 on SO, 76 on SuperUser and 430 on ServerFault). We discussed that option several times, but I now proposed a change to actually make it happen: https://review.opendev.org/#/c/746497/ It's always a difficult decision to make to kill a resource, but I feel like in this case, consolidation and simplification would help. Thoughts, comments? [1] https://stackoverflow.com/questions/tagged/openstack -- Thierry

10 18

[release] IRC meeting updates
by Herve Beraud 27 May '21

27 May '21

Hello team, As you know we face issues with freenode and we need to address them ASAP. This email aims to socialize the plan that we will follow as the release team. The TC provided good guidelines to follow for the next few days/weeks, so we will apply them from A to Z [1]: 1. Do NOT change any channel topics to represent this change. This is likely to result in the channel being taken over by Freenode and will disrupt communications within our community. 2. Register your nicknames on OFTC [2][3] 3. Be *prepared* to join your channels on OFTC. The OpenStack community channels have already been registered on OFTC and await you. [3] 4. Continue to use Freenode for OpenStack discussions until the bots have been moved and the official cut-over takes place this coming weekend. We anticipate using OFTC starting Monday, May 31st. 5. Projects should work to get a few volunteers to staff their project channels on Freenode, for the near future to help redirect people to OFTC. This should occur via private messages to avoid a ban. 6. Continue to hold project meetings on Freenode until the bots are enabled on OFTC. 7. Update project wikis/documentation with the new IRC network information. We ask that you consider referring to the central contributor guide. 8. The TC is asking that projects take advantage of this time of change to consider moving project meetings from the #openstack-meeting* channels to their project channel. 9. Please avoid discussing the move to OFTC in Freenode channels as this may also trigger a takeover of the channel. So, to be clear, our next meeting will be on freenode (as usual) and it will remain there as long as our bots won't be transferred to OFTC. We should note that the TC explicitly asked us to avoid discussing the freenode/OFTC topic on our freenode channel, so don't be surprised if I don't speak about that during our next meeting. If you want to bring related feedback, then, please do it by replying to this ML thread. I'll transfer it to the TC through their etherpad [4]. If not yet done, please, start registering your nicknames on OFTC and be ready to join it ASAP. To finish, please carefully read the TC's original thread [1]. Thanks for your attention. [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022718.html [2] https://etherpad.opendev.org/p/feedback-on-freenode [3] https://www.oftc.net/Services/#register-your-account [4] https://etherpad.opendev.org/p/openstack-irc -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 0

[puppet][tripleo] Inviting tripleo CI cores to maintain tripleo jobs ?
by Takashi Kajinami 26 May '21

26 May '21

Hi team, As you know, we currently have TripleO jobs in some of the puppet repos to ensure a change in puppet side doesn't break TripleO which consumes some of the modules. Because these jobs hugely depend on the job definitions in TripleO repos, I'm wondering whether we can invite a few cores from the TripleO CI team to the puppet-openstack core group to maintain these jobs. I expect the scope here is very limited to tripleo job definitions and doesn't expect any +2 for other parts. I'd be nice if I can hear any thoughts on this topic. Thank you, Takashi

4 7

[all][tc] Technical Committee next weekly meeting on May 27th at 1500 UTC
by Ghanshyam Mann 26 May '21

26 May '21

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

1 2

[cinder][third-party][CI] revision needed to your gerrit comments
by Brian Rosmaita 26 May '21

26 May '21

Hello Cinder Third-Party CI maintainers, tl;dr - add an 'autogenerated' *tag* to your Gerrit comments [0] The recent Gerrit update has brought some changes--many good ones, but also some problems. The good news is that it is within your control to fix one of the issues we're seeing. The issue is that we lost the "Toggle CI" button in the old Gerrit, whose function was to hide all the CI comments on a review so that only the human reviewers' comments were displayed. It's a problem for reviewers because other human reviewers' comments are easily missed. So we'd like to be able to easily hide the CI comments in the new interface. (Don't worry--your CI's results are nicely displayed within the "Zuul Summary" tab on the interface, so hiding the comments aren't going to make your CI results more difficult to find. They are already clearly displayed in their own table.) In the new Gerrit interface, when you have the "Files" tab active, below the list of changed files, there is a "Change Log" tab. Right underneath it, there is a "Only Comments" toggle. When it's activated, currently all the comments from OpenStack Zuul are hidden. But the comments from other CIs are not. Your CI's comments will be hidden if you include an 'autogenerated' tag in your review input. If you are using zuul, include the tag: autogenerated:zuul Other CI systems should use the tag: autogenerated:yourCIname If your CI system uses ssh to communicate with Gerrit, you can find info about adding a tag here: https://review.opendev.org/Documentation/cmd-review.html (you specify a --tag option) If your CI system uses http to communicate with Gerrit, you can find info about adding a tag here: https://review.opendev.org/Documentation/rest-api-changes.html#set-review (you specify it in the JSON request body) The Cinder team will really appreciate your quick attention to this matter! thanks, brian [0] https://review.opendev.org/Documentation/rest-api-changes.html#review-input

1 0

Freenode and libera.chat
by Erno Kuvaja 26 May '21

26 May '21

Hi all, For those of you who have not woken up to this sad day yet. Andrew Lee has taken his stance as owner of freenode ltd. and by the (one sided) story of the former volunteer staff members basically forced the whole community out. As there is history of LTM shutting down networks before (snoonet), it is appropriate to expect that the intentions here are not aligned with the communities and specially the users who's data he has access to via this administrative takeover. I think it's our time to take swift action and show our support to all the hard working volunteers who were behind freenode and move all our activities to irc.libera.chat. Please see https://twitter.com/freenodestaff and Christian's letter which links to the others as well https://fuchsnet.ch/freenode-resign-letter.txt Best, Erno 'jokke' Kuvaja

27 84

[ptl][tc] Project's feedback on Freenode situation
by Ghanshyam Mann 26 May '21

26 May '21

Hello PTLs/Release Liaisons, As you know, there is a lot of discussion going on for Freenode situation, If you are not aware of that, these are the ML thread to read[1][2]. Most TC members (I mentioned in my weekly summary email also[3]) think to wait for more time and monitor the situation to make any decision. But in today's discussion on openstack-tc, a few projects (Ironic, Kolla) are in favour of making the decision soon instead of waiting. To proceed further, TC would like to get feedback from each project. I request PTLs to discuss this in your team and write your feedback in below etherpad: - https://etherpad.opendev.org/p/feedback-on-freenode [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022468.html [2] http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022539.html [3] http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022663.html -gmann

1 1

[cinder] xena R-18 virtual mid-cycle on 2 june
by Brian Rosmaita 26 May '21

26 May '21

As mentioned at today's weekly meeting, the Cinder Xena R-18 virtual mid-cycle will be held: DATE: Wednesday 2 June 2021 TIME: 1400-1600 UTC LOCATION: https://bluejeans.com/3228528973 The meeting will be recorded. Please add topics to the mid-cycle etherpad: https://etherpad.opendev.org/p/cinder-xena-mid-cycles cheers, brian

1 0

OpenDev IRC services are moving to OFTC this weekend
by Jeremy Stanley 26 May '21

26 May '21

As a majority of our constituent projects have voiced a preference for enacting our long-standing evacuation plan, the OpenDev Collaboratory's IRC service bots will be switching from Freenode to the OFTC network this weekend (May 29-30, 2021). We understand this is short notice, but multiple projects have requested that we act quickly. Please expect some gaps in channel logging and notifications from our various bots over the course of the weekend. I have provided a much more detailed writeup to the service-discuss mailing list, and encourage anyone with questions to read it and follow up there if needed. Subsequent updates will be sent only to service-discuss, in order to limit noise for individual project lists and keep further discussion focused in one place as much as possible: http://lists.opendev.org/pipermail/service-discuss/2021-May/000249.html -- Jeremy Stanley

1 0

[tripleo][ci] mirror issues failing jobs
by Wesley Hayutin 26 May '21

26 May '21

https://bugs.launchpad.net/tripleo/+bug/1929461 something is going on w/ either centos or the infra mirrors... I suspect centos atm. Mirror monitoring is here: http://cacti.openstack.org/cacti/graph_view.php

3 4

[ironic] Upstream Meeting - May 31st
by Iury Gregory 26 May '21

26 May '21

Hello Ironicers! Our upstream meeting on May 31st will be held on OFTC server instead of Freenode, please check the email in [1] for more details. We have updated our Wiki [2] to mention the correct IRC server, and we are updating our docs. [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022718.html [2] https://wiki.openstack.org/wiki/Meetings/Ironic Thank you! -- *Att[]'sIury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Part of the ironic-core and puppet-manager-core team in OpenStack* *Software Engineer at Red Hat Czech* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory(a)gmail.com <iurygregory(a)gmail.com>*

1 0

RDO IRC Information
by Amy Marrich 26 May '21

26 May '21

Dear RDO Community Members, As many of you know, there have been changes in Freenode which affect the RDO channel, OpenInfra channels, and the channels of many other communities we work closely with. After careful consideration, the OpenDev team has chosen to move the Open Infrastructure Foundation IRC related infrastructure to OFTC[0]. As of Monday, May 31st, OFTC will become the primary home of RDO (#rdo) including where we host our meeting. The Fedora and CentOS Communities have chosen to move to Libera[1] and due to our close relationship with these projects RDO will have a presence on this system as well also in #rdo. Our channel is already created on both systems and are ready for you to join them and it is recommended you register your Nick[2][3] on both these systems. While not a total solution, we would like to mention Matrix[4] which we hope in the future will be able to bridge OFTC and Libera.chat into one location. Thanks, Amy Marrich (spotz) 0 - https://www.oftc.net/ 1 - https://libera.chat/ 2 - https://www.oftc.net/Services/#register-your-account 3 - https://libera.chat/guides/registration 4 - https://matrix.org

1 0

threat to freenode (where openstack irc hangs out)
by Chris Morgan 26 May '21

26 May '21

https://twitter.com/dmsimard/status/1393203159770804225?s=20 https://p.haavard.me/407 I have no independent validation of this. Chris -- Chris Morgan <mihalis68(a)gmail.com>

10 15

PNDriver on openstack VM is not able to communicate to ET200SP device connected to my physical router
by Kumar Prasad, Vikash 26 May '21

26 May '21

Dear Community, I have installed openstack on Centos 7 on Virutalbox VM on windows 10. Now I am running an application PNDriver on openstack VM(VNF), which is supposed to communicate with a hardware ET200SP, which is connected to my physical home router. Now my PNDriver is not able to communicate to ET200SP hardware device. PNDriver minimum requirement to run on an interface is using ethtool it should list the speed, duplex, and port properties, but by default speed , duplex, and port values it is Showing "unknown". I tried setting these values using ethtool and somehow I was able to set duplex, speed values but port value when I am trying to set it is throwing error. My question is how we can set the port value of openstack VM(Vnf) using ethtool? Second question is that suppose if we create a VM on virtualbox, then virtualbox provides a provision for bridged type on network setting, can I not configure openstack vm (vnf) like a virtualbox VM so that my vnf can also get broadcast messages broadcasted by the connected hardware devices in my home router? Thanks Vikash kumar prasad

1 0

[cinder] Bug deputy report for week of 2021-05-26
by Sofia Enriquez 26 May '21

26 May '21

Hello, This is a bug report from 2021-05-19 to 2021-05-26. You're welcome to join the next Cinder Bug Meeting later today. Weekly on Wednesday at 1500 UTC on #openstack-cinder Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- Critical:- High: - https://bugs.launchpad.net/cinder/+bug/1929128 "Can't migrate plain encrypted volume - keymanager error". Unassigned. - https://bugs.launchpad.net/cinder/+bug/1928953 " Volume uuid of deleted volume is visible in volume list while restoring volume backup in horizon". Unassigned. Medium: - https://bugs.launchpad.net/cinder/+bug/1929606 "Create x Update Volume Metadata in Cinder Backend". Unassigned. - https://bugs.launchpad.net/cinder/+bug/1928948 "Attach volumes from different SP to a single vm, the zone ports will be replaced". Unassigned. Low: - https://bugs.launchpad.net/cinder/+bug/1929220 "doc: Volume encryption supported by the key manager in cinder" Incomplete: - https://bugs.launchpad.net/cinder/+bug/1929429 "PowerMax - check for SG is not case insensitive". Unassigned. - https://bugs.launchpad.net/cinder/+bug/1929354 "Cinder service is disabled while backup creation is still successful". Unassigned. Cheers, Sofia -- L. Sofía 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

[neutron] Update of the neutron-lib-commit group in the Gerrit
by Slawek Kaplonski 26 May '21

26 May '21

Hi, In Gerrit we have neutron-lib-core group and members of that group have permission to approve neutron-lib patches in master branch. Until today members of the neutron-drivers-core group were members of that group but I added also neutron-core group there. So now every neutron-core team member can approve neutron-lib patches as well. I think that in current state of our teams and current state of the neutron- lib project, it's perfectly fine and we can trust all our neutron cores and let them approve neutron-lib patches as well. But if You have anything against that, please let me know so we can discuss it on ML or on IRC :) -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[all] OpenStack IRC
by Mohammed Naser 26 May '21

26 May '21

Hi everyone, We'd like to invite the parties of the community who are interested in the current IRC situation to participate in the upcoming (emergency) meeting: https://etherpad.opendev.org/p/openstack-irc Thank you, Mohammed -- Mohammed Naser VEXXHOST, Inc.

1 0

[tripleo][ci] centos-stream-8 libvirt issue
by Wesley Hayutin 25 May '21

25 May '21

Greetings, This may be our first stream outage. \0/ Hooray for hitting things first upstream.. lolz FYI.. not 100% sure as it's late here, but I think I've captured what is happening. https://bugs.launchpad.net/tripleo/+bug/1929634 https://bugzilla.redhat.com/show_bug.cgi?id=1961558 Thanks

1 0

[victoria][magnum][octavia]<NOSRV> in amphora
by Luke Camilleri 25 May '21

25 May '21

I have configured magnum with a service type of LoadBalancer and it is successfully deploying an external LoadBalancer via Octavia. The problem is that I cannot reach the public IP address but can see the entries in the haproxy.log on the amphora instance and the log shows <NOSRV> 0 SC-- at the end of each entry when it is being accessed (via a browser for example). So the Octavia part seems to be fine, the config shows the correct LB --> listener --> pool --> member and the nodeports that the service should be listening on (I am assuming that the same nodeports are also used for the healthchecks) The haproxy.cfg in the amphora instance shows the below in the pool members section: server 43834d2f-4e22-4065-b448-ddf0713f2ced 192.168.1.191:31765 weight 1 check inter 60s fall 3 rise 3 server 3a733c48-24dd-426e-8394-699a908121ee 192.168.1.36:31765 weight 1 check inter 60s fall 3 rise 3 server 8d093783-79c9-4094-b3a2-8d31b1c4567f 192.168.1.99:31765 weight 1 check inter 60s fall 3 rise 3 and the status of the pool's members (# openstack loadbalancer member list) is as follows: +------------------------------------------------------------+---------------------------+-----------------+-----------------------+---------------------------+ | id | provisioning_status | address | protocol_port | operating_status | 8d093783-79c9-4094-b3a2-8d31b1c4567f ACTIVE 192.168.1.99 31765 ERROR 43834d2f-4e22-4065-b448-ddf0713f2ced ACTIVE 192.168.1.191 31765 ERROR 3a733c48-24dd-426e-8394-699a908121ee ACTIVE 192.168.1.36 31765 ERROR From the below loadbalancer healthmonitor show command I can see that the health checks are being done via TCP on the same port and can confirm that the security group allows the nodeports range (ALLOW IPv4 30000-32767/tcp from 0.0.0.0/0) +---------------------+--------------------------------------+ | Field | Value +---------------------+--------------------------------------+ | provisioning_status | ACTIVE | type | TCP | id | 86604638-27db-47d2-ad9c-0594564a44be | operating_status | ONLINE +---------------------+--------------------------------------+ $ kubectl describe service nginx-service Name: nginx-service Namespace: default Labels: <none> Annotations: <none> Selector: app=nginx Type: LoadBalancer IP Families: <none> IP: 10.254.255.232 IPs: <none> LoadBalancer Ingress: 185.89.239.217 Port: <unset> 80/TCP TargetPort: 8080/TCP NodePort: <unset> 31765/TCP Endpoints: 10.100.4.11:8080,10.100.4.12:8080,10.100.5.10:8080 Session Affinity: None External Traffic Policy: Cluster Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal EnsuringLoadBalancer 29m service-controller Ensuring load balancer Normal EnsuredLoadBalancer 28m service-controller Ensured load balancer The Kubernetes deployment file: apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:latest ports: - containerPort: 8080 --- apiVersion: v1 kind: Service metadata: name: nginx-service spec: selector: app: nginx type: LoadBalancer ports: - protocol: TCP port: 80 targetPort: 8080 Does ayone have any pointers as to why the amphora is not able to reach the nodeports of the kubernetes workers? Thanks in advance

2 2

[all][infra] Topic change request for the retired projects IRC channel
by Ghanshyam Mann 25 May '21

25 May '21

Hi infra-root, We have retired the few projects in OpenStack and their IRC channel are still there. I chatted with fungi about it on TC channel and he suggested that unregistering these channels is not a good idea or recommendation. In that case, can we change the Topic of these channels to something saying that "XYZ project is retired and this channel is also not active, contact openstack-discuss ML for any query" Below is the list of retired projects channel: #openstack-karbor #openstack-searchlight #openstack-qinling #openstack-tricircle #congress -gmann

3 4

[kolla][kolla-absible][cinder][iscsi]
by Franck VEDEL 25 May '21

25 May '21

Hello. First, sorry…poor english… so it’s a google translation. I hope you could understand my problem. Following the installation (with kolla ansiible) of an openstack (wallaby) on a physical server (under centos8), we were able to see all the possibilities offered in our teaching by Openstack. (i’m working in a french university). For various reasons, we need to extend this manipulation. We will have 3 nodes (dell R740) and a Dell bay for storage.(dell compellent) After having mounted a first test with 3 servers (T340), and put the storage (LVM) on node 3 (without the bay therefore) to test whether we had understood certain things correctly (in particular the parameter of the « multinode" file and that of « globals.xml"), we want to test with the Compellent bay. My question is as follows: knowing that the 3 nodes are three identical servers, in the multinode file, how to configure [storage]… should one of the 3 servers be put, add the iscsid docker… or else put the IP of the bay . I admit that this aspect is problematic for me. what about « enable_iscsii » and « enable_backends_lvm » parameters ? In a configuration like mine, would you put a "controller" or 2 or 3? Should we instead put an LVM on one of the servers and with iscsi make this LVM point the bay? Maybe these are silly questions, I'm not sure. This use of the bay is new and I don't know how best to do it. Between cinder, lvm, iscsi, the bay, the multinode file and the options of globals.xml, it is still not easy at first Franck VEDEL

2 1

[cinder] priority reviews for milestone -1
by Brian Rosmaita 25 May '21

25 May '21

Xena milestone-1 is this week. One of the Cinder project priorities for M-1 is the long-awaited removal of the Block Storage API v2 and its support in the python-cinderclient. Patches are available for your reviewing pleasure: https://review.opendev.org/q/topic:%22drop-v2%22+status:open cheers, brian

1 0

[openstack-helm] Meeting Cancelled
by Gage Hugo 25 May '21

25 May '21

Hey team, Since there are no agenda items [0] for the IRC meeting today, the meeting is cancelled. Our next meeting will be June 1st. Thanks [0] https://etherpad.opendev.org/p/openstack-helm-weekly-meeting

1 0

[cinder] reminder: this week's meeting in video+IRC
by Brian Rosmaita 25 May '21

25 May '21

Quick reminder that this week's Cinder team meeting on Wednesday 26 May, being the final meeting of the month, will be held in both videoconference and IRC at the regularly scheduled time of 1400 UTC. These are the video meeting rules we've agreed to: * Everyone will keep IRC open during the meeting. * We'll take notes in IRC to leave a record similar to what we have for our regular IRC meetings. * Some people are more comfortable communicating in written English. So at any point, any attendee may request that the discussion of the current topic be conducted entirely in IRC. * The meeting will be recorded. connection info: https://bluejeans.com/3228528973 meeting agenda: https://etherpad.opendev.org/p/cinder-xena-meetings cheers, brian

1 0

[victoria] Reboot problem
by Albert Shih 25 May '21

25 May '21

Hi I'm running (trying) a openstack (version victoria) with a Dell Unity storage unit. When I'm create a instance, everything work fine, the block volume are created on the Unity, the mount (with iscsi) work on the compute and the instance boot normaly. But if I shutdown a instance and try to restart it, it's failed. It's just like the block volume cannot be mount. I check on the unity eveyrthing are ok In the log of the compute /var/log/nova/nova-compute.log I can see : Any idea ? Regards 2021-05-21 21:39:15.849 2663 WARNING os_brick.initiator.connectors.iscsi [req-42f8147b-b006-4af7-8dfb-31c39b46b728 868dde297576ce232570ea549928d02d58f543007825d199eb48f30a10139c96 416ac2de9ed74316920e9cbe3d376bb3 - 223c116cac324ae19fd74877a6c06d27 223c116cac324ae19fd74877a6c06d27] LUN 5 on iSCSI portal 10.15.23.252:3260 not found on sysfs after logging in. 2021-05-21 21:39:15.952 2663 WARNING os_brick.initiator.connectors.iscsi [req-42f8147b-b006-4af7-8dfb-31c39b46b728 868dde297576ce232570ea549928d02d58f543007825d199eb48f30a10139c96 416ac2de9ed74316920e9cbe3d376bb3 - 223c116cac324ae19fd74877a6c06d27 223c116cac324ae19fd74877a6c06d27] Couldn't find iSCSI nodes because iscsiadm err: iscsiadm: No records found : os_brick.exception.VolumeDeviceNotFound: Volume device not found at . 2021-05-21 21:39:15.960 2663 WARNING os_brick.initiator.connectors.iscsi [req-42f8147b-b006-4af7-8dfb-31c39b46b728 868dde297576ce232570ea549928d02d58f543007825d199eb48f30a10139c96 416ac2de9ed74316920e9cbe3d376bb3 - 223c116cac324ae19fd74877a6c06d27 223c116cac324ae19fd74877a6c06d27] iscsiadm stderr output when getting sessions: iscsiadm: No active sessions. : os_brick.exception.VolumeDeviceNotFound: Volume device not found at . 2021-05-21 21:39:16.231 2663 INFO nova.compute.manager [req-42f8147b-b006-4af7-8dfb-31c39b46b728 868dde297576ce232570ea549928d02d58f543007825d199eb48f30a10139c96 416ac2de9ed74316920e9cbe3d376bb3 - 223c116cac324ae19fd74877a6c06d27 223c116cac324ae19fd74877a6c06d27] [instance: ec79c0d6-259d-466f-94da-def4ce318d3a] Successfully reverted task state from powering-on on failure for instance. 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server [req-42f8147b-b006-4af7-8dfb-31c39b46b728 868dde297576ce232570ea549928d02d58f543007825d199eb48f30a10139c96 416ac2de9ed74316920e9cbe3d376bb3 - 223c116cac324ae19fd74877a6c06d27 223c116cac324ae19fd74877a6c06d27] Exception during message handling: os_brick.exception.VolumeDeviceNotFound: Volume device not found at . 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server Traceback (most recent call last): 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/oslo_messaging/rpc/server.py", line 165, in _process_incoming 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server res = self.dispatcher.dispatch(message) 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/oslo_messaging/rpc/dispatcher.py", line 276, in dispatch 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server return self._do_dispatch(endpoint, method, ctxt, args) 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/oslo_messaging/rpc/dispatcher.py", line 196, in _do_dispatch 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server result = func(ctxt, **new_args) 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/nova/exception_wrapper.py", line 77, in wrapped 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server _emit_exception_notification( 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server self.force_reraise() 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server six.reraise(self.type_, self.value, self.tb) 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/six.py", line 703, in reraise 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server raise value 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/nova/exception_wrapper.py", line 69, in wrapped 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server return f(self, context, *args, **kw) 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/nova/compute/manager.py", line 188, in decorated_function 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server LOG.warning("Failed to revert task state for instance. " 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server self.force_reraise() 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server six.reraise(self.type_, self.value, self.tb) 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/six.py", line 703, in reraise 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server raise value 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/nova/compute/manager.py", line 159, in decorated_function 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server return function(self, context, *args, **kwargs) 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/nova/compute/utils.py", line 1456, in decorated_function 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server return function(self, context, *args, **kwargs) 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/nova/compute/manager.py", line 216, in decorated_function 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server compute_utils.add_instance_fault_from_exc(context, 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server self.force_reraise() 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server six.reraise(self.type_, self.value, self.tb) 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/six.py", line 703, in reraise 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server raise value 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/nova/compute/manager.py", line 205, in decorated_function 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server return function(self, context, *args, **kwargs) 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/nova/compute/manager.py", line 3152, in start_instance 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server self._power_on(context, instance) 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/nova/compute/manager.py", line 3120, in _power_on 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server self.driver.power_on(context, instance, 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 3429, in power_on 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server self._hard_reboot(context, instance, network_info, block_device_info, 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 3294, in _hard_reboot 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server xml = self._get_guest_xml(context, instance, network_info, disk_info, 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 6364, in _get_guest_xml 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server conf = self._get_guest_config(instance, network_info, image_meta, 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 6006, in _get_guest_config 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server storage_configs = self._get_guest_storage_config(context, 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 4750, in _get_guest_storage_config 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server self._connect_volume(context, connection_info, instance) 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 1623, in _connect_volume 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server vol_driver.connect_volume(connection_info, instance) 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/nova/virt/libvirt/volume/iscsi.py", line 64, in connect_volume 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server device_info = self.connector.connect_volume(connection_info['data']) 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/os_brick/utils.py", line 137, in trace_logging_wrapper 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server return f(*args, **kwargs) 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/oslo_concurrency/lockutils.py", line 359, in inner 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server return f(*args, **kwargs) 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/os_brick/initiator/connectors/iscsi.py", line 519, in connect_volume 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server self._cleanup_connection(connection_properties, force=True) 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server self.force_reraise() 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server six.reraise(self.type_, self.value, self.tb) 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/six.py", line 703, in reraise 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server raise value 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/os_brick/initiator/connectors/iscsi.py", line 513, in connect_volume 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server return self._connect_single_volume(connection_properties) 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/os_brick/utils.py", line 61, in _wrapper 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server return r.call(f, *args, **kwargs) 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/retrying.py", line 212, in call 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server raise attempt.get() 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/retrying.py", line 247, in get 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server six.reraise(self.value[0], self.value[1], self.value[2]) 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/six.py", line 703, in reraise 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server raise value 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/retrying.py", line 200, in call 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server attempt = Attempt(fn(*args, **kwargs), attempt_number, False) 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/os_brick/initiator/connectors/iscsi.py", line 591, in _connect_single_volume 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server raise exception.VolumeDeviceNotFound(device='') 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server os_brick.exception.VolumeDeviceNotFound: Volume device not found at . 2021-05-21 21:39:16.237 2663 ERROR oslo_messaging.rpc.server 2021-05-21 21:43:45.556 2663 WARNING nova.compute.manager [req-6d91e265-b6b2-4522-826d-176e0d24a2d3 - - - - -] While synchronizing instance power states, found 1 instances in the database and 0 instances on the hypervisor. 2021-05-21 21:43:45.598 2663 INFO nova.compute.manager [-] [instance: ec79c0d6-259d-466f-94da-def4ce318d3a] During _sync_instance_power_state the DB power_state (4) does not match the vm_power_state from the hypervisor (0). Updating power_state in the DB to match the hypervisor. -- Albert SHIH Observatoire de Paris France xmpp: jas(a)obspm.fr Heure local/Local time: Fri May 21 11:43:30 PM CEST 2021

2 2

[telemetry] Retire panko
by Matthias Runge 24 May '21

24 May '21

Hi there, over the past couple of cycles, we have seen decreasing interest on panko. Also it has some debts, which were just carried over from the early days. We discussed over at the PTG and didn't really found a reason to keep it alive or included under OpenStack. With that, it also makes sense to retire puppet-panko. I'll wait for 1-2 weeks and propose appropriate patches to get it retired then, if I don't hear anything against it or if there are any takers. Matthias

1 2

[automation-sig][freezer][i18n-sig][powervmstacker-sig][public-cloud-sig] IRC channel cleanup
by Jeremy Stanley 24 May '21

24 May '21

I've proposed a pair of changes removing the OpenDev Collaboratory IRC bots (including logging) from inactive channels. Some of these channels correspond to current groups within the OpenStack community, so it's only fair to give them a heads up and let them know. The following channels have had no human discussion at all (no comments from anything other than our bots) for all of 2021 so far: * #openstack-auto-scaling * #openstack-fr * #openstack-freezer * #openstack-powervm * #openstack-publiccloud * #openstack-self-healing It's fine if these efforts aren't utilizing IRC, but there's probably little point in us logging or reporting information in them if they're unused. The patches for removing our services from those channels are available for review here (they also include cleanup of channels for other known defunct efforts or vestiges of channels which have since move to new names): https://review.opendev.org/792301 https://review.opendev.org/792302 If you're concerned and would like to resume using one or more of these channels, feel free to follow up here on the mailing list or with review comments some time in the next few days. If there are no objections I plan to merge these no later than Monday, May 24. Of course it's quite easy to reinstate services on a channel at any time, so if you don't see this until the changes have already merged, please follow up anyway and we can restore the bots as needed. -- Jeremy Stanley

1 1

[neutron] Bug deputy report (week starting on 2021-05-17)
by Bernard Cafarelli 24 May '21

24 May '21

Hey neutrinos, we are starting a new bug deputy rotation (new dates available as usual at [0]), here are the bugs that were reported last week. Skipping invalid/duplicate bugs, this was relatively quiet, most bugs have fixes or assignees. OVN eyes are welcome on https://bugs.launchpad.net/bugs/1929197 (unconfirmed section). In details: Critical * Fullstack test TestUninterruptedConnectivityOnL2AgentRestart failing often with LB agent - https://bugs.launchpad.net/bugs/1928764 Causing FT failures, lajos looking into it in https://review.opendev.org/c/openstack/neutron/+/792507 * Devstack "fixup_ubuntu" method removed - https://bugs.launchpad.net/bugs/1928805 Fixed with https://review.opendev.org/c/openstack/neutron/+/791983 * Docs job is broken in neutron - https://bugs.launchpad.net/bugs/1928913 pyroute2 issue with newer versions, https://review.opendev.org/c/openstack/neutron/+/792180 fixes it for older branches, and https://review.opendev.org/c/openstack/neutron/+/792077 in master (dependency will be added to pyroute2 directly soon) Medium * "test_reserve_provider_segment_without_physical_network" failing randomly - https://bugs.launchpad.net/bugs/1929190 Proposed test fix https://review.opendev.org/c/openstack/neutron/+/792559 Low * Missing packages in openSuse installation steps - https://bugs.launchpad.net/bugs/1929012 Small suggested doc fix on packages to install for L3 agent Unconfirmed * [OVN] SB connection unreliable - https://bugs.launchpad.net/bugs/1929197 Needs some OVN eyes, error on "AttributeError: 'NoneType' object has no attribute 'chassis_exists'" Incomplete * [stein][neutron] l3 agent error - https://bugs.launchpad.net/bugs/1928675 After a migration from queens, controllers go OOM with HA routers "Respawning ip_monitor" logs Mentioned env was cleaned, we may get more information on next env update [0] https://wiki.openstack.org/wiki/Network/Meetings#Bug_deputy -- Bernard Cafarelli

1 0

[TripleO] Opting out of global-requirements.txt
by James Slagle 24 May '21

24 May '21

I'd like to propose that TripleO opt out of dependency management by removing tripleo-common from global-requirements.txt. I do not feel that the global dependency management brings any advantages or anything needed for TripleO. I can't think of any reason to enforce the ability to be globally pip installable with the rest of OpenStack. Two of our most critical projects, tripleoclient and tripleo-common do not even put many of their data files in the right place where our code expects them when they are pip installed. So, I feel fairly confident that no one is pip installing TripleO and relying on global requirements enforcement. One potential advantage of not being in global-requirements.txt is that our unit tests and functional tests could actually test the same code. As things stand today, our unit tests in projects that depend on tripleo-common are pinned to the version in global-requirements.txt, while our functional tests currently run with tripleo-common from master (or included depends-on). The changes needed would be (aiui): - Remove tripleo repos from projects.txt - Remove check-requirements jobs from those same repos - Remove tripleo-common from global-requirements.txt I think we should also plan to backport these changes to Wallaby. Let me know any concerns or feedback, or anything I might be overlooking. Thanks. -- -- James Slagle --

9 14

[kolla] Draft release process
by Mark Goddard 24 May '21

24 May '21

Hi, At the Xena PTG [1] we discussed changing the early phases of our release process to provide more stability while developing features for Kolla projects. We also agreed to firm up timing and improve documentation around some of the steps of the release process nearer to the release. I have drafted a new release process/schedule [2] based on these ideas. Please share your comments, thoughts and concerns either here or in the Etherpad. Thanks, Mark [1] https://etherpad.opendev.org/p/kolla-xena-ptg [2] https://etherpad.opendev.org/p/kolla-release-process-draft

1 0

[kolla] master branch open for development
by Mark Goddard 24 May '21

24 May '21

Hi, Apologies, this email should have been sent some time ago. I wanted to notify the community that the master branch of Kolla projects is open for development. Note that review focus will still be on patches relevant to Wallaby until it is released. Thanks, Mark

1 0

[wallaby][trove] Instance Volume Resize
by Ammad Syed 24 May '21

24 May '21

Hi, I am using wallaby / trove on ubuntu 20.04. I am trying to extend volume of database instance. Its having trouble that instance cannot exceed volume size of 10GB. My flavor has 2vcpus 4GB RAM and 10GB disk. I created a database instance with 5GB database size and mysql datastore. The deployment has created 10GB root and 5GB /var/lib/mysql. I have tried to extend volume to 11GB, it failed with error that "Volume 'size' cannot exceed maximum of 10 GB, 11 cannot be accepted". I want to keep root disk size to 10GB and only want to extend /var/lib/mysql keeping the same flavor. Is it possible or should I need to upgrade flavor as well ? -- Regards, Syed Ammad Ali

2 4

[all][tc] What's happening in Technical Committee: summary 21th May, 21: Reading: 5 min
by Ghanshyam Mann 22 May '21

22 May '21

Hello Everyone, Here is last week's summary of the Technical Committee activities. 1. What we completed this week: ========================= Project updates: ------------------- * None for this week. Other updates: ------------------ * None for this week. 2. TC Meetings: ============ * TC held this week meeting on Thursday; you can find the full meeting logs in the below link: - http://eavesdrop.openstack.org/meetings/tc/2021/tc.2021-05-20-15.00.log.html * We will have next week's meeting on May 27th, Thursday 15:00 UTC[1]. 3. Activities In progress: ================== TC Tracker for Xena cycle ------------------------------ TC is using the etherpad[2] for Xena cycle working item. We will be checking and updating the status biweekly in the same etherpad. Open Reviews ----------------- * Four open reviews for ongoing activities[3]. Starting the 'Y' release naming process --------------------------------------------- * Y release naming process is started[4]. Nomination is open until June 10th feel free to propose names in below wiki ** https://wiki.openstack.org/wiki/Release_Naming/Y_Proposals Replacing ATC terminology with AC (Active Contributors) ------------------------------------------------------------------- * As UC is merged into TC, this is to include the AUC into ATC so that they can be eligible for TC election voting. We are having a good amount of discussion on Gerrit[5], feel free to review the patch if you have any points regarding this. * In the last TC meeting, we will write a TC resolution to map the ATC with the new term AC from Bylaws' perspective. Retiring sushy-cli -------------------- * Ironic project is retiring the sushy-cli[6] Discussion on moving from Freenode -------------------------------------------- * As you know there are changes in Freenode organization/governance strategy and policies, we are having a lot of discussion over ML on this[7][8]. * In TC, we many members think to monitor this situation and not to make any quick decision in hurry. This also needs to decide which platform is better for the long term. Until then we will continue on Freenode. * As Naser mentioned in the ML thread if anyone feels a very strong opinion to be discussed on priority, feel free to add this in next week's TC meeting agenda. 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[9]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [10] 3. Office hours: The Technical Committee offers a weekly office hour every Tuesday at 0100 UTC [11] 4. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [2] https://etherpad.opendev.org/p/tc-xena-tracker [3] https://review.opendev.org/q/project:openstack/governance+status:open [4] http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022383.html [5] https://review.opendev.org/c/openstack/governance/+/790092 [6] https://review.opendev.org/c/openstack/governance/+/792348 [7] http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022468.html [8] http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022539.html [9] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [10] http://eavesdrop.openstack.org/#Technical_Committee_Meeting [11] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours -gmann

1 0

[largescale-sig][neutron] What driver are you using?
by Arnaud Morin 22 May '21

22 May '21

Hey large-scalers, We had a discusion in my company (OVH) about neutron drivers. We are using a custom driver based on BGP for public networking, and another custom driver for private networking (based on vlan). Benefits from this are obvious: - we maintain the code - we do what we want, not more, not less - it fits perfectly to the network layer our company is using - we have full control of the networking stack But it also have some downsides: - we have to maintain the code... (rebasing, etc.) - we introduce bugs that are not upstream (more code, more bugs) - a change in code is taking longer, we have few people working on this (compared to a community based) - this is not upstream (so not opensource) - we are not sharing (bad) So, we were wondering which drivers are used upstream in large scale environment (not sure a vlan driver can be used with more than 500 hypervisors / I dont know about vxlan or any other solution). Is there anyone willing to share this info? Thanks in advance!

2 3

[octavia][tripleo][kolla][stable][release] $series-eol delete problem
by Előd Illés 21 May '21

21 May '21

Hi teams in $SUBJECT, during the deletion of $series-eol tagged branches it turned out that the below listed branches / repositories contains merged patches on top of $series-eol tag. The issue is with this that whenever the branch is deleted only the $series-eol (and other) tags can be checked out, so the changes that were merged after the eol tags, will be *lost*. There are two options now: 1. Create another tag (something like: "$series-eol-extra"), so that the extra patches will not be lost completely, because they can be checked out with the newly created tags 2. Delete the branch anyway and don't care about the lost patch(es) Here are the list of such branches, please consider which option is good for the team and reply to this mail: openstack/octavia * stable/stein has patches on top of the stein-eol tag * stable/queens has patches on top of the queens-eol tag openstack/kolla * stable/pike has patches on top of the pike-eol tag * stable/ocata has patches on top of the ocata-eol tag openstack/tripleo-common * stable/rocky has patches on top of the rocky-eol tag openstack/os-apply-config * stable/pike has patches on top of the pike-eol tag * stable/ocata has patches on top of the ocata-eol tag openstack/os-cloud-config stable/ocata has patches on top of the ocata-eol tag Thanks, Előd

5 5

[all][stable] Delete $series-eol tagged branches
by Előd Illés 21 May '21

21 May '21

Hi, As I wrote previously [1] the long-waited deletion of $series-eol tagged branches started with the removal of ocata-eol tagged ones first (for the list of deleted branches, see: [2]) Then I also sent out a warning [3] about the next step, to delete pike-eol tagged branches, which finally happened today (for the list of deleted branches, see: [4]). So now I'm sending out a *warning* again, that as a 3rd step, the deletion of already tagged but still open branches will continue in 1 or 2 weeks time frame. If everything works as expected, then branches with *queens-eol*, *rocky-eol* and *stein-eol* tags can be processed in one batch. Also I would like to ask the teams who have $series-eol tagged branches to abandon all open patches on those branches, otherwise the branch cannot be deleted. Thanks, Előd [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-April/021949.ht… [2] http://paste.openstack.org/show/804953/ [3] http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022173.html [4] http://paste.openstack.org/show/805404/

2 2

[Interop] new meetup pointer
by Kanevsky, Arkady 21 May '21

21 May '21

Team, The meetings will be held going forward at https://meetpad.opendev.org/interop at 4pm UTC every Friday Convert time to your timezone: https://mytime.io/16pm/UTC Thanks, Arkady Kanevsky, Ph.D. SP Chief Technologist & DE Dell Technologies office of CTO Dell Inc. One Dell Way, MS PS2-91 Round Rock, TX 78682, USA Phone: 512 7204955

1 0

[Interop] Next 2 meetings on May 28 and June 4 are CANCELLED
by Kanevsky, Arkady 21 May '21

21 May '21

Arkady Kanevsky, Ph.D. SP Chief Technologist & DE Dell Technologies office of CTO Dell Inc. One Dell Way, MS PS2-91 Round Rock, TX 78682, USA Phone: 512 7204955

1 0

[all] OpenDev Collaboratory IRC services
by Jeremy Stanley 21 May '21

21 May '21

I know lots of people are discussing the recent Freenode IRC upheaval and what it means for their projects. On behalf of the OpenDev sysadmins I've started a thread on the service-discuss(a)lists.opendev.org mailing list to get feedback from communities currently utilizing the OpenDev Collaboratory's IRC bot services in their channels on Freenode (meeting minutes/logging, Gerrit change events, OpenDev service status information, channel operator assistance): http://lists.opendev.org/pipermail/service-discuss/2021-May/000236.html Please follow up there with your thoughts, to assist in our decision making, so we can take the needs of your project into account. Thanks! -- Jeremy Stanley

1 0

[release] Release countdown for week R-19, May 24 - May 28
by Herve Beraud 21 May '21

21 May '21

Development Focus ----------------- The Xena-1 milestone is next week, on 27 May, 2021! Project team plans for the Xena cycle should now be solidified. General Information ------------------- Libraries need to be released at least once per milestone period. Next week, the release team will propose releases for any library which had changes but has not been otherwise released since the Wallaby release. PTL's or release liaisons, please watch for these and give a +1 to acknowledge them. If there is some reason to hold off on a release, let us know that as well, by posting a -1. If we do not hear anything at all by the end of the week, we will assume things are OK to proceed. NB: If one of your libraries is still releasing 0.x versions, start thinking about when it will be appropriate to do a 1.0 version. The version number does signal the state, real or perceived, of the library, so we strongly encourage going to a full major version once things are in a good and usable state. Upcoming Deadlines & Dates -------------------------- Xena-1 milestone: 27 May, 2021 -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 0

[nova] Weekly meeting moved to Tuesday 16:00 UTC
by Balazs Gibizer 21 May '21

21 May '21

Hi, Based on the poll[1] and the discussion on the weekly meeting[2] we agreed to move the nova weekly IRC meeting to Tuesday 16:00 UTC from now on. Cheers, gibi [1]http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022440.ht… [2]http://eavesdrop.openstack.org/meetings/nova/2021/nova.2021-05-20-16.00.l…

1 0

unable to get spice console
by cloud learner 21 May '21

21 May '21

Dear all, Unable to get spice console on victoria single node. Kindly help. Thanks

1 0