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

[neutron] Specs to review
by Slawek Kaplonski 11 May '21

11 May '21

Hi, As we spoke on today's team meeting. I set review-priority = +1 for some of the specs which I think would be good to review. List is available at https:// tinyurl.com/22ct4dwx[1] Please take a look at those specs if You will have some time. Thx in advance. -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] https://tinyurl.com/22ct4dwx

1 0

[all] Nomination open for OpenStack "Y" Release Naming until 10th June, 21
by Ghanshyam Mann 11 May '21

11 May '21

Hello Everyone, We are now starting the process for the OpenStack 'Y' release name. Below are the details on dates and criteria: Dates[1]: ======= - Nomination Open: 2021-05-13 to 2021-06-10 - TC Poll on proposed names: 2021-06-10 to 2021-06-17 Criteria: ====== - Refer to the below governance page for the naming criteria: https://governance.openstack.org/tc/reference/release-naming.html#release-n… - Any community members can propose the name to the below wiki page: https://wiki.openstack.org/wiki/Release_Naming/Y_Proposals We encourage all community members to participate in this process. [1]https://governance.openstack.org/tc/reference/release-naming.html#polls -gmann

1 0

[ops][victoria][cinder] Import volume?
by DHilsbos＠performair.com 11 May '21

11 May '21

All; I'm looking to transfer several VMs from XenServer to an OpenStack Victoria cloud. Finding explanations for importing Glance images is easy, but I haven't been able to find a tutorial on importing Cinder volumes. Since they are currently independent servers / volumes it seems somewhat wasteful and messy to import each VMs disk as an image just to spawn a volume from it. We're using Ceph as the storage provider for Glance and Cinder. Thank you, Dominic L. Hilsbos, MBA Director - Information Technology Perform Air International Inc. DHilsbos(a)PerformAir.com www.PerformAir.com

3 5

[train][nova][neutron] gratiutous arp on centos 7
by Ignazio Cassano 11 May '21

11 May '21

Hello All, We've just updated openstack centos7 fron stein to train. Unfortunately live migrations works but vm lost a lot of pings after migration. We also applied the following patches but the do not solve: https://review.opendev.org/c/openstack/neutron/+/640258/ https://review.opendev.org/c/openstack/neutron/+/753314/ https://review.opendev.org/c/openstack/neutron/+/766277/ https://review.opendev.org/c/openstack/nova/+/742180/12 https://review.opendev.org/c/openstack/nova/+/747454/4 After that we also tried to apply https://review.opendev.org/c/openstack/nova/+/602432 but the issue remains the same. Please, anyone can help us ? Ignazio

1 0

[zun][horizon] How to display containers among VMs on network topology ?
by Maxime d'Estienne 11 May '21

11 May '21

Hello, I installed Zun on my stack and it works very well, I have a few containers up and running. I also added the zun-ui plugin for Horizon wich allows me to see the list of containers and to create them. But I often use the network topology view, wich I found very clean sometimes. I wondered if there is a solution to display the containers as are Vm's ? Thank you ! Maxime

2 2

[sdk]: identity service if get_application_credential method could use user name
by dmeng 11 May '21

11 May '21

Hello, Hope this email finds you well. Shall I please ask a question about the openstacksdk identity service, the application credential? We would like to get the expiration date of an application credential using the Identity v3 method get_application_credential or find_appplication_credential. We found that they require both the user id and the application credential id in order to get it. The code I'm using is as the following, and this works for us. conn = connection.Connection( session=sess, region_name='Victoria, identity_api_version='3') keystone = conn.identity find = keystone.get_application_credential(user='my_user_id', application_credential = 'app_cred_id') expire_date = find['expires_at'] We are wondering if we could use the user name to get it instead of the user id? If I do get_application_credential(user='catherine', application_credential = 'app_cred_id'), then it will show me an error that "You are not authorized to perform the requested action: identity:get_application_credential". Is there any method that no need user info, can just use the application credential id to get the expiration date? We also didn't find any documentation about the application credential in openstacksdk identity service docs. Thanks and have a great day! Catherine

2 5

Re: [cinder] Multiattach volume mount/attach limit
by Adam Tomas 11 May '21

11 May '21

Hi, thank you for the answer. Regards Adam > > Hi, > > This is currently not possible, and I believe there is no ongoing effort > to add this feature either. > > Cheers, > Gorka. > > >

1 0

[placement] clouds.yaml does not use placement API version variable
by jayaditya gupta 10 May '21

10 May '21

Even after specifying the variable in clouds.yaml placement still uses version 1.0 Story : https://storyboard.openstack.org/#!/story/2008553 Hello can someone help me on this one. I'm not sure where exactly is the issue in placement or in osc-placement . I would really appreciate the insight on this one. Thanks

1 0

[dev][tc]nova-scheduler: cpu-topology: sub-numa(numa nodes within one CPU socket) aware scheduler
by Song Bao Hua (Barry Song) 10 May '21

10 May '21

Dears, Historically, both AMD EPYC and Intel Xeon had NUMA nodes within one CPU socket. For Intel haswell/broadwell, they could have two rings to connect multiple CPUs: +----------------------------+ +-------------------------+ +---+ +-----+ +----+ +---+ +---+ +-----+ +----+ +---+ | | | | +---+ +-----+ +----+ ring +---+ +---+ ring +-----+ +----+ +---+ | | | | +---+ +-----+ +----+ +---+ +---+ +-----+ +----+ +---+ | | | | | | | | +----------------------------+ +-------------------------+ Due to the latency to access the memory located in different rings, cluster-on-die(COD) NUMA nodes did exist in haswell/ broadwell. For AMD EPYC, they used to have 4 DIEs in one CPU socket: +-------------------------------------------------+ | AMD EPYC | | +-------------+ +-------------+ | | | | | | | | | die | | die | | | | |-------- | | | | |\ /| | | | +-------------+ -\ /- +-------------+ | | | /-\ | | | +-------|------+/- -+-------|------+ | | | - | | | | | die | | die | | | | |------| | | | | | | | | | +--------------+ +--------------+ | | | +-------------------------------------------------+ These 4 different DIEs could be configured as 4 different NUMA. However, with the development of hardware, Intel and AMD no longer need to be aware of NUMA nodes within single one CPU. Intel has moved to mesh since skylake(server): +-------|-----------------------+ | | | | | | | | | | |-------|-------|-------|-------| | | | | | | | | | | |-------|-------|-------|-------| | | | | | | | | | | |-------|-------|-------|-------| | | | | | | | | | | +-------------------------------+ AMD moved memory and I/O to a separate DIE, thus made the whole CPU become UMA in EPYC II: +---------+ +---------+ +---------+ +---------+ | cpu die | |cpu die | |cpu die | |cpu die | | | | | | | | | +---------+ +---------+ +---------+ +---------+ +------------------------------------------------------+ | | | memory and I/O DIE | | | +------------------------------------------------------+ +---------+ +---------+ +---------+ +---------+ |cpu die | |cpu die | |cpu die | |cpu die | | | | | | | | | +---------+ +---------+ +---------+ +---------+ Skylake, while still having SNC(sub-numa-cluster) within a DIE for a huge mesh network, doesn't really suffer from this kind of internal sub-numa since the latency difference is really minor to enable SNC or not. According to "64-ia-32-architectures-optimization-manual"[1], for a typical 2P system, disabling and enabling SNC will bring minor latency difference for memory access within one CPU: SNC off: Using buffer size of 2000.000MB Measuring idle latencies (in ns)... Numa node Numa node 0 1 0 81.9 153.1 1 153.7 82.0 SNC on: Using buffer size of 2000.000MB Measuring idle latencies (in ns)... Numa node Numa node 0 1 2 3 0 81.6 89.4 140.4 153.6 1 86.5 78.5 144.3 162.8 2 142.3 153.0 81.6 89.3 3 144.5 162.8 85.5 77.4 As above, if we disable sub-numa in one CPU, the CPU has memory latency as 81.9, but if sub-numa is enabled, the advantage is really minor, SNC can access its own memory with the latency of 81.6 with 0.3 gap only. So SNC doesn't really matter on Xeon. However, the development of kunpeng920's topology is different from Intel and AMD. Similar with AMD EPYC, kunpeng920 has two DIEs in one CPU. Unlike EPYC which has only 8cores in each DIE, each DIE of kunpeng920 has 24 or 32 cores. For a typical 2P system, we can set it to 2NUMA or 4NUMA. +------------------------------+ +------------------------------+ | CPU | | CPU | | +----------+ +----------+ | | +----------+ +----------+ | | | | | | | | | | | | | | | DIE | | DIE | | | | DIE | | DIE | | | | | | | | | | | | | | | | | | | | | | | | | | | +----------+ +----------+ | | +----------+ +----------+ | | | | | +------------------------------+ +------------------------------+ * 2NUMA - DIE interleave In this case, two DIEs become one NUMA. The advantage is that we are getting more CPUs in one NUMA, so this decreases the fragment of CPUs and help deploy more virtual machines on the same host when we apply the rule of pinning VM within one NUMA, compared with disabling DIE interleave. But, this has some obvious disadvantage. Since we need to run DIE interleave, the average memory access latency could increase much. Enabling DIE interleave: Numa node Numa node 0 1 0 95.68 199.21 1 199.21 95.68 Disabling DIE interleave Numa node Numa node 0 1 2 3 0 85.79 104.33 189.95 209.00 1 104.33 85.79 209.00 229.60 2 189.95 209.00 85.79 104.33 3 209.00 229.60 104.33 85.79 As above, one DIE can access its local memory with latency of 85.79, but when die-interleave is enabled, the latency becomes 95.68. The gap 95.68-85.79 isn't minor. * 4NUMA - each DIE becomes one NUMA In this way, NUMA-aware software can access its local memory with much lower latency. Thus, we can gain some performance improvement in openstack if one VM is deployed in one DIE and only access its local memory. Testing has shown 4%+ performance improvement. However, under the rule that VM does not cross NUMA, less VMs could be deployed on the same host. In order to achieve both goals of performance improvement and anti-fragmentation, we are looking for some way of sub-numa awareness in openstack scheduler. That means, 1. we will disable DIE interleave, thus, for 2P system, we are going to have 4 NUMA; 2. we use the rule VM shouldn't cross CPU, thinking one CPU as a big NUMA and each DIE as a smaller sub-numa. 3. For guests, we can define different priorities, for high priority VMs whose performance is a great concern, openstack will try to deploy them in same sub-numa which is a DIE for kunpeng920; for low priority VMs who can endure across-die latency, they could be placed on different sub-numa, but still within same CPU. So basically, we'd like to make openstack aware of the topology of sub-numa within one cpu and support a rule which prevents cross-CPU but allows cross-DIE. At the same time, this scheduler should try its best to deploy important VMs in same sub-numa and allow relatively unimportant VMs to cross two sub-numa. This might be done by customized openstack flavor according to [2], but we are really looking for some flexible and automatic way. If openstack scheduler can recognize this kind of CPU topology and make smart decision accordingly, it would be nice. Please let me know how you think about it. And alternative ways also welcome. [1] https://software.intel.com/content/www/us/en/develop/download/intel-64-and-… [2] https://docs.openstack.org/nova/pike/admin/cpu-topologies.html Thanks Barry

1 0

Re: [ironic] IPA image does not want to boot with UEFI
by Julia Kreger 10 May '21

10 May '21

Adding the list back and trimming the message. Replies in-band. Well, that is good that the server is not signed, nor other esp images are not working. On Thu, Apr 1, 2021 at 11:20 AM Vuk Gojnic <vuk.gojnic(a)gmail.com> wrote: > > Hey Julia, > > Thanks for asking. I have tried with several ESP image options with same effect (one taken from Ubuntu Live ISO that boots on that node, another downloaded and third made with grub tools). None of them was signed. Interesting. At least it is consistent! Have you tried to pull down the iso image and take it apart to verify it is UEFI bootable against a VM or another physical machine? I'm wondering if you need both uefi parameters set. You definitely don't have properties['capabilities']['boot_mode'] set which is used or... maybe a better word to use is drawn in for asserting defaults, but you do have the deploy_boot_mode setting set. I guess a quick manual sanity check of the actual resulting iso image is going to be critical. Debug logging may also be useful, and I'm only thinking that because there is no logging from the generation of the image. > > The server is not in UEFI secure boot mode. Interesting, sure sounds like it is based on your original message. :( > Btw. I will be on holidays for next week so I might not be able to follow up on this discussion before Apr 12th. No worries, just ping us on irc.freenode.net in #openstack-ironic if a reply on the mailing list doesn't grab our attention. > > Bests, > Vuk > > On Thu, Apr 1, 2021 at 4:20 PM Julia Kreger <juliaashleykreger(a)gmail.com> wrote: >> >> Greetings, >> >> Two questions: >> 1) Are the ESP image contents signed, or are they built using one of >> the grub commands? >> 2) Is the machine set to enforce secure boot at this time? >> >> [trim]

2 3

[cinder] Multiattach volume mount/attach limit
by Adam Tomas 10 May '21

10 May '21

Hi, Is there any way to limit the number of possible mounts of multiattach volume? Best regards Adam Tomas

2 1

[tripleo][ci] all c8 master / wallaby blocked
by Wesley Hayutin 10 May '21

10 May '21

https://bugs.launchpad.net/tripleo/+bug/1927952 https://zuul.openstack.org/builds?job_name=tripleo-ci-centos-8-content-prov… Issues atm w/ quay.io, we are making sure our failover is working properly atm. RDO was missing the latest ceph containers. Thanks

1 1

[swift][security-sig] Please revisit your open vulnerability report
by Jeremy Stanley 10 May '21

10 May '21

Please help the OpenStack Vulnerability Management Team by taking a look at the following report: Swift tempurl middleware reveals signatures in the logfiles (CVE-2017-8761) https://launchpad.net/bugs/1685798 Can it be exploited by a nefarious actor, and if so, how? Is it likely to be fixable in all our supported stable branches, respecting stable backport policy? What deployment configurations and options might determine whether a particular installation is susceptible? This is the sort of feedback we depend on to make determinations regarding whether and how to keep the public notified, so they can make informed decisions. Thanks for doing your part to keep our users safe! -- Jeremy Stanley

1 0

[nova][security-sig] Please revisit your open vulnerability report
by Jeremy Stanley 10 May '21

10 May '21

Please help the OpenStack Vulnerability Management Team by taking a look at the following report: tenant isolation is bypassed if port admin-state-up=false https://launchpad.net/bugs/1798904 Can it be exploited by a nefarious actor, and if so, how? Is it likely to be fixable in all our supported stable branches, respecting stable backport policy? What deployment configurations and options might determine whether a particular installation is susceptible? This is the sort of feedback we depend on to make determinations regarding whether and how to keep the public notified, so they can make informed decisions. Thanks for doing your part to keep our users safe! -- Jeremy Stanley

1 0

[neutron][security-sig] Please revisit your open vulnerability reports
by Jeremy Stanley 10 May '21

10 May '21

Please help the OpenStack Vulnerability Management Team by taking a look at the following reports: Anti-spoofing bypass using Open vSwitch (CVE-2021-20267) https://launchpad.net/bugs/1902917 Neutron RBAC not working for multiple extensions https://launchpad.net/bugs/1784259 tenant isolation is bypassed if port admin-state-up=false https://launchpad.net/bugs/1798904 non-IP ethertypes are permitted with iptables_hybrid firewall driver https://launchpad.net/bugs/1838473 RA Leak on tenant network https://launchpad.net/bugs/1844712 Anti-spoofing bypass https://launchpad.net/bugs/1884341 Can these be exploited by a nefarious actor, and if so, how? Are they likely to be fixable in all our supported stable branches, respecting stable backport policy? What deployment configurations and options might determine whether a particular installation is susceptible? This is the sort of feedback we depend on to make determinations regarding whether and how to keep the public notified, so they can make informed decisions. Thanks for doing your part to keep our users safe! -- Jeremy Stanley

1 0

[keystone][security-sig] Please revisit your open vulnerability report
by Jeremy Stanley 10 May '21

10 May '21

Please help the OpenStack Vulnerability Management Team by taking a look at the following report: PCI-DSS account lock out DoS and account UUID lookup oracle https://launchpad.net/bugs/1688137 Can it be exploited by a nefarious actor, and if so, how? Is it likely to be fixable in all our supported stable branches, respecting stable backport policy? What deployment configurations and options might determine whether a particular installation is susceptible? This is the sort of feedback we depend on to make determinations regarding whether and how to keep the public notified, so they can make informed decisions. Thanks for doing your part to keep our users safe! -- Jeremy Stanley

1 0

[horizon][security-sig] Please revisit your open vulnerability reports
by Jeremy Stanley 10 May '21

10 May '21

Please help the OpenStack Vulnerability Management Team by taking a look at the following reports: using glance v2 api does not remove temporary files https://launchpad.net/bugs/1674846 DOS : API_RESULT_LIMIT does not work for swift objects https://launchpad.net/bugs/1724598 XSS in adding JavaScript into the ‘Subnet Name’ field https://launchpad.net/bugs/1892848 Can these be exploited by a nefarious actor, and if so, how? Are they likely to be fixable in all our supported stable branches, respecting stable backport policy? What deployment configurations and options might determine whether a particular installation is susceptible? This is the sort of feedback we depend on to make determinations regarding whether and how to keep the public notified, so they can make informed decisions. Thanks for doing your part to keep our users safe! -- Jeremy Stanley

1 0

[glance][security-sig] Please revisit your open vulnerability report
by Jeremy Stanley 10 May '21

10 May '21

Please help the OpenStack Vulnerability Management Team by taking a look at the following report: default paste_deploy.flavor is none, but config file text implies it is 'keystone' (was: non-admin users can see all tenants' images even when image is private) https://launchpad.net/bugs/1799588 Can it be exploited by a nefarious actor, and if so, how? Is it likely to be fixable in all our supported stable branches, respecting stable backport policy? What deployment configurations and options might determine whether a particular installation is susceptible? This is the sort of feedback we depend on to make determinations regarding whether and how to keep the public notified, so they can make informed decisions. Thanks for doing your part to keep our users safe! -- Jeremy Stanley

1 0

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

10 May '21

Reminder that the next TripleO irc meeting is: ** Tuesday 11 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 Apr 27 - you can find the logs there http://eavesdrop.openstack.org/meetings/tripleo/2021/tripleo.2021-04-27-14.… Hope you can make it, regards, marios

1 0

[keystone] release notes for Victoria & wallaby?
by Ruby Loo 10 May '21

10 May '21

Hi, Where might I find out what changed in keystone in the wallaby release? I don't see any release notes for wallaby (or victoria) here: https://docs.openstack.org/releasenotes/keystone/. Thanks in advance, --ruby

2 2

[oslo] [tooz] Why does not tooz's tox env use upper-constraints?
by Radosław Piliszek 10 May '21

10 May '21

The question is the subject. Why does not tooz's tox env use upper-constraints? I asked this on IRC once some time ago but did not receive an answer so trying out ML as a more reliable medium. -yoctozepto

4 4

[nova] Getting compute nodes disabled by default
by Thomas Goirand 10 May '21

10 May '21

Hi Nova team, I was wondering if there was a way so that new compute nodes appear as disabled when they pop up. Indeed, the default workflow is that they first appear in the "nova" availability zone, and enabled by default. This doesn't really fit a production environment. I'd prefer if they could appear disabled, and if I had to enable them manually, when I'm finished running validity tests, and when my scripts have finished moving the new compute in the correct availability zone. Your thoughts? Cheers, Thomas Goirand (zigo)

2 2

[Multi-arch][SIG] Biweekly Meeting tomorrow at 0700 and 1500 UTC
by Rico Lin 10 May '21

10 May '21

Dear Multi-arch forks We will host our meeting tomorrow, please fill in the agenda [1] if you got anything you would like us to discuss about Here's our meeting schedule and location [2]: Tuesday at 0700 UTC in #openstack-meeting-alt Tuesday at 1500 UTC in #openstack-meeting [1] https://etherpad.opendev.org/p/Multi-Arch-agenda [2] http://eavesdrop.openstack.org/#Multi-Arch_SIG_Meeting *Rico Lin*

1 0

Nova db instance table node field where it comes from?
by Szabo, Istvan (Agoda) 09 May '21

09 May '21

Hello, Where this entry is coming from of an instance? I haven't found in the libvirt instance.xml and to be honest don't know where else to look. 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.

1 0

[heat] [aodh] [autoscaling] [openstack victoria] How to setup aodh and heat to auto scale in openstack victoria based on cpu usage?
by Swogat Pradhan 09 May '21

09 May '21

Hi, How to set up aodh and heat to auto scale in openstack victoria based on cpu usage? As the metric cpu_util is now deprecated, how can someone use heat to auto scale up and down using cpu usage of the instance? I checked the ceilometer package and I could see the transformers are removed so i can't see any other way to perform arithmetic operations and generate cpu usage in percentage. Any insight is appreciated. with regards Swogat pradhan

1 1

[os-net-config] add VLAN interface to OVS bridge
by Tony Liu 09 May '21

09 May '21

Hi, I want to have a VLAN interface on a OVS bridge without tagging. Can that be done by os-net-config? I tried couple things. 1) Define a VLAN interface as a member of OVS bridge. In this case, VLAN interface is created and added on OVS bridge, but with the tag of VLAN ID. ``` {"network_config": [ { "type": "ovs_bridge", "name": "br-test", "use_dhcp": false, "addresses": [{"ip_netmask": "10.250.1.5/24"}], "members": [ { "type": "vlan", "device": "eno4", "vlan_id": 100, "primary": true } ] } ]} ``` 2) Define a VLAN interface out of OVS bridge and reference that VLAN interface as the type of "interface" in the member. This doesn't work unless the VLAN interface exists before running os-net-config. ``` {"network_config": [ { "type": "vlan", "vlan_id": 100, "device": "eno4", "addresses": [{"ip_netmask": "10.250.1.5/24"}] }, { "type": "ovs_bridge", "name": "br-test", "use_dhcp": false, "members": [ { "type": "interface", "name": "vlan100", "primary": true } ] } ]} ``` Anything else I can try? Thanks! Tony

1 0

[tripleo] nic config sample for OVN
by Tony Liu 09 May '21

09 May '21

Hi, Could anyone share a nic configuration template for OVN? In my case, the external interface is a VLAN interface. Thanks! Tony

1 0

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

09 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: ------------------ ** Swift and Ironic added the 'assert:supports-standalone' tag. ** Update Nodejs Runtime to Nodejs14 From Nodejs10 for Xena Cycle[1] ** Reduced TC office hours to one per week[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-06-15.00.log.html * We will have next week's meeting on May 13th, 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 ----------------- * Two open reviews for ongoing activities[5]. Starting the 'Y' release naming process --------------------------------------------- * Governance patch is up to finalize the dates for Y release naming process[6] * https://wiki.openstack.org/wiki/Release_Naming/Y_Proposals Others --------- * Replacing ATC terminology with AC[7]. 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[8]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [9] 3. Office hours: The Technical Committee offers a weekly office hour every Tuesday at 0100 UTC [10] 4. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022247.html [2] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours [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] https://review.opendev.org/c/openstack/governance/+/789385 [7] https://review.opendev.org/c/openstack/governance/+/790092 [8] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [9] http://eavesdrop.openstack.org/#Technical_Committee_Meeting [10] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours -gmann

1 0

[puppet] Propose retiring puppet-glare
by Takashi Kajinami 09 May '21

09 May '21

Hello, I'd like to propose retiring puppet-galre project, because the Glare[1] project looks inactive for a while based on the following three points - No actual development is made for 2 years - No release was made since the last Rocky release - setup.cfg is not maintained and the python versions listed are very outdated [1] https://opendev.org/x/glare I'll wait for 1-2 weeks to hear opinions from others. If anybody is interested in keeping the puppet-glare project or has intention to maintain Glare itself then please let me know. Thank you, Takashi

4 5

[devstack][infra] POST_FAILURE on export-devstack-journal : Export journal
by Martin Kopec 09 May '21

09 May '21

Hi, one of our jobs (python-tempestconf project) is frequently failing with POST_FAILURE [1] during the following task: export-devstack-journal : Export journal I'm bringing this to a broader audience as we're not sure where exactly the issue might be. Did you encounter a similar issue lately or in the past? [1] https://zuul.opendev.org/t/openstack/builds?job_name=python-tempestconf-tem… Thanks for any advice, -- Martin Kopec

4 10

[TripleO] Closed out wallaby milestone in Launchpad and moved bugs to xena-1
by Marios Andreou 07 May '21

07 May '21

Hello, I closed out the wallaby-rc1 milestone in launchpad and moved ongoing bugs over to xena-1 https://launchpad.net/tripleo/+milestone/xena-1 - info on the moved bugs @ [1] Thanks to tosky for pinging on tripleo about this: there were problems a while back with gerrit <--> launchpad integration so there are likely many bugs that should be in fix-released but weren't moved automatically after the related patches merged. Please take a moment to check the bugs assigned to you in https://launchpad.net/tripleo/+milestone/xena-1 and make sure the status reflects reality? regards, marios [1] https://gist.github.com/marios/b3155fe3b1318cc26bfa4bc15c764a26#gistcomment…

1 1

Proposing Cédric Jeanneret (Tengu) for tripleo-core
by James Slagle 07 May '21

07 May '21

I'm proposing we formally promote Cédric to full tripleo-core duties. He is already in the gerrit group with the understanding that his +2 is for validations. His experience and contributions have grown a lot since then, and I'd like to see that +2 expanded to all of TripleO. If there are no objections, we'll consider the change official at the end of next week. -- -- James Slagle --

24 24

[horizon] Support for Angular 1.8.x in Horizon (fixing Debian Bullseye)
by Thomas Goirand 06 May '21

06 May '21

Hi, In Debian Bullseye, we've noticed that the ssh keypair and Glance image panels are broken. We have python3-xstatic-angular that used to depends on libjs-angularjs, and that libjs-angularjs moved to 1.8.2. Therefore, Horizon in Bullseye appears broken. I have re-embedded Angula within the python3-xstatic-angular and ask the Debian release team for an unblock, but due to the fact that the Debian policy is to *not* allow twice the same library with different versions, I have little hope for this unblock request to be approved. See the discussion here: https://bugs.debian.org/988054 So my question is: how hard would it be to fix Horizon so that it could work with libjs-angularjs 1.8.2 ? Is there any patch already available for this? Cheers, Thomas Goirand (zigo)

2 2

[interop][cinder] review of next.json
by Brian Rosmaita 06 May '21

06 May '21

Hello Interop WG, We began a review of next.json [0] at yesterday's cinder meeting and a few issues came up. 1. The 'description' for the volumes capabilities should be updated; here's a patch: https://review.opendev.org/c/osf/interop/+/789940 2. Are capabilities that require an admin (or system-scoped) token still excluded? 3. Are capabilities that require multiple users for testing (for example, volume transfer) excluded? Thanks! [0] https://opendev.org/osf/interop/src/branch/master/next.json

2 1

[openstack-ansible] Keystone federation with OpenID needs shibboleth
by Taltavull Jean-Francois 06 May '21

06 May '21

Hi All, I'm trying to make keystone federation with openid connect work on an Ubuntu 20.04 + Victoria cloud deployed with OSA. Despite the fact that I use openid, shibboleth seems to be involved and I had to add "ShibCompatValidUser On" directive to the file "/etc/apache2/conf-available/shib.conf", by hand in the keystone lxc container, in order to successfully authenticate ("valid user: granted" an not "valid user: denied" in apache log file). Has anyone already experienced this use case ? Thanks and best regards, Jean-Francois

2 6

[cinder] save the date for xena midcycles
by Brian Rosmaita 06 May '21

06 May '21

At yesterday's cinder meeting, we selected the times for our virtual midcycles: midcycle-1: week R-18, Wednesday 2 June 2021, 1400-1600 UTC midcycle-2: week R-9, Wednesday 4 August 2021, 1400-1600 UTC Use this etherpad to propose topics: https://etherpad.opendev.org/p/cinder-xena-mid-cycles Connection info will be posted on the etherpad closer to the date of each midcycle. The midcycles will be recorded. cheers, brian

1 0

[devstack][installation] Trouble with devstack installation
by Lana DI NOIA 06 May '21

06 May '21

Hello, I encounter the following error when I run stack.sh: ERROR: Editable requirements are not allowed as constraints ++./stack.sh:main:752 err_trap ++./stack.sh:err_trap:530 local r=1 stack.sh failed: full log in /opt/stack/logs/stack.sh.log.2021-05-06-115934 Error on exit And a little higher I have this warning Attempting uninstall: pip Found existing installation: pip 21.1.1 Uninstalling pip-21.1.1: Successfully uninstalled pip-21.1.1 Successfully installed pip-21.1.1 WARNING: Running pip as root will break packages and permissions. You should install packages reliably by using venv: https://pip.pypa.io/warnings/venv Any idea why? Thanks

1 0

[largescale-sig] Next meeting: May 5, 15utc
by Thierry Carrez 06 May '21

06 May '21

Hi everyone, Our next Large Scale SIG meeting will be this Wednesday in #openstack-meeting-3 on IRC, at 15UTC. You can doublecheck how it translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20210505T15 A number of topics have already been added to the agenda, including discussing our OpenInfra.Live show on May 20. Feel free to add other topics to our agenda at: https://etherpad.openstack.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

1 1

[ironic] RFC: abandon sushy-cli?
by Dmitry Tantsur 06 May '21

06 May '21

Hi ironicers, sushy-cli was an attempt to create a redfish CLI based on sushy. The effort stopped long ago, and the project hasn't had a single meaningful change since Ussuri. There is an official Redfish CLI from DMTF, I don't think we have cycles to maintain an alternative one. If you would like to maintain sushy-cli, please speak up! Dmitry -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

4 3

Rocky Linux for Openstack
by Wada Akor 06 May '21

06 May '21

Good day , Please I want to know when will openstack provide information on how to installation of openstack on Rocky Linux be available. Thanks & Regards

7 8

[manila][ptg] Xena PTG Summary
by Goutham Pacha Ravi 06 May '21

06 May '21

Hello Zorillas, and other interested Stackers! Sorry this is getting to you later than usual :) We concluded a productive Project Team Gathering on 23rd Apr '21. I'd like to thank everyone that participated as well as the friendly folks at the OpenInfra Foundation who worked hard to organize this event. The following is my summary of the proceedings. I've linked associated etherpads and resources to dig in further. Please feel free to follow up here or on freenode's #openstack-manila if you have any questions. == Day 1 - Apr 19, 2021, Mon == === Manila Retrospective === Topic Etherpad: https://etherpad.opendev.org/p/manila-wallaby-retrospective - interns and their mentors did a great job through Wallaby! Many accomplishments, thanks to the sponsoring organizations for their investment - the two Bugsquash events at M1 and M3 were very effective. - we added new core members (python-manilaclient, manila-tempest-plugin) - sub-teams (manila-ui, manilaclient and manila-tempest-plugin) increased focus on the individual projects and sped up reviews - good cross project collaboration with OpenStack QA, Horizon, NFS-Ganesha and Ceph communities - we discussed strategies to avoid reviewer burnout and performed health checks on the team growth initiatives we took up in the Wallaby cycle Actions: - need to get proactive about reviews so we can avoid burn-out at the end of the cycle - continue bug squash days in Xena - look for interested contributors to join the core maintainer team - bring up reviews in weekly meetings and assign review owners earlier than M-2 - contributors need to be reminded to help with reviews == Day 3 - Apr 21, 2021, Wed == === manila-tempest-plugin plans and update === - lkuchlan and vhari highlighted difficulties around "capabilities" testing that was exposed due to feature changes in the CephFS driver in the Wallaby cycle - optional feature testing requires rework, the configuration options and test strategy have gotten confusing over time - discussion continued on dropping testing for older API microversions where some optional features (snapshots, snapshot cloning) weren't really optional. It was agreed that this was overkill. The problem is specifically in share type extra-specs. If these are setup with API version >= 2.24, we could circumvent this: https://review.opendev.org/c/openstack/manila-tempest-plugin/+/785307. The only issue is that tests could theoretically be run against a cloud that doesn't support API version 2.24 (has to be Newton release or older). The team agreed that we could document this deficiency in the configuration file since Newton release has been EOL for a while. Actions: - review and merge the fix to share type extra-specs - rework existing "run_XYZZY_tests" and "capability_XYZZY_support" flags to "share-feature-enabled" section where these capabilities are always set when a feature is enabled - this is in-line with the way optional feature testing for other OpenStack services is done === Service Recovery === Topic Etherpad: https://etherpad.opendev.org/p/xena-ptg-manila-share-recovery-polling - gouthamr discussed the use cases and architectures needing to run manila-share in active-active HA - service recovery after failure needs to be coordinated to prevent metadata corruption - clustering services will provide coordination for cleanup - vendor driver authors will need to audit critical sections and replace oslo.concurrency locks with distributed locks. Actions: - there will be a specification submitted for review === Polling operations in manila-share === Topic Etherpad: https://etherpad.opendev.org/p/xena-ptg-manila-share-recovery-polling - haixin and gouthamr summarized the periodic tasks conducted by the share manager service - to update share service capabilities and real time capacity information, - to monitor the health of share replicas, - to "watch" the progress of long running clone, snapshot and migration operations. - these periodic tasks will be inefficiently duplicated if running across multiple nodes associated with the same backend storage system/driver - many of these periodic tasks are meant to be read-only, however, the health-check operations modify database state, currently these assume a single writer, and unless staggered, updates may be duplicated as well - proposed mitigation was to allow clustered hosts to ignore polling operations if one is in progress elsewhere, and for the service instance executing the tasks to distribute the workload to other hosts via the message queue - another issue with periodic tasks was the lack of ability to stop an unnecessary task from running - we could take advantage of oslo's threadgroup that exposes a start/stop API Actions: - replace loopingcall periodic tasks with threadgroups to selectively run periodic tasks - propose a specification to coordinate and distribute polling workloads === Interop Working Group === - arkady_kanevsky presented the mission of the InteropWG, and laid out plans for the upcoming Interop guideline - manila tests were added to the guideline as part of the 2020.11 guideline and have been available for the community to provide results - there was an optional capability (shrinking shares) that was flagged, and the team discussed if it was to remain flagged, or be moved to an advisory state - including reduction of the cutoff score - the team wants to stabilize the tests exposed through the next guideline, and work on a way to remove the necessity of an admin user to bootstrap the manila's tempest tests where unnecessary Actions: - improve manila tempest plugin to not request admin credentials for the tests exposed, and work with a configured "default" share type === Share server migration improvements === - share server migration was added as an experimental feature in the Victoria release - carloss presented use cases for nondisruptive share server migration - nondisruptive migration would mean that network changes are unnecessary, so the share manager needn't seek out any new network ports or relinquish existing ones - the share server migration is experimental, however, we'd still make nondisruptive migration possible only from a new API microversion - manual triggering of the second phase is still necessary to allow control of the cutover/switchover. All resources will continue to be tagged busy until the migration has been completed Actions: - no specification is necessary because the changes to the API and core manila are expected to be minimal === OpenStackSDK and Manila === - ashrod98, NicoleBU and markypharaoh, seniors at Boston University worked through the past cycle to expose manila resources to the OpenStackSDK - an outreachy internship proposal has been submitted to continue their work to expose more API functionality via the SDK - we'd prioritize common elements - quotas, limits and availability zones so we can parallely work on the OpenStackClient and Horizon implementation for these - need review attention on the patches Actions: - some domain reviewers for manila patches to be added to the OpenStackSDK core team to help with reviews == Day 4 - Apr 22, 2021, Thu == === Support soft delete/recycle bin functionality === - haixin told us that inspur cloud has a "soft-delete" functionality that they would like to contribute to upstream manila - the functionality allows users to recover deleted shares within a configurable time zone via Manila API - the proposal is to only allow soft-deletion and recovery of shares, but in the future this can be extended to other resources such as snapshots, replicas, share groups - soft deletions have the same validations as deletions currently do - quota implications and alternatives (unmanage, an system admin API) were discussed Actions: - a specification will be proposed for this work === New Driver Requirements and CI knowledge sharing === - there was a informative presentation from the Cinder PTG [3] about using Software Factory to deploy a Third Party CI system with Gerrit, Nodepool, Zuulv3 and other components - some helpful but unmaintained test hook code exists in the repos to aid with CI systems using devstack-gate - since devstack-gate has been deprecated for a long time, third party CIs are strongly recommended to move away from it Actions: - complete removal of devstack-gate related manila-tempest-plugin installation from manila's devstack plugin - create a Third Party CI and help wiki/doc that vendor driver maintainers can curate and contribute to === New Driver for Dell EMC PowerStore === - vb123 discussed Dell EMC powerstore storage, its capabilities and their work in cinder, and made a proposal for a driver in manila - this driver's being targeted for the Xena release: https://blueprints.launchpad.net/manila/+spec/powerstore-manila-driver - community shared updates and documentation from the Victoria and Wallaby cycles that may be helpful to the driver authors - driver submission deadlines have been published: https://releases.openstack.org/xena/schedule.html === Enabling access allow/deny for container driver with LDAP === - esantos and carloss enabled the container driver in the Wallaby release to support addition of and updates to LDAP security services - however, this work was just intended to expose a reference implementation to security services - the container driver does not validate access rules applied with the LDAP server today - the proposal is to enable validation in the driver when a security service is configured Actions: - publish container driver helper image to the manila-image-elements repository and explore container registries that community can use for the long term for CI and dev/test - file a bug and fix the missing LDAP validation in the container share driver === Keystone based user/cephx authentication === - "cephx" (CEPHFS) access types are not validated beyond their structure and syntax - with cephx access, an access key for the ceph client user can be retrieved via the access-list API call - access keys are privileged information, while we've always had a stance that Native CephFS is only suitable in trusted tenant environments, there's a desire to hide access keys from unrelated users in the project - gouthamr proposed that we allow deployers to choose if Keystone user identity validation must be performed - when validation is enabled, manila ensures that users may only allow share access to other users in their project - users may only retrieve access keys belonging to themselves, and no other project users - an alternative would be to keystone validation would be to allow controlling the access_key via a separate RBAC policy - with the alternative, we wouldn't be able to validate if the access to user is in the same project as the user requesting the access Actions: - a specification will be proposed, however, the work's not expected to be prioritized for Xena === Addressing Technical Debt === - we discussed tech debt that was piling up from the last couple of cycles and assigned owners to drive them to completion in the Xena cycle Actions: - python-manilaclient still relies on keystoneclient to perform auth, there's ongoing work from vkmc+gouthamr to replace this with keystoneauth [4] - code in manila relies on the retrying python library that is no longer maintained; kiwi36 will propose replacing the usage with tenacity with tbarron's help [5] - tbarron will be resurrecting a patch that removes old deprecated configuration options [6] - carloss will be picking up rootwrap-to-privsep migration === Unified Limits === Topic Etherpad: https://etherpad.opendev.org/p/unified-limits-ptg - kiwi36, our Outreachy intern, proposed the design for using keystone's unified limits in manila with the help of the oslo.limit library - he walked through the prototype using resource quotas and highlighted the differences with the current quota system - we discussed why nested quotas were preferable to user quotas Actions: - a release independent specification will be proposed for the community to review and continue this work - explore how share type quotas will be handled === Secure RBAC Follow up === - vhari presented the RBAC changes that were made in the Wallaby release, including support for the system scope and reader role - a tempest test strategy was discussed, along with improvements made to tempest itself to make test credential setup with the new default roles - there's no plan to enforce the new defaults in Xena, we'll take the release to stabilize the feature and turn on deprecation warnings indicating intent to switch to the new defaults in the Y release Actions: - vhari and lkuchlan will start working on the tempest tests - wrap up known issues with the new defaults and backport fixes to the Wallaby release - manila's admin model and user personas will be documented == Day 5 - Apr 23, 2021, Fri == === VirtIOFS plans and update === Topic Etherpad: https://etherpad.opendev.org/p/nova-manila-virtio-fs-support-xptg-april-2021 - tbarron and lyarwood presented an update on the research that was done in the wallaby release wrt live attaching virtiofs volumes to running compute instances - qemu supports live attaches, the feature is coming to libvirt soon. live migration of instances with virtiofs volumes isn't supported yet - this is ongoing work in the qemu/kvm/libvirt communities - we discussed the connection initiation and information exchange between manila and nova, and what parts will be coordinated via the os-share library - there are as yet no anticipated changes to the manila API Actions: - continue working with the libvirt community to have the live-attach APIs added - a specification will be proposed to nova (and manila if changes are necessary to the manila API) === CephFS driver update === Topic Etherpad: https://etherpad.opendev.org/p/cephfs-driver-update-xena-ptg - vkmc presented the changes and new features in the cephfs driver in the wallaby cycle - the driver was overhauled to interact with ceph via the ceph-mgr daemon instead of the deprecated ceph_volume_client library - there's an upgrade impact going from victoria to wallaby. Deployers must consult the release notes [7] and the ceph driver documentation [8] prior to upgrading. Data path operations are unaffected during an upgrade: - ceph clusters must be running the latest version of the release they're on to allow the wallaby manila driver to communicate with the ceph cluster - the ceph user configured with the driver needs mgr "caps", and mds/osd privileges can be dropped/reduced [8] - we discussed dropping the use of dbus in the nfs-ganesha module, and using the "watch-url" approach that ganesha's ceph-fsal module provides - we also discussed ceph-adm and ceph-orch based deployment which replaces ceph-ansible and the impact that would have on ganesha configuration - ceph quincy will support active/active nfs-ganesha clusters (even with ceph-adm based deployment), we discussed manila side changes to take advantage of this feature === manilaclient and OpenStackClient plans and update === Topic Etherpad: https://etherpad.opendev.org/p/manila-osc-xena-ptg - maaritamm provided an update on our multi-cycle effort to gain parity between manila's shell client and the osc plugin - we made great progress in the wallaby cycle and covered all "user" related functionality that was requested - we discussed what's left, and sought community priority of the missing commands - we discussed deprecation of the manila shell client and only supporting the osc plugin - albeit addressing the "standalone" use case where "manila" can be used in place of "openstack share" if users desire - we could use help to add new commands, and to review code in the osc plugin Actions: - achieve complete feature parity between the two shell client implementations, deprecate the manila shell client === manila-ui plans and update === Topic Etherpad: https://etherpad.opendev.org/p/manila-ui-update-xena-ptg - disap, our Outreachy intern and vkmc, highlighted the changes made in the wallaby cycle - we lauded the cross-project collaboration that was renewed in this cycle to triage issues, and proactively work on incoming changes in horizon and elsewhere - manila-ui's microversion catchup is progressing slowly, but surely - we have another outreachy project proposal that overlaps with the xena cycle Actions: - continue to catch up to API feature functionality in the UI Thanks for staying with me so far! :) There were a number of items that we couldn't cover, that you can see on the PTG Planning etherpad [1], if you own those topics, please add them to the weekly IRC meeting agenda [2] and we can go over them. The meeting minutes etherpad continues to be available [9]. As usual, the whole PTG was recorded and posted on the OpenStack Manila Youtube channel [10] We had a great turn out and we heard from a diverse set of contributors, operators, interns and users from several affiliations and time zones. On behalf of the OpenStack Manila team, I deeply appreciate your time, and help in keeping the momentum on the project! Best, gouthamr [1] https://etherpad.opendev.org/p/xena-ptg-manila-planning [2] https://wiki.openstack.org/wiki/Manila/Meetings [3] https://www.youtube.com/watch?v=hVLpPBldn7g [4] https://review.opendev.org/647538 [5] https://review.opendev.org/380552 [6] https://review.opendev.org/745206/ [7] https://docs.openstack.org/releasenotes/manila/wallaby.html <https://docs.openstack.org/releasenotes/manila/wallaby.html> [8] https://docs.openstack.org/manila/wallaby/admin/cephfs_driver.html [9] https://etherpad.opendev.org/p/xena-ptg-manila [10] https://www.youtube.com/playlist?list=PLnpzT0InFrqDmsKKsF0MQKtv9fP4Oik17

1 0

[neutron] Drivers team meeting 07.05.2021 cancelled
by Slawek Kaplonski 06 May '21

06 May '21

Hi, Due to lack of new RFEs and any other topics, let's cancel tomorrow's meeting. Please use that time to review some of the already proposed specs: https:// review.opendev.org/q/project:openstack/neutron-specs+status:open[1] See You online :) -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] https://review.opendev.org/q/project:openstack/neutron-specs+status:open

1 0

[Octavia] 2021-05-12 weekly meeting cancelled
by Gregory Thiemonge 05 May '21

05 May '21

Hi, I'll be on PTO next Wednesday, I won't be able to run the meeting. We decided during yesterday's meeting that next week meeting is cancelled, Thanks, Greg

1 0

[wallaby][magnum] magnum-conductor Service down
by Ammad Syed 05 May '21

05 May '21

Hi, I am experiencing a problem in magnum 12.0.0 that conductor service randomly goes down. I am using ubuntu 20.04. root@controller ~(keystone_ubuntu20_new)# openstack coe service list +----+------+------------------+-------+----------+-----------------+---------------------------+---------------------------+ | id | host | binary | state | disabled | disabled_reason | created_at | updated_at | +----+------+------------------+-------+----------+-----------------+---------------------------+---------------------------+ | 1 | None | magnum-conductor | down | False | None | 2021-05-03T10:33:16+00:00 | 2021-05-05T21:48:39+00:00 | +----+------+------------------+-------+----------+-----------------+---------------------------+---------------------------+ checking the logs of last updated timestamp in /var/log/syslog. I have found below error. May 5 21:49:29 orchestration magnum-conductor[10827]: /usr/lib/python3/dist-packages/magnum/drivers/common/driver.py:38: PkgResourcesDeprecationWarning: Parameters to load are deprecated. Call .resolve and .require separately. May 5 21:49:29 orchestration magnum-conductor[10827]: yield entry_point, entry_point.load(require=False) May 5 21:49:29 orchestration magnum-conductor[10827]: /usr/lib/python3/dist-packages/kubernetes/client/apis/__init__.py:10: DeprecationWarning: The package kubernetes.client.apis is renamed and deprecated, use kubernetes.client.api instead (please note that the trailing s was removed). May 5 21:49:29 orchestration magnum-conductor[10827]: warnings.warn( May 5 21:49:29 orchestration magnum-conductor[10827]: /usr/lib/python3/dist-packages/magnum/drivers/common/driver.py:38: PkgResourcesDeprecationWarning: Parameters to load are deprecated. Call .resolve and .require separately. May 5 21:49:29 orchestration magnum-conductor[10827]: yield entry_point, entry_point.load(require=False) May 5 21:49:29 orchestration magnum-conductor[10827]: Traceback (most recent call last): May 5 21:49:29 orchestration magnum-conductor[10827]: File "/usr/lib/python3/dist-packages/eventlet/hubs/hub.py", line 476, in fire_timers May 5 21:49:29 orchestration magnum-conductor[10827]: timer() May 5 21:49:29 orchestration magnum-conductor[10827]: File "/usr/lib/python3/dist-packages/eventlet/hubs/timer.py", line 59, in __call__ May 5 21:49:29 orchestration magnum-conductor[10827]: cb(*args, **kw) May 5 21:49:29 orchestration magnum-conductor[10827]: File "/usr/lib/python3/dist-packages/eventlet/semaphore.py", line 152, in _do_acquire May 5 21:49:29 orchestration magnum-conductor[10827]: waiter.switch() May 5 21:49:29 orchestration magnum-conductor[10827]: greenlet.error: cannot switch to a different thread There is no logs in magnum-conductor.log after the last updated timestamp of conductor service. The service looks running if I see in ps -ef | grep magnum-conductor. - Ammad

1 0

[wallaby][neutron][ovn] Distributed FIP
by Malik Obaid 05 May '21

05 May '21

Hi, I am using Openstack Wallaby release on Ubuntu 20.04. I have enabled DVR and Distributed FIP on 1 controller node and 2 compute nodes, we have mapped an interface(ens224) with the physical network(br-eth1) using below command: ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth1 The issue I am facing here is that when I analyze the traffic on interface (ens224) while initializing ping from a VM on my compute node 1, it shows the traffic flowing through my controller as well as both the compute nodes rather than only flowing through compute node 1. I would really appreciate any input in this regard. Thank you. Regards, Malik Obaid

1 0

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

05 May '21

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

1 1

[ptl][release][stable][EM] Extended Maintenance - Train
by Előd Illés 05 May '21

05 May '21

Hi, As Wallaby was released the day before yesterday and we are in a less busy period, it is a good opportunity to call your attention to the following: In less than a month Train is planned to transition to Extended Maintenance phase [1] (planned date: 2021-05-12). I have generated the list of the current *open* and *unreleased* changes in stable/train for the follows-policy tagged repositories [2] (where there are such patches). These lists could help the teams who are planning to do a *final* release on Train before moving stable/train branches to Extended Maintenance. Feel free to edit and extend these lists to track your progress! * At the transition date the Release Team will tag the*latest* (Train) *releases* of repositories with *train-em* tag. * After the transition stable/train will be still open for bug fixes, but there won't be any official releases. NOTE: teams, please focus on wrapping up your libraries first if there is any concern about the changes, in order to avoid broken releases! Thanks, Előd [1] https://releases.openstack.org/ [2] https://etherpad.opendev.org/p/train-final-release-before-em

1 1

[TripleO] stable/wallaby branch for tripleo repos \o/ ping if problems :)
by Marios Andreou 05 May '21

05 May '21

Hello tripleo o/ now that https://review.opendev.org/c/openstack/releases/+/789558 merged (thanks elod & hberaud for reviews) we have a stable/wallaby branch for all tripleo repos (list at [1]). Note that for python-tripleoclient & tripleo-common the branch was previously created with [2] as part of our testing and preparation. Special thank you to all those involved from the tripleo-ci team - rlandy, baghyashris, ysandeep, ananya (frenzy_friday), pojadav and apologies to those I missed. Preparations started at least six weeks ago (i.e. the previous 2 sprints). If you are interested in our prep work there are some notes and pointers at [3]. So: * stable/wallaby for tripleo repos is now a thing \o/ * go ahead and post patches to stable/wallaby (you'll need those .gitreview things to merge first like [4]) * If there are issues with CI please reach out to tripleo-ci in freenode #tripleo or #oooq - especially ping the persons with |ruck or |rover in the irc nickname [5] I'll deal with the launchpad side of things next (moving ongoing bugs over from wallaby-rc1 to xena-1 etc), regards, marios [1] https://releases.openstack.org/teams/tripleo.html#wallaby [2] http://lists.openstack.org/pipermail/openstack-discuss/2021-April/021741.ht… [3] https://hackmd.io/2sxlx1XzTa-Te47_zLv42Q?view [4] https://review.opendev.org/c/openstack/tripleo-heat-templates/+/789889 [5] https://docs.openstack.org/tripleo-docs/latest/ci/ruck_rover_primer.html

2 2

[TripleO] stable/wallaby branching
by Marios Andreou 05 May '21

05 May '21

Hello TripleO, quick update on the plan for stable/wallaby branching. The goal is to release tripleo stable/wallaby just after PTG i.e. last week of April. The tripleo-ci team have spent the previous sprint preparing and we now have the integration and component pipelines in place [1][2]. As of today we should also have the upstream check/gate multinode branchful jobs. We are planning to use this current sprint to resolve issues and ensure we have the CI coverage in place so we can safely release all the tripleo things. As we usually do, we are going to first branch python-tripleoclient and tripleo-common so we can exercise and sanity check the CI jobs. The stable/wallaby for client and common will appear after we merge [3]. *** PLEASE AVOID *** posting patches to stable/wallaby python-tripleoclient or tripleo-common until the CI team has completed our testing. Basically until we are ready to create a stable/wallaby for all the tripleo things (which will be announced in due course). Obviously as always please speak up if you disagree with any of the above or if something doesn't make sense or if you have any concerns about the proposed timings regards, marios [1] https://review.rdoproject.org/zuul/builds?pipeline=openstack-periodic-integ… [2] https://review.rdoproject.org/zuul/builds?pipeline=openstack-component-trip… [3] https://review.opendev.org/c/openstack/releases/+/785670

1 1

[infra] Retiring the LimeSurvey instance at survey.openstack.org
by Jeremy Stanley 05 May '21

05 May '21

We are retiring our beta-test LimeSurvey service that was running on survey.openstack.org, as well as decommissioning the server itself, some time later today. Our survey service never saw production use. It was a compelling idea, but the prevalence of free surveys-as-a-service options (a number of which are built with open source software) meant that the only real benefit to running our own was that we didn't need to entrust the response data to third party organizations. As a result, there's been very limited use of the offering and in order to redirect our limited time and resources to services where we can provide the most benefit to our communities, we're ending this one. -- Jeremy Stanley

1 0