September 2021 - openstack-discuss

Question about vDPA support for live migration
by Jeffrey Zhang 14 Sep '21

14 Sep '21

Hey everyone, I am testing vDPA on OpenStack Wallaby. I have set it up successfully. But I found there are several features that are not implemented, including live/code migration[0], which I wanted. Anyone know what's the latest progress about this. when will the live migration feature land? I found no talk about this. [0] <https://signaldomn.online/click?redirect=https%3A%2F%2Freview.opendev.org%2…> https://review.opendev.org/c/openstack/nova/+/780866/3/ <https://signaldomn.online/click?redirect=https%3A%2F%2Freview.opendev.org%2…> releasenotes/notes/vdpa-cc2300d2c46c150b.yaml Thanks.

2 3

[puppet] Propose retiring puppet-freezer
by Takashi Kajinami 14 Sep '21

14 Sep '21

Hello, Today I looked into the current code of puppet-freezer and noticed this module is still very incomplete. Most of its implementations are inherited from the cookiecutter template, and the module doesn't support fundamental resources like packages, services and so on. Because we haven't seen any interest in fixing that feature gap for a long time, I'll propose retiring the module during this cycle. Please let me know if you have any concerns. If I don't hear any objections I'll submit a series of patches to retire the module. Thank you, Takashi Kajinami

2 3

[oslo] RFE requested for oslo-messaging
by Nikita Kalyanov 14 Sep '21

14 Sep '21

Dear Release Team, We experienced strange freezes and timeouts for a long time on our OpenStack deployment [1] and some duplicate messages [2]. After applying the fixes [3], [4] both bugs are gone. Is a freeze exception possible for these? Thanks! nkalyanov [1] https://bugs.launchpad.net/oslo.messaging/+bug/1935864 [2] https://bugs.launchpad.net/oslo.messaging/+bug/1935883 [3] https://review.opendev.org/c/openstack/oslo.messaging/+/800564 [4] https://review.opendev.org/c/openstack/oslo.messaging/+/800575

5 5

MTU configuration for instances
by shubjero 14 Sep '21

14 Sep '21

Hey Openstackers, I am trying to determine how to configure/manipulate an OpenStack instances MTU configuration upon deployment/creation. I know that in neutron.conf you can set the 'global_physnet_mtu = value' and 'path_mtu = value' in ml2_conf.ini. In our case we are setting these to 9000 as the physical interfaces of our control plane and compute nodes are all using 9000 mtu however the bonded interfaces for our various networks are 8900. With this mtu configured, we've noticed that our OpenStack neutron networks within a tenancy are auto-selecting a mtu of 8958 as from what I've read it will take the 9000 mtu and minus the approriate overhead to pass the underlying physical network properly but I think because our bonded interfaces are 8900 this has started to introduce some problems in instances with operating systems that hard code the MTU from Neutron networks. When an instance gets deployed it may (Ubuntu 20.04) or may not (Ubuntu 18.04) retrieve the network mtu from neutron metadata service and builds it in to the netplan configuration as provided below. My question is, where in Neutron could I configure a lower MTU for the instances? I am not sure if I should change my global_physnet_mtu and path_mtu to 8900 OR some other configuration option? Thanks all! ---- # curl --silent http://169.254.169.254/openstack/2018-08-27/network_data.json | jq . { "links": [ { "id": "tap4318b50a-76", "vif_id": "4318b50a-7685-4777-917f-eea947aa1cb6", "type": "ovs", "mtu": 8958, <--- Matches the MTU of the underlying OpenStack network attached to this instance "ethernet_mac_address": "fa:16:3e:a4:19:44" } ], "networks": [ { "id": "network0", "type": "ipv4_dhcp", "link": "tap4318b50a-76", "network_id": "4acb077c-0656-4731-ba42-031a22af7931" } ], "services": [] } ---- # cat /etc/netplan/50-cloud-init.yaml # This file is generated from information provided by the datasource. Changes # to it will not persist across an instance reboot. To disable cloud-init's # network configuration capabilities, write a file # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following: # network: {config: disabled} network: version: 2 ethernets: ens3: dhcp4: true match: macaddress: fa:16:3e:a4:19:44 mtu: 8958 <--- MTU gets hard-coded in the config for Ubuntu 20.04 but not Ubuntu 18.04. set-name: ens3

2 1

[TripleO] Reviving the TripleO review priorities etherpad
by James Slagle 13 Sep '21

13 Sep '21

I'd like to see about helping to focus our review priorities by reviving the tripleo-review-priorities etherpad: https://etherpad.opendev.org/p/tripleo-review-priorities I deleted all the old cruft, and created some new high level topics. There are likely others as well. I'll start by filling in some links to what I think the highest priority items are, but I could use help to create an accurate list of where the core team should focus. I'd like to get some feedback on the approach in the #tripleo meeting tomorrow as well. Let me know any thoughts. -- -- James Slagle --

1 0

[neutron] Bug deputy report for week of September 6
by Lajos Katona 13 Sep '21

13 Sep '21

Hi Neutron Team I was bug deputy in neutron last week. Summary ======= One bug needs more attention but that is for Rocky, and seems like ovs-agent ovs communication issue ( https://bugs.launchpad.net/neutron/+bug/1943112 ) And one question regarding Neutron standalone use with OVN perhaps ( https://bugs.launchpad.net/neutron/+bug/1943355 ) The employee of the week is ralonsoh :-) Needs attention ================ * openstack rocky version, neutron is throwing the following error : ovs|00002|ovsdb_idl|WARN|transaction error: {"details":"Transaction causes multiple rows in \"Manager\" table to have identi https://bugs.launchpad.net/neutron/+bug/1943112 * Can We Use Openstack Neutron as standalone component? https://bugs.launchpad.net/neutron/+bug/1943355 This one is more like a question, not an actual bug, or a bug for documentation. Bugs with assignees =================== * [OVN] "DHCP_Options" is not updated when the metadata port IPs are https://bugs.launchpad.net/neutron/+bug/1942794 Assigned to ralonsoh, patch: https://review.opendev.org/c/openstack/neutron/+/807692 * [OVN] Metadata ports owner is "network:distributed" only since Wallaby release https://bugs.launchpad.net/neutron/+bug/1942866 Assigned to ralonsoh, patch: https://review.opendev.org/c/openstack/neutron/+/807707 * [OVN] "neutron-ovn-tempest-ovs-master-fedora" CI job failing since 2021-08-24 https://bugs.launchpad.net/neutron/+bug/1942913 Assigned to ralonsoh, patches: https://review.opendev.org/c/openstack/neutron/+/808109 & https://review.opendev.org/c/openstack/tempest/+/808081 * [OVN][FT] During the OvnNorthd stop, the unix file could not exist https://bugs.launchpad.net/neutron/+bug/1943029 Assigned to ralonsoh, patch: https://review.opendev.org/c/openstack/neutron/+/807862 * Replace "Inspector.from_engine()" with "sqlalchemy.inspect()" https://bugs.launchpad.net/neutron/+bug/1943155 Assigned to ralonsoh, patch: https://review.opendev.org/c/openstack/neutron/+/808103 RFEs ==== No new RFE for this week.

1 0

OpenInfra Live - September 16 at 9am CT
by Ashlee Ferguson 13 Sep '21

13 Sep '21

Hi everyone, This week’s OpenInfra Live episode is brought to you by the OpenInfra Community. Since the Paris Summit in 2014, the OpenInfra Foundation has hosted our annual Superuser Awards to recognize organizations that have used open infrastructure to meaningfully improve their business while contributing back to the community. Past winners will join us for this episode to discuss where they are now, what is next, and tips for organizations applying for this year's awards. Episode: Superusers: Where are they now? Date and time: September 16 at 9am CT (1400 UTC) You can watch us live on: YouTube: https://www.youtube.com/watch?v=nUwgBdx0lSw <https://www.youtube.com/watch?v=nUwgBdx0lSw> LinkedIn: https://www.linkedin.com/feed/update/urn:li:ugcPost:6841804188478009344/ <https://www.linkedin.com/feed/update/urn:li:ugcPost:6841804188478009344/> Facebook: https://www.facebook.com/104139126308032/posts/4319519031436666/ <https://www.facebook.com/104139126308032/posts/4319519031436666/> WeChat: recording will be posted on OpenStack WeChat after the live stream Speakers: Jared Baker (The Ontario Institute for Cancer Research (OICR)) Belmiro Moreira (CERN) Mohammed Naser (VEXXHOST) Xiaoguang, Zhang and Zhiqiang Yu (China Mobile) Think your organization or someone you know could be a Superuser? Nominations <https://openinfrafoundation.formstack.com/forms/superuserawards_2021> for the 2021 Superuser Awards are open! Have an idea for a future episode? Share it now at ideas.openinfra.live <https://openinfrafoundation.formstack.com/forms/openinfralive>. Thanks, Ashlee

1 0

[Image Encryption] Meeting today cancelled
by Josephine Seifert 13 Sep '21

13 Sep '21

Hello, unfortunately I have to cancel the meeting today. Next meeting will be Monday 20th. greetings Josephine (Luzi)

1 0

[designate][interop] test_create_all_recordset_types ddt issue
by Martin Kopec 13 Sep '21

13 Sep '21

Hi designate team, I'm reaching out because we have encountered a problem with one of the tests [1]. We track the following name [2]: designate_tempest_plugin.tests.api.v2.test_recordset.RecordsetsTest.test_create_all_recordset_types That test name is actually incorrect due to the ddt and the real name of the test is created dynamically based on the test data passed via ddt. We have a consistency check which is supposed to verify that the test names tracked in our guidelines match the ones in Tempest/tempest plugins, however, there was a bug - we are fixing that by [3]. The question is, should interop track all the permutations of the test? See [4]. [1] https://opendev.org/openstack/designate-tempest-plugin/src/commit/da27a70ae… [2] https://opendev.org/osf/interop/src/commit/d8eac71fa507c68e9c1f83a19dd77af8… [3] https://review.opendev.org/c/osf/interop/+/806598 [4] https://review.opendev.org/c/osf/interop/+/807586 Thank you, -- Martin Kopec Senior Software Quality Engineer Red Hat EMEA

5 7

Instances cannot ping each other and cannot ping virtual-router
by wodel youchi 13 Sep '21

13 Sep '21

Hi, I deployed OpenStack Train using TripleO using this tutorial : https://kdjlab.com/deploying-rdo-in-a-cohesive-manner/ and the documentation of TripleO. I deployed it with DVR. In my deployment I am using virtual machines with nested-kvm. The deployment went well, I am using network isolation like this : - nic1 : provisioning - nic2 and nic3 (bond0) storage and storage mgmt networks, each one in it's VLAN - nic3 and nic5 (bond1) tenant, api and *external* (10.0.2.0/24 VLAN2100) networks, each one in it's VLAN In my physical host (the bare metal KVM) I created a bridge which handles the provisioning, tenant, api and external networks. I created a private tenant network (172.16.100.0/24). openstack network create private neutron subnet-create private 172.16.100.0/24 --name private-sub --dns-nameserver 172.16.0.252 I created a public network and I attached it to the external network using the same VLAN tag (10.0.2.0/24 VLAN 2100, pool: 10.0.2.100-10.0.2.120) : *openstack network create --provider-network-type vlan --provider-physical-network datacentre --provider-segment 2100 --external public* neutron subnet-create public 10.0.2.0/24 --name public-sub --disable-dhcp --allocation-pool=start=10.0.2.100,end=10.0.2.120 --gateway=10.0.2.1 --dns-nameserver 172.16.0.252 I created a vrouter, one port in the public network and the other in the private network. I created two cirrus instances, each one got it's ip address from the private network. I found : cirrus-1 : 172.16.100.81 cirrus-2 : 172.16.100.103 vrouter : 172.16.100.1 private : 10.0.2.101 external neutron:dhcp : 172.16.100.2 The problems : - The instances cannot ping each other. - The instances cannot ping the vrouter. - I cannot ping the public vrouter interface. But both instances can ping neutron:dhcp Could someone help me dig into this. Thanks in advance, Regards.

1 1

Openstack nova live migration pain
by hai wu 13 Sep '21

13 Sep '21

This is Openstack train release. Nova live migration is extremely painful to deal with. Everytime we complete a live migration, nova-compute service on the source host would still be up and runnning, but it would always fail to further increment the report_count database field in nova database, host heartbeat purpose, thus controller would think the hypervisor host failed via its is_up() function checking on report_count and updated_at fields iirc. So we end up having to manually migrate one vm at a time, then restart service, then manually migrate the next vm .. Any ideas? I already tried setting debug=True for nova.conf even for database tracing, but thus far I could not find any obvious error message. Each time the live migration (no shared storage) would succeed, but each time we will have to restart nova-compute service. This is so bad .. Any suggestions on this would be highly appreciated. Thanks, Hai

4 12

[largescale-sig] Next meeting: Sept 15th, 15utc
by Thierry Carrez 13 Sep '21

13 Sep '21

Hi everyone, The Large Scale SIG meeting is back this Wednesday in #openstack-operators on OFTC IRC, at 15UTC. You can doublecheck how that time translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20210915T15 A number of topics have already been added to the agenda, including discussing the topic of 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 0

[kolla][operators] Kolla Ansible will switch to use Quay.io by default (instead of Docker Hub)
by Radosław Piliszek 13 Sep '21

13 Sep '21

Dear Kolla Operators, This is a heads-up message that Kolla Ansible will switch to using Quay.io instead of Docker Hub by default. [1] This was agreed at the last meeting unless we find obstacles not to do it. But it seems it's even a better option for our users from China. [2] Therefore the patch [1] has been proposed and will likely be merged and probably backported to stable branches too. The main reasoning behind this change is that users suffer from Docker Hub's limits. [3] You may have noticed we started (a long time ago) publishing weekly, instead of daily, to Docker Hub to mitigate the issue to some extent. However, we had to switch our CI to Quay.io anyway to really be able to work on the project rather than pray for luck with Docker Hub. Quay.io has been great for us in general so we decided to make the same switch for users. Oh, and, by the way, we publish to Quay.io daily. ;-) If you use your own, local registry, then you are most likely unaffected but make sure you set both `kolla_registry` AND `kolla_namespace` as we have to override both. Finally, kind reminder that operators of multinode and production clusters are strongly advised to set up their own, local registries. The docs show a simple minimal example of that. [4] (use option 1 from the current page as possibility of option 2 will be gone with the switch to quay.io). Thank you for reading up to this point! [1] https://review.opendev.org/c/openstack/kolla-ansible/+/808486 [2] http://lists.openstack.org/pipermail/openstack-discuss/2021-September/02481… [3] https://bugs.launchpad.net/kolla-ansible/+bug/1942134 [4] https://docs.openstack.org/kolla-ansible/wallaby/user/multinode.html#deploy… -yoctozepto

2 2

Cannot create a swift container, mandatory "Storage Policy" dropdown field is empty
by Michel Niyoyita 13 Sep '21

13 Sep '21

Hello team , I am replacing swift by Ceph Radosgateway , and I am successful by creating containers through openstack and ceph CLI side . but once trying to create through the horizon dashboard I get errors: *Error: *Unable to fetch the policy details. , Unable to get the Swift service info and Unable to get the Swift container listing. Kindly help to solve the issue I deployed Openstack wallaby using kolla-ansible running on ubuntu 20.04 and ceph pacific using ansible running on ubuntu 20.04 Michel

1 0

goodbye openstack, welcome ansible
by Sorin Sbarnea 13 Sep '21

13 Sep '21

Today was my last day as a part of the OpenStack team at Red Hat. After almost 5 years, I've decided to use the opportunity to join the newly created Ansible DevTools team, a team that will improve and maintain development tools such as ansible-lint, molecule and the more recent Ansible extension for VS Code. If you are interested in finding out more, make sure to attend the next Ansible Contributor Summit <https://github.com/ansible/community/wiki/Contributor-Summit> which is happening at the end of this month. To those who will be missing me, don't worry I will not be far away. Cheers! Sorin Sbarnea

7 6

[all][infra] Mailing lists offline 2021-09-12 for server upgrade
by Jeremy Stanley 13 Sep '21

13 Sep '21

n Sunday, September 12, the OpenDev sysadmins will be performing operating system upgrades for the server hosting the lists.airshipit.org, lists.opendev.org, lists.openstack.org, lists.starlingx.io, and lists.zuul-ci.org sites. Expect extended outages for message delivery and access to archives between 15:00 UTC and 21:00 UTC, though messages sent to the mailing lists at these sites should queue normally and be delivered automatically after maintenance activities have concluded. If you have any questions, feel free to reply to this message, or find us in the #opendev channel on the OFTC IRC network. -- Jeremy Stanley

1 1

[all][tc] What's happening in Technical Committee: summary 10th Sept, 21: Reading: 5 min
by Ghanshyam Mann 11 Sep '21

11 Sep '21

Hello Everyone, Here is this week's summary of the Technical Committee activities. 1. TC Meetings: ============ * TC held this week's IRC meeting on Sept 9th Thursday. * Most of the meeting discussions are summarized in the below sections (Completed or in-progress activities section). To know more details, you can check the complete logs @ https://meetings.opendev.org/meetings/tc/2021/tc.2021-09-09-15.00.log.html * We will have next week's meeting on Sept 16th, Thursday 15:00 UTC on IRC, feel free the topic in agenda [1] by Sept 15th. 2. What we completed this week: ========================= * Closeout Yoga PTL Election[2] * New project 'Venus' is an official project now[3] * Added the cinder-lvm charm to Openstack charms[4] * Fixed documentation for "assert:supports-standalone" tag[5] 3. Activities In progress: ================== TC Tracker for Xena cycle ------------------------------ TC is using the etherpad[6] for Xena cycle working item. We will be checking and updating the status biweekly in the same etherpad. Open Reviews ----------------- * Twelve open reviews for ongoing activities[7]. TC Chair/Vice-chair for Yoga ---------------------------------- * TC chair and vice-chair nomination are also up for review/vote[8][9]. TC tags analysis ------------------- * As discussed in last PTG, TC is working on an analysis of the usefulness of the Tags framework[10] or what all tags can be cleaned up. * You might have read the email from yoctozepto[11] about it, if you are operator, please respond to the email and based on the feedback we will continue the discussion on this. Leaderless projects ----------------------- * All the six leaderless projects[12] now have leaders identified and they are being proposed as PTL in governance[13]. Collecting Pain points from projects/SIGs/pop-up ----------------------------------------------------------- * We will continue discussing it in PTG[14], join us if you are interested to help/discuss this topic. Project updates ------------------- * Add openstack-loadbalancer charm and interfaces[15] * Retiring js-openstack-lib [16] Yoga release community-wide goal ----------------------------------------- * Please add the possible candidates in this etherpad [17]. * Current status: "Secure RBAC" is selected for Yoga cycle[18]. PTG planning ---------------- * We are collecting the PTG topics in etherpad[19], feel free to add any topic you would like to discuss. * We discussed the live stream of one of the TC PTG sessions like we did last time. Once we will have more topics in etherpad then we can select the appropriate one. Test support for TLS default: ---------------------------------- * Rico has started a separate email thread over testing with tls-proxy enabled[20], we encourage projects to participate in that testing and help to enable the tls-proxy in gate testing. 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[21]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [22] 3. Office hours: The Technical Committee offers a weekly office hour every Tuesday at 0100 UTC [23] 4. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [2] http://lists.openstack.org/pipermail/openstack-discuss/2021-September/02474… [3] https://review.opendev.org/c/openstack/governance/+/804824 [4] https://review.opendev.org/c/openstack/governance/+/807203 [5] https://review.opendev.org/c/openstack/governance/+/807728 [6] https://etherpad.opendev.org/p/tc-xena-tracker [7] https://review.opendev.org/q/project:openstack/governance+status:open [8] https://review.opendev.org/c/openstack/governance/+/807163 [9] https://review.opendev.org/c/openstack/governance/+/807178 [10] https://governance.openstack.org/tc/reference/tags/index.html [11] http://lists.openstack.org/pipermail/openstack-discuss/2021-September/02480… [12] https://etherpad.opendev.org/p/yoga-leaderless [13] https://review.opendev.org/q/topic:%2522formal-vote%2522+status:open+messag… [14] https://etherpad.opendev.org/p/pain-point-elimination [15] https://review.opendev.org/c/openstack/governance/+/807837 [16] https://review.opendev.org/c/openstack/governance/+/798540 [17] https://etherpad.opendev.org/p/y-series-goals [18] https://review.opendev.org/c/openstack/governance/+/803783 [19] https://etherpad.opendev.org/p/tc-yoga-ptg [20] http://lists.openstack.org/pipermail/openstack-discuss/2021-June/023000.html [21] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [22] http://eavesdrop.openstack.org/#Technical_Committee_Meeting [23] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours -gmann

1 0

[designate][interop][qa] Yoga PTG - ddt topic
by Martin Kopec 10 Sep '21

10 Sep '21

Hi designate team, we (interop) would like to schedule a session on your PTG agenda to go through the latest changes in interop and more importantly through the ddt issue [1][2]. I put a topic proposal to your ptg agenda [3]. [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-September/02475… [2] https://bugs.launchpad.net/designate/+bug/1943115 [3] https://etherpad.opendev.org/p/yoga-ptg-designate Thank you, -- Martin Kopec Senior Software Quality Engineer Red Hat EMEA

1 0

[neutron][interop] Yoga PTG session request
by Martin Kopec 10 Sep '21

10 Sep '21

Hi neutron team, we (interop) would like to schedule a 15-30 minute session on your PTG agenda to go through the latest changes in interop. We also detected a few tests from neutron-tempest-plugin which aren't tracked in interop yet and we need your help to find out whether they are good candidates or not. I put a topic proposal to your ptg agenda [1]. The best time seems to be on Wednesday or Thursday atm. [1] https://etherpad.opendev.org/p/neutron-yoga-ptg Thank you, -- Martin Kopec Senior Software Quality Engineer Red Hat EMEA

1 0

[horizon][dev] Multiple Login Sessions Enhancement Proposal
by Soares Sarto, Ricardo 10 Sep '21

10 Sep '21

Hi, Based on a new feature request about Horizon's login session, we would like to know if you're open to considering the improvement described below. If that is the case, we can submit a spec and upstream that implementation when the feature is done. Currently, a specific user is able to create multiple login sessions in Horizon, allowing him to log in to Horizon from multiple browsers/devices at the same time. The proposal is to have a parameterized solution and have a configuration to control how Horizon's login sessions are handled, the configuration options would be as below: 1 - Default option, allow the user to create multiple login sessions - this is the current behavior; 2 - Block subsequent login attempts if the user already has an active session; 3 - Invalidate the active session (if there is one) when the user creates a new one. Option number 2 obligates the user to log out of the system before opening a new one, on the other hand, in option number 3, the Horizon application is in charge of invalidating any previous active session and keeping only the latest one. This solution targets only Horizon login sessions, not affecting other kinds of sessions (e.g.: CLI).

3 2

[devstack][openstack-qa] DevStack on VirtualBox with Host-only Adapter
by os-user157 10 Sep '21

10 Sep '21

Hi all, I'm trying to deploy DevStack inside an Ubuntu Server 20.04.3 LTS virtual machine inside VirtualBox, but I'm struggling a lot, I got a lot of different errors. My use case: I want to test Zuul and DevStack, so I'll create a virtual machine for DevStack and one for Zuul, both on VirtualBox. I'm using a Host-only adapter with CIDR 192.168.200.0/24, and I need DevStack to be accessible on this network, and to use this network as the floating range for giving floating IP addresses to instances inside DevStack, so that Zuul can also access them. My local.conf: https://paste.openstack.org/show/809182/ Screenshots of the network configuration of my VirtualBox VM: First adapter, NAT (used for internet connectivity): https://i.imgur.com/C7XTiLJ.png Second adapter, host-only, used for communication with my Windows host and other VMs in the same network: https://i.imgur.com/Qeciuqx.png DevStack is erroring with the arping command on lib/neutron-legacy, arping gets 0 responses and exits the script with exit code 1 Does anyone have experience in dpeloying DevStack inside VirtualBox in such manner? I really need some help with this, if anyone could give me some ideas of waht could be wrong, it'd very much appreciated! Thanks.

3 3

[Interop] Proposal for new weekly meeting
by Arkady Kanevsky 10 Sep '21

10 Sep '21

Team, Friday meetings are a bit late for EMEA folks and too close to weekend plans. Propose that we move the meeting to Mondays (3pm UTC). Feedback, please. Thanks, -- Arkady Kanevsky, Ph.D. Phone: 972 707-6456 Corporate Phone: 919 729-5744 ext. 8176456

2 2

[release] Release countdown for week R-3, Sep 13 - Sep 17
by Herve Beraud 10 Sep '21

10 Sep '21

Development Focus ----------------- The Release Candidate (RC) deadline is next Thursday, September 16. Work should be focused on fixing any release-critical bugs. General Information ------------------- All deliverables released under a cycle-with-rc model should have a first release candidate by the end of the week, from which a stable/xena branch will be cut. This branch will track the Xena release. Once stable/xena has been created, the master branch will be ready to switch to Yoga development. While the master branch will no longer be feature-frozen, please prioritize any work necessary for completing Xena plans. Release-critical bugfixes will need to be merged in the master branch first, then backported to the stable/xena branch before a new release candidate can be proposed. Actions ------- Early in the week, the release team will be proposing RC1 patches for all cycle-with-rc projects, using the latest commit from the master branch. If your team is ready to go for cutting RC1, please let us know by leaving a +1 on these patches. If there are still a few more patches needed before RC1, you can -1 the patch and update it later in the week with the new commit hash you would like to use. Remember, stable/xena branches will be created with this, so you will want to make sure you have what you need included to avoid needing to backport changes from the master branch (which will technically then be Yoga) to this stable branch for any additional RCs before the final release. The release team will also be proposing releases for any deliverable following a cycle-with-intermediary model that has not produced any Xena release so far. Finally, now is a good time to finalize release highlights. Release highlights help shape the messaging around the release and make sure that your work is properly represented. Upcoming Deadlines & Dates -------------------------- RC1 deadline: September 16 (R-3 week) Final RC deadline: September 30 (R-1 week) Final Xena release: October 6 -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud

1 0

[cyborg] RFE requested for Cyborg
by Brin Zhang(张百林) 10 Sep '21

10 Sep '21

Dear Release Team, We experienced strange freezes and timeouts for a long time on our python-cyborgclient need to update the lost feature of device profile 'description' [1] And we have merged this at 7, Sep, that we can update [2]'s hash then to publish it. [1] https://review.opendev.org/c/openstack/python-cyborgclient/+/803886 [2] https://review.opendev.org/c/openstack/releases/+/807624 brinzhang

3 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