May 2021 - openstack-discuss - lists.openstack.org

Live migration fails
by Szabo, Istvan (Agoda) 07 Aug '24

07 Aug '24

Hi, I have couple of compute nodes where the live migration fails with existing vms. When I quickly spawn a vm and try live migration it works so I assume shouldn't be a big problem with the compute node. However I have many existing vms where it fails with a servername not found. /var/log/nova/nova-conductor.log:2021-04-21 14:47:12.605 227612 ERROR nova.conductor.tasks.migrate [req-f4067a26-a233-4673-8c07-9a8a290980b0 dce35e6eceea4312bb0baa0510cef363 ca7e35079f4440c78bd9870724b9638b - default default] [instance: 1517a2ac-3b51-4d8d-80b3-89a5614d1ae0] Unable to find record for source node servername on servername: ComputeHostNotFound: Compute host servername could not be found. /var/log/nova/nova-conductor.log:2021-04-21 14:47:12.605 227612 WARNING nova.scheduler.utils [req-f4067a26-a233-4673-8c07-9a8a290980b0 dce35e6eceea4312bb0baa0510cef363 ca7e35079f4440c78bd9870724b9638b - default default] Failed to compute_task_migrate_server: Compute host servername could not be found.: ComputeHostNotFound: Compute host servername could not be found. /var/log/nova/nova-conductor.log:2021-04-21 14:47:12.605 227612 WARNING nova.scheduler.utils [req-f4067a26-a233-4673-8c07-9a8a290980b0 dce35e6eceea4312bb0baa0510cef363 ca7e35079f4440c78bd9870724b9638b - default default] [instance: 1517a2ac-3b51-4d8d-80b3-89a5614d1ae0] Setting instance to ACTIVE state.: ComputeHostNotFound: Compute host servername could not be found. /var/log/nova/nova-conductor.log:2021-04-21 14:47:12.672 227612 ERROR oslo_messaging.rpc.server [req-f4067a26-a233-4673-8c07-9a8a290980b0 dce35e6eceea4312bb0baa0510cef363 ca7e35079f4440c78bd9870724b9638b - default default] Exception during message handling: ComputeHostNotFound: Compute host am-osfecn-4025 Tried with this command: nova live-migration --block-migrate id. Any idea? Thank you. ________________________________ This message is confidential and is for the sole use of the intended recipient(s). It may also be privileged or otherwise protected by copyright or other legal rules. If you have received it by mistake please let us know by reply email and delete it from your system. It is prohibited to copy this message or disclose its content to anyone. Any confidentiality or privilege is not waived or lost by any mistaken delivery or unauthorized disclosure of the message. All messages sent to and from Agoda may be monitored to ensure compliance with company policies, to protect the company's interests and to remove potential malware. Electronic messages may be intercepted, amended, lost or deleted, or contain viruses.

5 16

[all] Dynamic Zuul results table in Gerrit 3
by Radosław Piliszek 04 Aug '22

04 Aug '22

Hello Fellow OpenStack and OpenDev Folks! TL;DR click on [3] and enjoy. I am starting this thread to not hijack the discussion happening on [1]. First of all, I would like to thank gibi (Balazs Gibizer) for hacking a way to get the place to render the table in the first place (pun intended). I have been a long-time-now user of [2]. I have improved and customised it for myself but never really got to share back the changes I made. The new Gerrit obviously broke the whole script so it was of no use to share at that particular state. However, inspired by gibi's work, I decided to finally sit down and fix it to work with Gerrit 3 and here it comes: [3]. Works well on Chrome with Tampermonkey. Not tested others. I hope you will enjoy this little helper (I do). I know the script looks super fugly but it generally boils down to a mix of styles of 3 people and Gerrit having funky UI rendering. Finally, I'd also like to thank hrw (Marcin Juszkiewicz) for linking me to the original Michel's script in 2019. [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-November/019051… [2] https://opendev.org/x/coats/src/commit/444c95738677593dcfed0cfd9667d4c4f0d5… [3] https://gist.github.com/yoctozepto/7ea1271c299d143388b7c1b1802ee75e Kind regards, -yoctozepto

5 7

Nova not updating to new size of an extended in-use / attached cinder volume (Ceph RBD) to guest
by Christian Rohmann 28 Jun '22

28 Jun '22

Hello Openstack-Discuss, after some digging I found out that cinder learned to resize attached (in-use) volumes quite a while ago with the introduction of the initial "extend 'in-use' volume" feature: https://review.opendev.org/c/openstack/cinder/+/454287/ The support was then extended to also cover Ceph RBD backed volumes with: https://review.opendev.org/c/openstack/nova/+/613039/ Since this is only about the cinder part, I was wondering if nova would ever find out and would actively rescan the device / volume and quintessentially present an increased new size to the guest. Apparently this is where a certain volume-extended event comes into play: https://review.opendev.org/c/openstack/nova/+/454322/ that is to be emitted by cinder when a volume had been extened. I then went head and tried this with the openstack cli (as Horizon does not seem to support / offer to resize in-use volumes. I run Openstack Train with Ceph RBD as storage. First I ran into an issue with the openstack cli (https://bugs.launchpad.net/cinder/+bug/1871759/comments/2 <https://bugs.launchpad.net/cinder/+bug/1871759/comments/2>) but using cinder extend $volumeid $newsize I was able to resize in-use volumes just fine. The only thing missing was the propagation to the guest. I played around with SCSI rescans, but that did not work, reboots also failed to do anyting in this regards. Stopping and starting the VM did work, but why having the capability to online-resize an attached volume when not being able to resize the guest volume as well? Apparently there seems to be an old and somewhat similar observation / bug with https://bugs.launchpad.net/nova/+bug/1369465 So I was simply wondering if this is expected to be working? Are there any special settings / options I need to set to enable this feature? Thanks and with kind regards Christian

4 9

[nova][dev] Revisiting qemu emulation where guest arch != host arch
by Apsey, Christopher 05 Jan '22

05 Jan '22

All, A few years ago I asked a question[1] about why nova, when given a hw_architecture property from glance for an image, would not end up using the correct qemu-system-xx binary when starting the guest process on a compute node if that compute nodes architecture did not match the proposed guest architecture. As an example, if we had all x86 hosts, but wanted to run an emulated ppc guest, we should be able to do that given that at least one compute node had qemu-system-ppc already installed and libvirt was successfully reporting that as a supported architecture to nova. It seemed like a heavy lift at the time, so it was put on the back burner. I am now in a position to fund a contract developer to make this happen, so the question is: would this be a useful blueprint that would potentially be accepted? Most of the time when people want to run an emulated guest they would just nest it inside of an already running guest of the native architecture, but that severely limits observability and the task of managing any more than a handful of instances in this manner quickly becomes a tangled nightmare of networking, etc. I see real benefit in allowing this scenario to run natively so all of the tooling that exists for fleet management 'just works'. This would also be a significant differentiator for OpenStack as a whole. Thoughts? [1] http://lists.openstack.org/pipermail/openstack-operators/2018-August/015653… Chris Apsey Director | Georgia Cyber Range GEORGIA CYBER CENTER 100 Grace Hopper Lane | Augusta, Georgia | 30901 https://www.gacybercenter.org

2 2

[docs] Double headings on every page
by Peter Matulis 04 Nov '21

04 Nov '21

Hi, I'm hitting an oddity in one of my projects where the titles of all pages show up twice. Example: https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/wall… Source file is here: https://opendev.org/openstack/charm-deployment-guide/src/branch/master/depl… Does anyone see what can be causing this? It appears to happen only for the current stable release ('wallaby') and 'latest'. Thanks, Peter

5 6

Help with eventlet 0.26.1 and dnspython >= 2
by Thomas Goirand 04 Oct '21

04 Oct '21

Hi, As you may know, eventlet is incompatible with dnspython >= 2.0.0.0rc1. See [1] for the details. However, Debian unstable has 2.0.0. Would there be some good soul willing to help me fix this situation? I would need a patch to fix this, but I'm really not sure how to start. Cheers, Thomas Goirand (zigo)

8 15

[all][tc][goals] Project Specific PTL and Contributor Documentation: Week R-20 Update
by Ghanshyam Mann 17 Sep '21

17 Sep '21

Hello Everyone, As you know, we did not select any community-wide goal for Xena cycle and in PTG, TC decided to spend more time on the previous cycle pending community-wide goal work[1] One of the previous cycle (Ussuri) goals is 'Project Specific PTL and Contributor Documentation' which still not completed by many projects. - https://governance.openstack.org/tc/goals/selected/ussuri/project-ptl-and-c… I am starting the work to finish this goal which is pretty straight forwards and sending the updates in this ML thread. Please review the patches and merge them or push the patches for your project's repo if not yet done. Gerrit Topic: https://review.opendev.org/q/topic:%22project-ptl-and-contrib-docs%22+(stat… Tracking: https://storyboard.openstack.org/#!/story/2007236 Progress Summary: =============== * Projects completed: 32 * Projects for which patches are up and required to merge those: 10 * Projects for which patches are not yet up: 12 [1] https://etherpad.opendev.org/p/tc-xena-tracker (Item#2) -gmann

2 2

[all]Introduction to venus which is the project of log management and has been contributed to the OpenStack community
by Liye Pang(逄立业) 10 Sep '21

10 Sep '21

Hello everyone, after feedback from a large number of operations and maintenance personnel in InCloud OpenStack, we developed the log management project “Venus” for the OpenStack projects and that has contributed to the OpenStack community. The following is an introduction to “Venus”. If there is interest in the community, we are interested in proposing it to become an official OpenStack project in the future. Background In the day-to-day operation and maintenance of large-scale cloud platform, the following problems are encountered： l Time-consuming for log querying while the server increasing to thousands. l Difficult to retrieve logs, since there are many modules in the platform, e.g. systems service, compute, storage, network and other platform services. l The large amount and dispersion of log make faults are difficult to be discovered. l Because of distributed and interaction between components of the cloud platform, and scattered logs between components, it will take more time to locate problems. About Venus According to the key requirements of OpenStack in log storage, retrieval, analysis and so on, we introduced Venus project, a unified log management module. This module can provide a one-stop solution to log collection, cleaning, indexing, analysis, alarm, visualization, report generation and other needs, which involves helping operator or maintainer to quickly solve retrieve problems, grasp the operational health of the platform, and improve the management capabilities of the cloud platform. Additionally, this module plans to use machine learning algorithms to quickly locate IT failures and root causes, and improve operation and maintenance efficiency. Application scenario Venus played a key role in the following scenarios： l Retrieval: Provide a simple and easy-to-use way to retrieve all log and the context. l Analysis: Realize log association, field value statistics, and provide multi-scene and multi-dimensional visual analysis reports. l Alerts：Convert retrieval into active alerts to realize the error finding in massive logs. l Issue location: Establish a chain relationship and knowledge graphs to quickly locate problems. Overall structure The architecture of log management system based on Venus and elastic search is as follows: Diagram 0: Architecture of Venus venus_api: API module，provide API、rest-api service. venus_manager: Internal timing task module to realize the core functions of the log system. Current progress The current progress of the Venus project is as follows: l Collection：Develop fluentd collection tasks based on collectd to read, filter, format and send plug-ins for OpenStack, operating systems, and platform services, etc. l Index：Dealing with multi-dimensional index data in elasticsearch, and provide more concise and comprehensive authentication interface to return query results. l Analysis：Analyzing and display the related module errors, Mariadb connection errors, and Rabbitmq connection errors. l Alerts：Develop alarm task code to set threshold for the number of error logs of different modules at different times, and provides alarm services and notification services. l Location：Develop the call chain analysis function based on global_requested series, which can show the execution sequence, time and error information, etc., and provide the export operation. l Management：Develop configuration management functions in the log system, such as alarm threshold setting, timing task management, and log saving time setting, etc. Application examples Two examples of Venus application scenarios are as follows. 1. The virtual machine creation operation was performed on the cloud platform and it was found that the virtual machine was not created successfully. First, we can find the request id of the operation and jump to the virtual machine creation call chain page. Then, we can query the calling process, view and download the details of the log of the call. 2. In the cloud platform, the error log of each module can be converted into alarms to remind the users. Further, we can retrieve the details of the error log and error log statistics. Next step The next step of the Venus project is as follows: * Collection：In addition to fluent, other collection plugins such as logstash will be integrated. * Analysis: Explore more operation and maintenance scenarios, and conduct statistical analysis and alarm on key data. * display: The configuration, analysis and alarm of Venus will be integrated into horizon in the form of plugin. * location: Form clustering log and construct knowledge map, and integrate algorithm class library to locate the root cause of the fault. Venus Project Registry Venus library: https://opendev.org/inspur/venus You can grab the source code using the following git command: git clone https://opendev.org/inspur/venus.git Venus Demo Youtu.be: <https://youtu.be/mE2MoEx3awM> https://youtu.be/mE2MoEx3awM

7 15

[interop][cinder] review of next.json (part 2)
by Brian Rosmaita 09 Aug '21

09 Aug '21

Hello Interop WG, The Cinder team completed its discussion of what capabilities should be added as advisory in next.json at yesterday's weekly cinder meeting [0]. The tldr; is that we don't have anything to propose for inclusion in next.json at the present time. The team does have some general questions that would help us determine the suitability of some proposed capabilities. We'd like to invite someone from the Interop WG to the cinder xena R-9 virtual midcycle (Wednesday 4 August 2021, 1400-1600 UTC) so we can discuss this "live". So if someone could put 1400 UTC 4 August on their schedule for a 20 minute discussion, that would be very helpful. cheers, brian [0] http://eavesdrop.openstack.org/meetings/cinder/2021/cinder.2021-05-12-14.00…

3 8

placement service issue (placement-status upgrade check failure)
by Deepak Mohanty 12 Jul '21

12 Jul '21

I need your help with installation of placement service on Ubuntu 20.04. I have followed the steps in: https://docs.openstack.org/placement/wallaby/install/install-ubuntu.html I am facing the following issue when I try to verify the installation: $ placement-status upgrade check Error: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/oslo_upgradecheck/upgradecheck.py", line 196, in run return conf.command.action_fn() File "/usr/lib/python3/dist-packages/oslo_upgradecheck/upgradecheck.py", line 104, in check result = func_name(self, **kwargs) File "/usr/lib/python3/dist-packages/oslo_upgradecheck/common_checks.py", line 41, in check_policy_json policy_path = conf.find_file(conf.oslo_policy.policy_file) File "/usr/lib/python3/dist-packages/oslo_config/cfg.py", line 2543, in find_file raise NotInitializedError() oslo_config.cfg.NotInitializedError: call expression on parser has not been invoked I did a bit of debugging and found that the policy file is: policy.json. I could not find any policy.json on my machine. I created an empty policy.json at: /etc/placement/policy.json (user and group = placement). That too did not work. I have followed the steps in the install guide twice, deleting the placement database and other resources and recreating them. I continue to see the same issue. Thank you for your time.

5 6

[all][infra][qa] Retiring Logstash, Elasticsearch, subunit2sql, and Health
by Clark Boylan 09 Jul '21

09 Jul '21

Hello everyone, Xenial has recently reached the end of its life. Our logstash+kibana+elasticsearch and subunit2sql+health data crunching services all run on Xenial. Even without the distro platform EOL concerns these services are growing old and haven't received the care they need to keep running reliably. Additionally these services represent a large portion of our resource consumption: * 6 x 16 vcpu + 60GB RAM + 1TB disk Elasticsearch servers * 20 x 4 vcpu + 4GB RAM logstash-worker servers * 1 x 2 vcpu + 2GB RAM logstash/kibana central server * 2 x 8 vcpu + 8GB RAM subunit-worker servers * 64GB RAM + 500GB disk subunit2sql trove db server * 1 x 4 vcpu + 4GB RAM health server To put things in perspective, they account for more than a quarter of our control plane servers, occupying over a third of our block storage and in excess of half the total memory footprint. The OpenDev/OpenStack Infra team(s) don't seem to have the time available currently to do the major lifting required to bring these services up to date. I would like to propose that we simply turn them off. All of these services operate off of public data that will not be going away (specifically job log content). If others are interested in taking this on they can hook into this data and run their own processing pipelines. I am sure not everyone will be happy with this proposal. I get it. I came up with the idea for the elasticsearch job log processing way back at the San Diego summit. I spent many many many hours since working to get it up and running and to keep it running. But pragmatism means that my efforts and the team's efforts are better spent elsewhere. I am happy to hear feedback on this. Thank you for your time. Clark

10 13

[Octavia dashboard] Impossible to fill the subnet field when creating a load balancer
by Taltavull Jean-Francois 09 Jul '21

09 Jul '21

Hi All, On my OSA Victoria deployment (on Ubuntu 20.04), the "Create Load Balancer" form does not allow me to fill the mandatory "subnet" field and therefore I can't create a load balancer with Horizon. On the other hand, Octavia works fine and I can create load balancers with the CLI, Terraform, etc. Has one of you already faced such a situation ? Best regards, Jean-François

3 6

[nova] spec review day
by Balazs Gibizer 05 Jul '21

05 Jul '21

Hi, During the today's meeting it came up that we should have a spec review day around M1 (and later one more before M2). As M1 is 27th of May, I propose to do a spec review day on 25th of May, which is a Tuesday. Let me know if the timing does not good for you. The rules are the usual. Let's use this day to focus on open specs, trying to reach agreement on as many thing as possible with close cooperation during the day. Cheers, gibi

1 3

[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

[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

Customization of nova-scheduler
by Levon Melikbekjan 16 Jun '21

16 Jun '21

Hello Openstack team, is it possible to customize the nova-scheduler via Python? If yes, how? Best regards Levon

8 16

[all] CRITICAL: Upcoming changes to the OpenStack Community IRC this weekend
by Ghanshyam Mann 16 Jun '21

16 Jun '21

Greetings contributors & community members! With recent events, the Technical Committee held an emergency meeting today (Wednesday, May 26th, 2021) regarding Freenode IRC and what our decision would be [1]. Earlier in the week, the consensus amongst the TC was to gather more information from the individual projects, and make a decision from there[2]. With #rdo, #ubuntu, and #wikipedia having been hijacked, the consensus amongst the TC and the community members who were able to attend the meeting was to move away from Freenode as soon as possible. The TC agreed that this move away from Freenode needs to be a community-wide move to the same, new IRC network for all projects to avoid splintering of the community. As has been long-planned in the event of a contingency, we will be moving to OFTC. We recognize this is a contentious topic, and ultimately we seek to ensure community continuity before evolution to something beyond IRC, as many have expressed interest in doing via Mailing List discussions. At this point, we had to make a decision to solve the immediate problem in the simplest and most expedient way possible, so this is that announcement. We welcome continued discussion about future alternatives on the other threads. With this in mind, we suggest the following steps. Everyone: ======= 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 [3][4] 3. Be *prepared* to join your channels on OFTC[4]. The OpenStack community channels have already been registered on OFTC and await you. 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. Projects/Project Leaders: ==================== 1. 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. 2. Continue to hold project meetings on Freenode until the bots are enabled on OFTC. 3. Update project wikis/documentation with the new IRC network information. We ask that you consider referring to the central contributor guide[5]. 4. 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. 5. Please avoid discussing the move to OFTC in Freenode channels as this may also trigger a takeover of the channel. We are working on getting our bots over to OFTC, and they will be moved over the weekend. Starting Monday May 31, the bots will be on OFTC. Communication regarding this migration will take place on OFTC[4] in #openstack-dev, and we're working on updating the contributor guide[5] to reflect this migration. Sincerely, The OpenStack TC and community leaders who came together to agree on a path forward. [1]: https://etherpad.opendev.org/p/openstack-irc [2]: https://etherpad.opendev.org/p/feedback-on-freenode [3]: https://www.oftc.net/Services/#register-your-account [4]: https://www.oftc.net/ [5]: https://docs.openstack.org/contributors/common/irc.html

3 6

[all][stable] Ocata - End of Life
by Előd Illés 09 Jun '21

09 Jun '21

Hi, Sorry, this will be long :) as there are 3 topics around old stable branches and 'End of Life'. 1. Deletion of ocata-eol tagged branches With the introduction of Extended Maintenance process [1][2] some cycles ago, the 'End of Life' (EOL) process also changed: * branches were no longer EOL tagged and "mass-deleted" at the end of maintenance phase * EOL'ing became a project decision * if a project decides to cease maintenance of a branch that is in Extended Maintenance, then they can tag their branch with $series-eol However, the EOL-tagging process was not automated or redefined process-wise, so that meant the branches that were tagged as EOL were not deleted. Now (after some changing in tooling) Release Management team finally will start to delete EOL-tagged branches. In this mail I'm sending a *WARNING* to consumers of old stable branches, especially *ocata*, as we will start deleting the *ocata-eol* tagged branches in a *week*. (And also newer *-eol branches later on) 2. Ocata branch Beyond the 1st topic we must clarify the future of Ocata stable branch in general: tempest jobs became broken about ~ a year ago. That means that projects had two ways forward: a. drop tempest testing to unblock gate b. simply don't support ocata branch anymore As far as I see the latter one happened and stable/ocata became unmaintained probably for every projects. So my questions are regarding this: * Is any project still using/maintaining their stable/ocata branch? * If not: can Release Team initiate a mass-EOL-tagging of stable/ocata? 3. The 'next' old stable branches Some projects still support their Pike, Queens and Rocky branches. These branches use Xenial and py2.7 and both are out of support. This results broken gates time to time. Especially nowadays. These issues suggest that these branches are closer and closer to being unmaintained. So I call the attention of interested parties, who are for example still consuming these stable branches and using them downstream to put effort on maintaining the branches and their CI/gates. It is a good practice for stable maintainers to check if there are failures in their projects' periodic-stable jobs [3], as those are good indicators of the health of their stable branches. And if there are, then try to fix it as soon as possible. [1] https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.… [2] https://docs.openstack.org/project-team-guide/stable-branches.html#maintena… [3] http://lists.openstack.org/pipermail/openstack-stable-maint/2021-April/date… Thanks, Előd

1 2

[Neutron] sriov network setup for victoria - clarification needed
by forums＠mossakowski.ch 09 Jun '21

09 Jun '21

Hello, I have two victoria environments: 1) a working one, standard setup with separate dedicated interface for sriov (pt0 and pt1) 2) a broken one, where I'm trying to reuse one of already used interfaces (ens2f0 or ens2f1) for sriov. ens2f0 is used for several VLANs (mgmt and storage) and ens2f1 is a neutron external interface which I bridged for VLAN tenant networks. On both I have enabled 63 VFs, it's a standard intetl 10Gb x540 adapter. On broken environment, when I'm trying to boot a VM with sriov port that I created before, I see this error shown on below gist: https://gist.github.com/moss2k13/8e6272cbe7748b2c5210fab291360e0b I'm investigating this for couple days now but I'm out of ideas so I'd like to ask for your support. Is this possible to achieve what I'm trying to do on 2nd environment? To use PF as normal interface and use its VFs for sriov-agent at the same time? Regards, Piotr Mossakowski

3 5

[neutron][interop][refstack] New tests and capabilities to track in interop
by Martin Kopec 07 Jun '21

07 Jun '21

Hi everyone, I would like to further discuss the topics we covered with the neutron team during the PTG [1]. * adding address_group API capability It's tested by tests in neutron-tempest-plugin. First question is if tests which are not directly in tempest can be a part of a non-add-on marketing program? It's possible to move them to tempest though, by the time we do so, could they be marked as advisory? * Shall we include QoS tempest tests since we don't know what share of vendors enable QoS? Could it be an add-on? These tests are also in neutron-tempest-plugin, I assume we're talking about neutron_tempest_plugin.api.test_qos tests. If we want to include these tests, which program should they belong to? Do we wanna create a new one? [1] https://etherpad.opendev.org/p/neutron-xena-ptg Thanks, -- Martin Kopec Senior Software Quality Engineer Red Hat EMEA

4 8

Fwd: [ironic] IPA image does not want to boot with UEFI
by Vuk Gojnic 04 Jun '21

04 Jun '21

Hi Julia, thanks for the response. I have now verified that the server has Secure Boot set to Disabled. It happens on all our HPE Gen10 and Gen10+ servers that are booting with UEFI in the same configuration (Secure Boot Disabled). Unsigned initrd from ubuntu for example works with Kernel from IPA: I have also updated firmware of the server to the latest version, but it is still the same. I am going to try to drill deeper in IPA builder code and IPA initrd which seems not to go well with UEFI boot mode. I am grateful for any hint. Bests, Vuk

3 7

[Manila ] Upcoming Bug Squash starting June 7th through June 11th 2021
by Vida Haririan 03 Jun '21

03 Jun '21

Hi everyone, As discussed, a new Bug Squash event is around the corner! The event will be held from 7th to 11th June, 2021, providing an extended contribution window. There will be a synchronous call held simultaneously on IRC, Thursday June 10th, 2021 at 15:00 UTC and we will use this Jitsi bridge [1]. A list of selected bugs will be shared here [2]. Please feel free to add any additional bugs you would like to address during the event. Thanks for your participation in advance. Vida [1] https://meetpad.opendev.org/ManilaX-ReleaseBugSquash [2] https://ethercalc.openstack.org/i3vwocrkk776 <https://meetpad.opendev.org/ManilaX-ReleaseBugSquash> <https://meetpad.opendev.org/ManilaX-ReleaseBugSquash>

2 1

[kolla] Reorganization of kolla-ansible documentation
by Klemen Pogacnik 03 Jun '21

03 Jun '21

Hello! I promised to prepare my view as a user of kolla-ansible on its documentation. In my opinion the division between admin guides and user guides is artificial, as the user of kolla-ansible is actually the cloud administrator. Maybe it would be good to think about reorganizing the structure of documentation. Many good chapters are already written, they only have to be positioned in the right place to be found more easily. So here is my proposal of kolla-ansible doc's structure: 1. Introduction 1.1. mission 1.2. benefits 1.3. support matrix 2. Architecture 2.1. basic architecture 2.2. HA architecture 2.3. network architecture 2.4. storage architecture 3. Workflows 3.1. preparing the surroundings (networking, docker registry, ...) 3.2. preparing servers (packages installation) 3.3. configuration (of kolla-ansible and description of basic logic for configuration of Openstack modules) 3.4. 1st day procedures (bootstrap, deploy, destroy) 3.5. 2nd day procedures (reconfigure, upgrade, add, remove nodes ...) 3.6. multiple regions 3.7. multiple cloud 3.8. security 3.9. troubleshooting (how to check, if cloud works, what to do, if it doesn't) 4. Use Cases 4.1. all-in-one 4.2. basic vm multinode 4.3. some production use cases 5. Reference guide Mostly the same structure as already is. Except it would be desirable that description of each module has: - purpose of the module - configuration of the module - how to use it with links to module docs - basic troubleshooting 6. Contributor guide The documentation also needs figures, pictures, diagrams to be more understandable. So at least in the first chapters some of them shall be added. I'm also thinking about convergence of documentation of kayobe, kolla and kolla-ansible projects. It's true that there's no strict connection between kayobe and other two and kolla containers can be used without kolla-ansible playbooks. But the real benefit the user can get is to use all three projects together. But let's leave that for the second phase. So please comment on this proposal. Do you think it's going in the right direction? If yes, I can refine it.

2 2

[TripleO] tripleo repos going Extended Maintenance stable/train OK? (not yet IMO)
by Marios Andreou 03 Jun '21

03 Jun '21

Hello TripleO o/ per [1] and the proposal at [2] the stable/train branch for all tripleo repos [3] is going to transition to extended maintenance [4]. Once [2] merges, we can still merge things to stable/train but it means we can no longer make official openstack tagged releases for stable/train. TripleO is a trailing project so if we want to hold on this for a while longer I think that is OK and that would also be my personal preference. >From a quick check just now e.g. tripleo-heat-templates @ [5] and at current time there are 87 commits since last September which isn't a tiny amount. So I don't think TripleO is ready to declare stable/train as extended maintenance, but perhaps I am wrong, what do you think? Please comment here or directly at [2] if you prefer regards, marios [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022287.html [2] https://review.opendev.org/c/openstack/releases/+/790778/2#message-e981f749… [3] https://releases.openstack.org/teams/tripleo.html#train [4] https://docs.openstack.org/project-team-guide/stable-branches.html#maintena… [5] https://github.com/openstack/tripleo-heat-templates/compare/11.5.0...stable…

2 3

[kolla] [kolla-ansible] fluentd doesn't forward OpenStack logs to Elasticsearch
by Bernd Bausch 03 Jun '21

03 Jun '21

I might have found a bug in Kolla-Ansible (Victoria version) but don't know where to file it. This is about central logging. In my installation, none of the interesting logs (Nova, Cinder, Neutron...) are sent to Elasticsearch. I confirmed that using tcpdump. I found that fluentd's config file /etc/kolla/fluentd/td-agent.conf tags these logs with "kolla.*". But later in the file, one finds filters like this: # Included from conf/filter/01-rewrite-0.14.conf.j2: <match kolla.var.log.kolla.*.*.log> @type rewrite_tag_filter capitalize_regex_backreference yes ... <rule> key programname pattern ^(nova-api|nova-compute|nova-compute-ironic|nova-conductor|nova-manage|nova-novncproxy|nova-scheduler|nova-placement-api|placement-api|privsep-helper)$ tag openstack_python </rule> If I understand this right, this basically re-tags all nova logs with "openstack_python". The same config file has an output rule at the very end. I think the intention is to make this a catch-all rule (or "match anything else"): # Included from conf/output/01-es.conf.j2: <match *.**> @type copy <store> @type elasticsearch host 192.168.122.209 port 9200 scheme http etc. Unfortunately, the /openstack_python/ tag doesn't match /*.**/, since it contains no dot. I fixed this with <match **>. Now I receive all logs, but I am not sure if this is the right way to fix it. The error, if it is one, is in https://opendev.org/openstack/kolla-ansible/src/branch/master/ansible/roles…. If you want me to file a bug, please let me know how. Bernd.

2 3

[largescale-sig] Next meeting: June 2, 15utc
by Thierry Carrez 03 Jun '21

03 Jun '21

Hi everyone, Our next Large Scale SIG meeting will be this Wednesday in #openstack-meeting-3 on OFTC IRC, at 15UTC. You can doublecheck how it translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20210602T15 Note that we changed IRC networks, you should now connect to OFTC[1] rather than Freenode servers. [1] https://www.oftc.net/ A number of topics have already been added to the agenda, including discussing our next OpenInfra.Live show. Feel free to add other topics to our agenda at: https://etherpad.openstack.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

1 1

Re: [Nova] Meeting time poll
by Sam Su (苏正伟) 02 Jun '21

02 Jun '21

0 *H÷ 010 +0 *H÷ $>Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hi, Nova team£º There are many asian developers for Openstack community. I found the current IRC time of Nova is not friendly to them, especially to East Asian. If they can take part in the IRC meeting, the Nova may have more developers. Of cource, Central Europe and NA West Coast is firstly considerable. If the team could schedule the meeting once per month, time suitable for asians, more people would participate in the meeting discussion. -----ÓÊŒþÔŒþ----- ·¢ŒþÈË: Artom Lifshitz [mailto:alifshit@redhat.com] ·¢ËÍÊ±Œä: 2021Äê5ÔÂ14ÈÕ 1:07 ÊÕŒþÈË: OpenStack Discuss <openstack-discuss(a)lists.openstack.org> Ö÷Ìâ: [Nova] Meeting time poll hem Hey all, As discussed during the IRC meeting today, the Red Hat Nova team would like to know if it's possible to shift the IRC meeting to a different day and/or time. This would facilitate our own internal calls, but I want to be very clear that we'll structure our internal calls around upstream, not the other way around. So please do not perceive any pressure to change, this is just a question :) To help us figure this out, I've created a Doodle poll [1]. I believe the regular attendees of the IRC meeting are spread between Central Europe and NA West Coast, so I've tried to list times that kinda make sense in both of those places, with a couple of hours on each side as a safety margin. Please vote on when you'd like the Nova IRC meeting to take place. Ignore the actual dates (like May 10), the important bits are the days of the week (Monday, Tuesday, etc). This is obviously a recurring meeting, something that Doodle doesn't seem to understand. I've not included Mondays and Wednesdays in the list of possibilities, as they would not work for Red Hat Nova. You can also vote to keep the status quo :) The times are listed in UTC, like the current meeting time, so unfortunately you have to be mindful of the effects of daylight savings time :( Thanks in advance! [1] https://doodle.com/poll/45ptnyn85iuw7pxz E0¢0 cÊR,S8vMÂä:ÐVê0 *H÷ 0Y10 &ò,dcom10 &ò,dlangchao10 &ò,dhome10U INSPUR-CA0 170109092830Z 270109093829Z0Y10 &ò,dcom10 &ò,dlangchao10 &ò,dhome10U INSPUR-CA0"0 *H÷ 0 «ä5ïc$Œ©æ'µ¯Þ6>úUKÛdÔ²Áe9Î~{BîÒLgD÷*wvVÊŠ/DýUj_xá\m/ óž=kÐ·éGÙœQ€ýx~Wùgk ÛÜøãÔ7É6NçÏ*?n°Ê²mhùè{Ã¯ôÌÆ 7üF-Î<@ÃÓÍ¬WçÅyåLZrF 6~føÈ×T~$0d¡ýL|zšøW=ötÚ%ýq,¥Ã~Ÿ"ÀýŸÑö2T,QÕÔ,dºÂÅ^§ÈôïåJ)ëVvp Ó£f0d0 +7CA0U0Uÿ0ÿ0U^YŠŽLX`Nöµ¥9Š2Á5j0 +70 *H÷ JÄß»íu+¶Wù«áMÈL¯i8y1ü'áRæL€uK·u`K=9@žnA0×ŠqÓÂéÑVxÓf Ý»Åü<ÔUrpŠz¶Ï7vèÑ¥`oñ÷7Ä°ù¬?Þ`PMKŠžp»9 ìcwg UhÁþuu|6~ŒÁècŸŸkl!êkMÔS3B±Æù¯:«ççA^5"ÆX¯ èË&á)PNäŒØkäA-7fGR,¿äŸœÞ}ÖfeKéK¥[ H¢WžÓ{oÊù ,F_5°ÎZË>u00 ~a"Ã'pMÊsa"0 *H÷ 0Y10 &ò,dcom10 &ò,dlangchao10 &ò,dhome10U INSPUR-CA0 190606032704Z 240604032704Z010 &ò,dcom10 &ò,dlangchao10 &ò,dhome10Uæµªæœ®ä¿¡æ¯10U èæ£äŒ1$0" *H÷ suzhengwei@inspur.com0"0 *H÷ 0 ÏþOªdbñ3S©ÁPf~°Š(ÒóÙéáœö»sÉÐ»¹w»#žŽý;Fqt$â MÓBß€]¡MhžR=IIPXHŠîÃ<F¶ÚI¥Ñ3Oåå£1 éêi²LÕŸ8 ·Ëì7NOH|µ<M³õÚá ±®åÙ@üì€® ·²)ŒYŸ'1~ðäHŠç«\Æ§è~\¬º}¥os:õàÕ48IM"ÌÀ÷Z\|pÉ'Âpl;ççµeŠÈÜlªéYØw1¡~¡ðKäpåAøNšu!Ä}£00= +700.&+7ò©×z©=÷Ø\Jý&§Md\0)U%"0 ++ +7 0U 05 +7 (0&0 +0 +0 +7 0D *H÷ 7050*H÷ 0*H÷ 0+0 *H÷ 0UÉÈ¿ñY-ŸŒ°ÕŸf7Uv€0U#0^YŠŽLX`Nöµ¥9Š2Á5j0ÑUÉ0Æ0Ã À œºldap:///CN=INSPUR-CA,CN=JTCA2012,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=home,DC=langchao,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint0Ä+·0Ž0±+0€ldap:///CN=INSPUR-CA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=home,DC=langchao,DC=com?cACertificate?base?objectClass=certificationAuthority0GU@0> % +7 suzhengwei@inspur.comsuzhengwei@inspur.com0 *H÷ ÊÃæÖñâ5ð+Éý,¬°Ü3zþdŸšÒMÚ¹Úxæ¥¹ÛHBœTfBUâ_lfÓ:.#§mK"§ÈL¹ç[Ç¿5FezK>6yÎP®)iÑ65k\&\v"³ÓÃäzKÇ S]*ÊO)§RÅþdãÖñN2üGç#v&4.$¯U»±[*3'NZfºÒ%åsÓå<"ù9¹{§ÌçÛîf7¶ùãÖ² ÞÌ-ÚÃñêfP!ï$JÑG£Cor°\S×AEzÙkÈšÖóB¯Lá!Öñ100p0Y10 &ò,dcom10 &ò,dlangchao10 &ò,dhome10U INSPUR-CA~a"Ã'pMÊsa"0 + ø0 *H÷ 1 *H÷ 0 *H÷ 1 210514012326Z0# *H÷ 1ŸÂÕ¶T0DóüÑµ¶80 +71r0p0Y10 &ò,dcom10 &ò,dlangchao10 &ò,dhome10U INSPUR-CA~a"Ã'pMÊsa"0*H÷ 1r p0Y10 &ò,dcom10 &ò,dlangchao10 &ò,dhome10U INSPUR-CA~a"Ã'pMÊsa"0 *H÷ 100 `He*0 `He0 *H÷ 0 `He0*H÷ 0 *H÷ @0+0 `He0 `He0 `He0 *H÷ «ä-7X×òÍ O05xÍh6÷ŽÔ?îk6è{îI®pq¯¯øQì¬°âmª¿%m<<Uv«d\ígt?)ÁJçá3S©å íL£&Îžð,°& h{stuCÃKÈ5=ÒvéqjórÝ^ç€ 1ºéT£Õn·rÈ£g&:2Ø)=C'SW>XËÄ âá{ a9[l}a=QÂ}7žR"È¹²8Üij Ÿ& l£·;Ÿ¹ö÷a4ó8Hv×{\#ª0&II¹¡ëžP%O2®jª?Â,HçôF

2 5

[requirements][docs] sphinx and docutils major version update
by Matthew Thode 01 Jun '21

01 Jun '21

Looks like a major version update came along and broke things. I'd appreciate if some docs people could take a look at https://review.opendev.org/793022 Thanks, -- Matthew Thode

2 1

[docs] Request to clean up reviewers on openstack-doc-core and openstack-contributor-guide-core
by Julia Kreger 01 Jun '21

01 Jun '21

Greetings, I went to go hunt down a reviewer for the contributors guide this morning and found that at least one of the reviewers no longer works on OpenStack. In this case pkovar, but just glancing at the group lists, there appears to be others. If someone with appropriate privileges could update the group memberships to better reflect reality, it would be helpful to the rest of the community. Thanks! -Julia

5 5

Question regarding the production status of DB2 in Trove
by Bekir Fajkovic 31 May '21

31 May '21

Hello! One question regarding the development status of DB2 inside Trove. I see that DB2 is still in experimental phase, when could it be expected for that datastore type to get production ready status? Best Regards. Bekir Fajkovic Senior DBA Mobile: +46 70 019 48 47 www.citynetwork.eu | www.citycloud.com INNOVATION THROUGH OPEN IT INFRASTRUCTURE ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED

3 8

[sdk]: Block storage resource get volume created at time
by dmeng 31 May '21

31 May '21

Hello there, Hope this email finds you well. I have a question for getting the volume created at time using the openstacksdk block storage volume class. I found that the attribute volume.create_at is in a format like "2021-05-28T17:16:45.000000", and we don't know the timezone for it. Wondering if the openstack always uses the GMT? or anywhere we could set it to our pacific time? Thanks and have a great day! Catherine

1 0

[puppet] Moved #puppet-openstack from Freenode to OFTC
by Tobias Urdin 31 May '21

31 May '21

Hello Puppeters! Just a friendly reminder that we have moved #puppet-openstack from Freenode to OFTC. Best regards

1 0

[oslo] Weekly meeting moving to OFTC next week
by Herve Beraud 31 May '21

31 May '21

Hello, Just a friendly reminder to inform all the Osloers that OpenStack IRC has moved from freenode to OFTC during the past weekend. So henceforward our weekly team meeting will be at OFTC network, on the same channel (#openstack-oslo) as it was previously at Freenode. If anyone has yet to register on OFTC then kindly do so as soon as possible. Don't forget that meetings are now scheduled the first and the third Monday of each month [1]. So, see you there during our next meeting on Monday 03 June. [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-April/022124.ht… -- 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

[glance] Weekly meeting moving to OFTC from this week
by Abhishek Kekane 31 May '21

31 May '21

Hello Everyone, Everyone is aware that OpenStack IRC has moved from freenode to OFTC during the past weekend. So henceforward our weekly team meeting will be at OFTC network, on the same channel (#openstack-meeting) as it was previously at Freenode. If anyone has yet to register on OFTC then kindly do so as soon as possible. Thanks & Best Regards, Abhishek Kekane

1 0

[neutron] Meetings are moving to OFTC this week
by Slawek Kaplonski 31 May '21

31 May '21

Hi, OpenStack moved to the OFTC IRC channels already so starting this week our team meeting, CI meeting and drivers meeting will be at OFTC server, on same channels as it was previously at Freenode. -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[requirements][neutron][os-vif][octavia] pyroute2 and eventlet update breaking gate
by Matthew Thode 31 May '21

31 May '21

looks like more updates to bother you about. pyroute2 review is at https://review.opendev.org/793020 eventlet review is at https://review.opendev.org/793021 It looks like this is mainly impacting neutron related projects -- Matthew Thode

4 5

[nova] Next nova meeting will be already on OFTC
by Balazs Gibizer 31 May '21

31 May '21

Hi, The next weekly meeting on 1st of June will be held already on the OFTC IRC servers, in the #openstack-meeting-3 channel. Cheers, gibi

1 0

[neutron] Bug deputy report - week of May 24th
by Slawek Kaplonski 31 May '21

31 May '21

Hi, I was bug deputy last week. Here is my report regarding bugs from it: **critical** https://bugs.launchpad.net/neutron/+bug/1929518 - Functional db migration tests broken - assigned, patch proposed https://bugs.launchpad.net/neutron/+bug/1929633 - Mechanism driver 'ovn' failed in create_port_precommit: AttributeError: 'NoneType' object has no attribute 'chassis_exists' - Issue related to switch ovn to be default neutron's backend in devstack, in progress **high** https://bugs.launchpad.net/neutron/+bug/1929523 - Test tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_subnet_details is failing from time to time - Unassigned https://bugs.launchpad.net/neutron/+bug/1929832 - stable/ussuri py38 support for keepalived-state-change monitor - In progress https://bugs.launchpad.net/neutron/+bug/1930222 - "test_add_and_remove_metering_label_rule_src_and_dest_ip_only" failing in py39 , in progress **medium** https://bugs.launchpad.net/neutron/+bug/1929438 - Cannot provision flat network after reconfiguring physical bridges - assigned, patch already proposed https://bugs.launchpad.net/neutron/+bug/1929578 - Make OVN metadata agent OVNDB read-only - assigned, patch proposed https://bugs.launchpad.net/neutron/+bug/1929676 - API extensions not supported by e.g. OVN driver may still be on the list returned from neutron - assigned, patch proposed https://bugs.launchpad.net/neutron/+bug/1930195 - Bump os-ken to 2.0.0 - in progress **Low** https://bugs.launchpad.net/neutron/+bug/1929658 - [OVN] Enable OVN L3 router plugin support for filter-validation - assigned, fix proposed https://bugs.launchpad.net/neutron/+bug/1929821 - [dvr] misleading fip rule priority not found error message - unassigned https://bugs.launchpad.net/neutron/+bug/1929998 - VXLAN interface cannot source from lo with multiple IPs - assigned... **undecided** https://bugs.launchpad.net/neutron/+bug/1930096 - Missing static routes after neutron-l3-agent restart - waiting for some info... **RFE** https://bugs.launchpad.net/neutron/+bug/1930200 - [RFE] Add support for Node- Local virtual IP, -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[masakari] Tomorrow meeting will be on OFTC
by Radosław Piliszek 31 May '21

31 May '21

Dears, Please be informed that we, as OpenStack community, have migrated our IRC presence to OFTC. Hence, the Masakari meetings, starting with the tomorrow one, will be held on #openstack-masakari on OFTC. Please find OFTC connection info on http://www.oftc.net/ Kind regards, -yoctozepto

1 0

[release] Release countdown for week R-18, May 31 - Jun 04
by Herve Beraud 31 May '21

31 May '21

Development Focus ----------------- We are now past the Xena-1 milestone. Teams should now be focused on feature development! General Information ------------------- Our next milestone in this development cycle will be Xena-2, on 15 July, 2021. This milestone is when we freeze the list of deliverables that will be included in the Xena final release, so if you plan to introduce new deliverables in this release, please propose a change to add an empty deliverable file in the deliverables/xena directory of the openstack/releases repository. Now is also generally a good time to look at bugfixes that were introduced in the master branch that might make sense to be backported and released in a stable release. If you have any questions around the OpenStack release process, feel free to ask on this mailing-list or on the #openstack-release channel on IRC (at OFTC). Upcoming Deadlines & Dates -------------------------- Xena-2 Milestone: 15 July, 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

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

31 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 29 May '21

29 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 28 May '21

28 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 27 May '21

27 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 27 May '21

27 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 27 May '21

27 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 27 May '21

27 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 27 May '21

27 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 26 May '21

26 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 25 May '21

25 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 25 May '21

25 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 23 May '21

23 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

[mistral] glance image upload
by Arnaud Morin 21 May '21

21 May '21

Hey team, Is there any way to upload/download an image to/from glance using a mistral workflow? I am seeing the glance.images_upload and glance.images_data, but I cant figure out how it works, I was thinking that we could provide some sort of swift URL to download/upload from. Is there any example available somewhere or maybe it's not yet implemented? Thanks

3 2

[Senlin][Octavia] Health policy - LB_STATUS_POLLING detection mode
by Giacomo Lanciano 21 May '21

21 May '21

Hi folks, I'd like to know what is the status of making the LB_STATUS_POLLING detection mode available for the Senlin Health Policy [1]. According to the docs and this patch [2], the implementation of this feature is blocked by some issue on LBaaS/Octavia side, but I could not find any details on what this issue really is. As the docs state, it would be really useful to have this detection mode available, as it is much more reliable than the others at evaluating the status of an application. If I can be of any help, I would be willing to contribute. Thanks in advance. Kind regards. Giacomo [1] https://docs.openstack.org/senlin/latest/contributor/policies/health_v1.htm… [2] https://review.opendev.org/c/openstack/senlin/+/423012 -- Giacomo Lanciano Ph.D. Student in Data Science Scuola Normale Superiore, Pisa, Italy https://www.linkedin.com/in/giacomolanciano

2 2

[neutron][stadium][stable] Proposal to make stable/ocata and stable/pike branches EOL
by Slawek Kaplonski 21 May '21

21 May '21

Hi, I checked today that stable/ocata and stable/pike branches in both Neutron and neutron stadium projects are pretty inactive since long time. * according to [1], last patch merged patch in Neutron for stable/pike was in July 2020 and in ocata October 2019, * for stadium projects, according to [2] it was September 2020. According to [3] and [4] there are no opened patches for any of those branches for Neutron and any stadium project except neutron-lbaas. So based on that info I want to propose that we will close both those branches are EOL now and before doing that, I would like to know if anyone would like to keep those branches to be open still. [1] https://review.opendev.org/q/project:%255Eopenstack/neutron+(branch:stable/ ocata+OR+branch:stable/pike)+status:merged[1] [2] https://review.opendev.org/q/(project:openstack/ovsdbapp+OR+project:opensta… +(branch:stable/ocata+OR+branch:stable/pike)+status:merged[2] [3] https://review.opendev.org/q/project:%255Eopenstack/neutron+(branch:stable/ ocata+OR+branch:stable/pike)+status:open[3] [4] https://review.opendev.org/q/(project:openstack/ovsdbapp+OR+project:opensta… +(branch:stable/ocata+OR+branch:stable/pike)+status:open[4] -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] https://review.opendev.org/q/project:%255Eopenstack/neutron+(branch:stable/ ocata+OR+branch:stable/pike)+status:merged [2] https://review.opendev.org/q/(project:openstack/ovsdbapp+OR+project:opensta… +(branch:stable/ocata+OR+branch:stable/pike)+status:merged [3] https://review.opendev.org/q/project:%255Eopenstack/neutron+(branch:stable/ ocata+OR+branch:stable/pike)+status:open [4] https://review.opendev.org/q/(project:openstack/ovsdbapp+OR+project:opensta… +(branch:stable/ocata+OR+branch:stable/pike)+status:open

6 11

OVN ovsdb clustering question
by Satish Patel 21 May '21

21 May '21

Folks, I have 3 controller nodes and am trying to setup clustering for OVN deployment, but lack enough documentation and have some issues and questions regarding it. I found this document but again its little confusing and very old - https://mail.openvswitch.org/pipermail/ovs-discuss/2018-March/046470.html # controller 1 /usr/share/ovn/scripts/ovn-ctl --db-nb-addr=172.30.40.93 \ --db-nb-create-insecure-remote=yes \ --db-sb-addr=172.30.40.93 \ --db-sb-create-insecure-remote=yes \ --db-nb-cluster-local-addr=172.30.40.93 \ --db-sb-cluster-local-addr=172.30.40.93 \ --ovn-northd-nb-db=tcp:172.30.40.93:6641,tcp:172.30.40.25:6641,tcp:172.30.40.177:6641 \ --ovn-northd-sb-db=tcp:172.30.40.93:6642,tcp:172.30.40.25:6642,tcp:172.30.40.177:6642 \ start_northd # controller 2 /usr/share/ovn/scripts/ovn-ctl --db-nb-addr=172.30.40.25 \ --db-nb-create-insecure-remote=yes \ --db-sb-addr=172.30.40.25 \ --db-sb-create-insecure-remote=yes \ --db-nb-cluster-local-addr=172.30.40.25 \ --db-sb-cluster-local-addr=172.30.40.25 \ --db-nb-cluster-remote-addr=172.30.40.93 \ --db-sb-cluster-remote-addr=172.30.40.93 \ --ovn-northd-nb-db=tcp:172.30.40.93:6641,tcp:172.30.40.25:6641,tcp:172.30.40.177:6641 \ --ovn-northd-sb-db=tcp:172.30.40.93:6642,tcp:172.30.40.25:6642,tcp:172.30.40.177:6642 \ start_northd # controller 3 /usr/share/ovn/scripts/ovn-ctl --db-nb-addr=172.30.40.177 \ --db-nb-create-insecure-remote=yes \ --db-nb-cluster-local-addr=172.30.40.177 \ --db-sb-addr=172.30.40.177 \ --db-sb-create-insecure-remote=yes \ --db-sb-cluster-local-addr=172.30.40.177 \ --db-nb-cluster-remote-addr=172.30.40.93 \ --db-sb-cluster-remote-addr=172.30.40.93 \ --ovn-northd-nb-db=tcp:172.30.40.93:6641,tcp:172.30.40.25:6641,tcp:172.30.40.177:6641 \ --ovn-northd-sb-db=tcp:172.30.40.93:6642,tcp:172.30.40.25:6642,tcp:172.30.40.177:6642 \ start_northd ## Validation steps controller-2# export\ remote="tcp:172.30.40.93:6641,tcp:172.30.40.25:6641,tcp:172.30.40.177:6641" controller-2# ovn-nbctl --db=$remote show controller-2# In the above command i am seeing output only when it hit controller-1 node, but for node-2 and note-3 giving me empty output that means data replication doesn't work. what is the command to verify synchronization working between all 3 nodes? Do I need to restart any other services?

1 0

[sdk] R1.0 preparation work
by Artem Goncharov 20 May '21

20 May '21

Hey all, As we were discussing during the PTG preparation work for the openstacksdk R1.0 has been started. There is now feature branch “feature/r1” and a set of patches already in place ([1]). (While https://review.opendev.org/c/openstack/devstack/+/791541 <https://review.opendev.org/c/openstack/devstack/+/791541> is not merged there are no functional tests running, but that is not blocking from doing the main work) Things to be done: - get rid of all direct REST calls in the cloud layer. Instead reuse corresponding proxies [must] - generalise tag, metadata, quota(set), limits [must] - clean the code from some deprecated things and py2 remaining (if any) [must] - review resource caching to be implemented on the resource layer [optional] - introduction of read-only resource properties [optional] - restructure documentation to make it more used friendly [optional] Planned R1 interface changes Every cloud layer method (Connection.connection.***, and not i.e. Connection.connection.compute.***) will consistently return Resource objects. At the moment there is a mix of Munch and Resource types depending on the case. Resource class itself fulfil dict, Munch and attribute interface, so there should be no breaking changes for getting info out of it. The only known limitation is that compared to bare dict/Munch it might be not allowed to modify some properties directly on the object. Ansible collection modules [2] would be modified to explicitly convert return of sdk into dict (Resource.to_dict()) to further operate on it. This means that in some cases older Ansible modules (2.7-2.9) will not properly work with newer SDK. Zuul jobs and everybody stuck without possibility to use newer Ansible collection [2] are potential victims here (depends on the real usage pattern). Sadly there is no way around it, since historically ansible modules operate whatever SDK returns and Ansible sometimes decides to alter objects (i.e. no_log case) what we might want to forbid (read-only or virtual properties). Sorry about that. In some rare cases attribute naming (whatever returned by the cloud layer) might be affected (i.e. is_bootable vs bootable). We are going to strictly bring all names to the convention. Due to the big amount of changes touching lot of files here I propose to stop adding new features into the master branch directly and instead put them into feature/r1 branch. I want to keep master during this time more like a stable branch for bugfixes and other important things. Once r1 branch feel ready we will merge it into master and most likely release something like RC to be able to continue integration work with Ansible. Everybody interested in the future of sdk is welcome in doing reviews and code [1] to know what comes and to speed up the work. Any concerns? Suggestions? Regards, Artem [1] https://review.opendev.org/q/project:openstack%252Fopenstacksdk+branch:feat… <https://review.opendev.org/q/project:openstack%2Fopenstacksdk+branch:featur…> [2] https://opendev.org/openstack/ansible-collections-openstack <https://opendev.org/openstack/ansible-collections-openstack>

3 5

[TripleO] next irc meeting Tuesday 25 May @ 1400 UTC in #tripleo
by Marios Andreou 20 May '21

20 May '21

Reminder that the next TripleO irc meeting is: ** Tuesday 25 May 1400 UTC in freenode irc channel: #tripleo ** ** https://wiki.openstack.org/wiki/Meetings/TripleO ** ** https://etherpad.opendev.org/p/tripleo-meeting-items ** Please add anything you want to highlight at https://etherpad.opendev.org/p/tripleo-meeting-items This can be recently completed things, ongoing review requests, blocking issues, or anything else tripleo you want to share. Our last meeting was on May 11 - you can find the logs there http://eavesdrop.openstack.org/meetings/tripleo/2021/tripleo.2021-05-11-14.… Hope you can make it on Tuesday, regards, marios

1 0

[neutron] Drivers meeting 21.05.2021 and 28.05.2021 cancelled
by Slawek Kaplonski 20 May '21

20 May '21

Hi, We don't have any new RFEs to discuss [1] so let's cancel tomorrow's drivers meeting. Next week (28.05.2021) we have Recharge Day in Red Hat so we will probably not have quorum on the drivers meeting and I will also be offline so let's cancel it too. See You on the drivers meeting in 2 weeks (4.06.2021). Have a great weekend :) [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers[1] -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers

2 1

[horizon] Cross-domain user/role/project management
by Martin Chlumsky 20 May '21

20 May '21

Hello, We run a cloud service with multiple keystone domains (Default domain and later we added a federated domain (AzureAD)). We are giving "federated domain users" roles on the projects in the Default domain which existed before the integration with AureAD. Is there a way to manage cross-domain role assignments in Horizon? A horizon setting I missed? I tried as admin and only users and projects of one domain at a time ever show up (I tried switching the domain context to Default and the federated domain). Thank you, Martin

1 0

[ussuri][tripleo][ironic][tftp] add --blocksize to tftp during installation
by Ruslanas Gžibovskis 20 May '21

20 May '21

Hi all, I wanted to ask, is there an option in tripleO to deploy undercloud tftp server with additional option, I had to add it to /usr/share/openstack-tripleo-heat-templates/deployment/ironic/ironic-pxe-container-puppet.yaml, so my container start cmd looks like this now: tripleoussuri/centos-binary-ironic-pxe:current-tripleo /bin/bash -c BIND_HOST=$(hiera ironic::pxe::tftp_bind_host -c /etc/puppet/hiera.yaml); /usr/sbin/in.tftpd --foreground --user root --address $BIND_HOST:69 --blocksize 1399 --m ap-file /var/lib/ironic/tftpboot/map-file /var/lib/ironic/tftpboot ironic_pxe_tftp But I believe it should be possibility with ExtraConfigUndercloud? I know, our network better should be fixed, but it will take several decades :) and while it will be fixed I want to automate deployment and it should be upgrade resistant :) Thanks for the advice in advance. -- Ruslanas Gžibovskis +370 6030 7030

1 0

[TripleO] tripleo-ci-centos-8-containers-multinode now using ephemeral Heat for master/wallaby
by James Slagle 20 May '21

20 May '21

For awareness, I wanted to point out that tripleo-ci-centos-8-containers-multinode is now using ephemeral Heat on the master and wallaby branches. This change[1] merged yesterday that made the switch. Of note, the Heat logs for the overcloud deployment are now under the directory undercloud/home/zuul/overcloud-deploy/overcloud/heat-launcher/log in the job logs. There is also a pending docs patch that covers a bit more how the feature works: https://review.opendev.org/c/openstack/tripleo-docs/+/783008 [1] https://review.opendev.org/c/openstack/tripleo-quickstart/+/777108 -- -- James Slagle --

1 0