- openstack-discuss - lists.openstack.org

[baremetal-sig][ironic] Tue Dec 8, 2pm UTC: Ironic and Redfish Interop Profiles
by Arne Wiebalck 04 Dec '20

04 Dec '20

Dear all, The Bare Metal SIG will meet on Tue Dec 8 at 2pm UTC. This time there will be a 10 minute "topic-of-the-day" presentation by Richard Pioso: 'An Introduction to Ironic Redfish Interoperability Profiles' So, if you would like to learn how to validate if hardware is fit for use with Redfish and Ironic, find all the details for this meeting on the SIG's etherpad: https://etherpad.opendev.org/p/bare-metal-sig Everyone is welcome, don't miss out! Cheers, Arne

2 1

[rdo][centos8] OVS and OVN packages
by Tony Liu 04 Dec '20

04 Dec '20

Hi, I see OVN package ovn2.13-central-20.09.0-2.el8.x86_64.rpm and OVS in openvswitch2.13-2.13.0-60.el8.x86_64.rpm [1]. But I can't find them in [2]. Where are they built? Which source package is it based, [3] and [4]? [1] http://mirror.centos.org/centos/8/nfv/x86_64/openvswitch-2/Packages/o/ [2] https://cbs.centos.org/koji/packages [3] https://github.com/ovn-org/ovn/archive/v20.09.0.tar.gz [4] https://github.com/openvswitch/ovs/archive/v2.13.1.tar.gz Thanks! Tony

2 2

[ironic] : Third-party ML2 plugins for Openstack ironic with virtual networks
by fsbiz＠yahoo.com 04 Dec '20

04 Dec '20

Is anyone using virtual networks for their Openstack Ironic installations? Our flat network is now past 3000 nodes and I am investigating Arista's ML2 plugin and / or Mellanox's NEO as the ML2 plugin. In addition to scaling we also have additional requirements like provisioning a bare-metal serverin a conference room away from the DC for demo purposes. I have general questions on whether anyone is actually using the above two (or any other ML2 plugins)with their Openstack ironic installations ? Thanks,Fred.

2 1

devstack multinode: MTU tag not sent in Libvirt XML created from Nova
by Shashi, Yatindra 04 Dec '20

04 Dec '20

Hi All, I am using devstack-train version. Can you guys tell me which source file or function should I look when I get mtu size in the network-info but not in the libvirtxml parsed like below log Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: DEBUG nova.network.os_vif_util [None req-31d5b683-9e85-455e-95fd-b110de636fe4 admin admin] Converting VIF {"id": "d0358b23-d96b-4394-969d-32858b60e261", "addre ss": "fa:16:3e:46:97:e0", "network": {"id": "991289bb-6794-4673-b32c-e0f2296a8949", "bridge": "br-int", "label": "shared", "subnets": [{"cidr": "192.168.233.0/24", "dns": [], "gateway": {"address": "192.168.233.1 ", "type": "gateway", "version": 4, "meta": {}}, "ips": [{"address": "192.168.233.237", "type": "fixed", "version": 4, "meta": {}, "floating_ips": []}], "routes": [], "version": 4, "meta": {"dhcp_server": "192.16 8.233.2"}}], "meta": {"injected": false, "tenant_id": "ac158184024043faba836ec3d347d0d7", "mtu": 1450, "physical_network": null, "tunneled": true}}, "type": "ovs", "details": {"connectivity": "l2", "port_filter": true, "ovs_hybrid_plug": false, "datapath_type": "system", "bridge_name": "br-int"}, "devname": "tapd0358b23-d9", "ovs_interfaceid": "d0358b23-d96b-4394-969d-32858b60e261", "qbh_params": null, "qbg_params": null , "active": false, "vnic_type": "normal", "profile": {}, "preserve_on_delete": false, "meta": {}} {{(pid=8579) nova_to_osvif_vif /opt/stack/nova/nova/network/os_vif_util.py:516}} Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: DEBUG nova.network.os_vif_util [None req-31d5b683-9e85-455e-95fd-b110de636fe4 admin admin] Converted object VIFOpenVSwitch(active=False,address=fa:16:3e:46:97: e0,bridge_name='br-int',has_traffic_filtering=True,id=d0358b23-d96b-4394-969d-32858b60e261,network=Network(991289bb-6794-4673-b32c-e0f2296a8949),plugin='ovs',port_profile=VIFPortProfileOpenVSwitch,preserve_on_del ete=False,vif_name='tapd0358b23-d9') {{(pid=8579) nova_to_osvif_vif /opt/stack/nova/nova/network/os_vif_util.py:553}} Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: DEBUG nova.objects.instance [None req-31d5b683-9e85-455e-95fd-b110de636fe4 admin admin] Lazy-loading 'pci_devices' on Instance uuid 997103d3-0a60-4ce2-a85d-c42 eb24cfd8b {{(pid=8579) obj_load_attr /opt/stack/nova/nova/objects/instance.py:1090}} Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: DEBUG nova.virt.libvirt.driver [None req-31d5b683-9e85-455e-95fd-b110de636fe4 admin admin] [instance: 997103d3-0a60-4ce2-a85d-c42eb24cfd8b] End _get_guest_xml xml=<domain type="acrn"> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <uuid>997103d3-0a60-4ce2-a85d-c42eb24cfd8b</uuid> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <name>instance-00000001</name> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <memory>1048576</memory> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <vcpu>1</vcpu> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <metadata> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <nova:instance xmlns:nova="http://openstack.org/xmlns/libvirt/nova/1.0"> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <nova:package version="20.1.2"/> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <nova:name>cl_acrn</nova:name> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <nova:creationTime>2020-12-04 09:11:22</nova:creationTime> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <nova:flavor name="ds1G"> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <nova:memory>1024</nova:memory> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <nova:disk>10</nova:disk> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <nova:swap>0</nova:swap> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <nova:ephemeral>0</nova:ephemeral> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <nova:vcpus>1</nova:vcpus> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: </nova:flavor> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <nova:owner> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <nova:user uuid="b4646b0d513645c8ab6d0656b2e699ed">admin</nova:user> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <nova:project uuid="ac158184024043faba836ec3d347d0d7">admin</nova:project> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: </nova:owner> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <nova:root type="image" uuid="b3464729-fdb5-435e-9eff-3525760afa5b"/> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: </nova:instance> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: </metadata> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <os> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <type>hvm</type> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <loader>/usr/share/acrn/bios/OVMF.fd</loader> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <boot dev="hd"/> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: </os> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <features> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <acpi/> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <apic/> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: </features> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <clock offset="utc"/> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <devices> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <disk type="file" device="disk"> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <driver type="raw" cache="none"/> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <source file="/opt/stack/data/nova/instances/997103d3-0a60-4ce2-a85d-c42eb24cfd8b/disk"/> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <target dev="vda" bus="virtio"/> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: </disk> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <interface type="bridge"> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <mac address="fa:16:3e:46:97:e0"/> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <model type="virtio"/> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <source bridge="br-int"/> --> Why no mtu set in xml Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <target dev="tapd0358b23-d9"/> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <virtualport type="openvswitch"> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: <parameters interfaceid="d0358b23-d96b-4394-969d-32858b60e261"/> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: </virtualport> Dez 04 10:11:22 acrn1-NUC7i7DNHE nova-compute[8579]: </interface> : I checked the solution mentioned in [ https://bugs.launchpad.net/nova/+bug/1747496] and the source code which it said to add is already in my nova code. Anyone have any suggestions? Mit freundlichen Grüßen/ with best regards, Yatindra Shashi IoTG DE- Intel Corporation Munich, Germany Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Gary Kershaw Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928

1 0

[release] Release countdown for week R-19, Nov 30 - Dec 04
by Herve Beraud 03 Dec '20

03 Dec '20

Greetings Everyone! Development Focus ----------------- We are now past the Wallaby-1 milestone. Teams should now be focused on feature development and completion of release cycle goals [0]. [0] https://governance.openstack.org/tc/goals/selected/wallaby/index.html General Information ------------------- Our next milestone in this development cycle will be Wallaby-2, on 21 January, 2021. This milestone is when we freeze the list of deliverables that will be included in the Wallaby final release, so if you plan to introduce new deliverables in this release, please propose a change to add an empty deliverable file in the deliverables/wallaby directory of the openstack/releases repository. Now is also generally a good time to look at bugfixes that were introduced in the master branch that might make sense to be backported and released in a stable release. If you have any question around the OpenStack release process, feel free to ask on this mailing-list or on the #openstack-release channel on IRC. Upcoming Deadlines & Dates -------------------------- Cinder Spec Freeze: 18 December, 2020 Manila Spec Freeze: 25 December, 2020 Wallaby-2 Milestone: 21 January, 2021 Hervé Beraud (hberaud) and the Release Management Team -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 0

[Interop]
by Kanevsky, Arkady 03 Dec '20

03 Dec '20

Team, I looked at https://www.openstack.org/brand/interop/. Looks like it had not been touched for a while. It does not list any add-on powered program. But it does list latest approved 2020.06 guidelines. Should we add it a verbiage for orchestration and DNS add-ons? And shortly about file system. Thanks, Arkady Kanevsky, Ph.D. SP Chief Technologist & DE Dell EMC office of CTO Dell Inc. One Dell Way, MS PS2-91 Round Rock, TX 78682, USA Phone: 512 7204955

2 4

[tripleo] wallaby-1 milestone and open specs
by Marios Andreou 03 Dec '20

03 Dec '20

Hi TripleO a reminder that this week is the Wallaby-1 milestone. As discussed at the last tripleo irc meeting [1] we should merge all specs by wallaby-1 if we are going to realistically deliver those things during W. Some specs have now merged and if you didn't already do so you can read them at [2]. There are still a few that are in review [3]. Call to all core reviewers please try and find time to review those over the next few days, in particular: network ports v2 @ [4], frrouter/bgp @ [5] and ephemeral heat [6]. Proposers of those specs please try respond quickly to reviewer comments so we can merge asap. thank you marios [1] http://eavesdrop.openstack.org/meetings/tripleo/2020/tripleo.2020-11-24-14.… [2] https://opendev.org/openstack/tripleo-specs/src/branch/master/specs/wallaby [3] https://review.opendev.org/q/project:openstack/tripleo-specs+status:open [4] https://review.opendev.org/c/openstack/tripleo-specs/+/760536 [5] https://review.opendev.org/c/openstack/tripleo-specs/+/758249 [6] https://review.opendev.org/c/openstack/tripleo-specs/+/765000

2 1

[neutron][stable] Backport of the patch which bumps RPC version
by Slawek Kaplonski 03 Dec '20

03 Dec '20

Hi, Some time ago we backported in Neutron patch [1] which caused bug [2]. Patch [1] was merged in the Ussuri development cycle so it is already in Ussuri and Victoria. Our mistake was that we merged it then without bump of the RPC version and without code which would provide backward compatybility between old agent and new neutron-server and that's why [2] happens. Now, as we know that, we have proposed patch [3] to fix it in master branch. And my question is - can we backport fix [3] to the stable/victoria and stable/ ussuri to fix the original issue caused by [1] there? In general I know that we shouldn't do that but here are the reasons why we would like to do it in this specific case: - rpc version which we want to change now wasn't changed since Train at least so there will be no any conflict with that, - bump rpc version now and provide backward compatybility on neutron-server will make upgrades Train->Ussuri and minor updates in Ussuri easier as there will be no similar issue like is described in [2] anymore, - patch [1] was already included in Ussuri and Victoria from master branch, it wasn't really cherry-picked there so it actually should be there since the beginning. Based on those reasons mentioned about and also becuase in general it is forbiden by stable policy to backport changes like that to stable branches I would like to know opinion from wider community, especially stable-core-maint team, about what would be the best approach to fix that issue: backport of [3] to stable/{ussuri,victoria} or revert [1] in stable/{ussuri,victoria}. [1] https://review.opendev.org/c/openstack/neutron/+/712632 [2] https://bugs.launchpad.net/neutron/+bug/1903531 [3] https://review.opendev.org/c/openstack/neutron/+/764108 -- Slawek Kaplonski Principal Software Engineer Red Hat

2 2

[neutron] default(ish) firewall rules
by Vladimir Prokofev 03 Dec '20

03 Dec '20

Hello. I'm running Queens private cloud with few separate projects inside. Guests in those projects have 2 networks - public, which is a provider network with public IP addresses, and private which is a VXLAN overlay network specific to the project. That's the setup, now here's the issue. They're mostly Windows guests there, and they tend to have browser service enabled on both public and private networks. This leads to situations where guests from one project can see guests in other projects over a public network via NetBIOS/SMB protocols, which is undesirable. I have two partial solutions in mind. Create some default firewall rule, similar to that exists by default for DHCP protocol that prohibit guests to act as DHCP server, but for UDP 137-139 port range. But not only I completely forgot how to do this(I think I saw some documentation about it ~2 years ago), but this will also block said protocol over private networks too, which is not an ideal solution. I would still love it if someone could point me to a proper documentation here. Second option is to add similar entries to security group rules. This will allow public/private interface differentiation by applying different security group to different interfaces, but introduces the possibility for cloud operator to delete those entries(either by mistake, or explicitly) which will lead to protocol being allowed once again. Anyone has any idea of a better solution here?

2 3

[tripleo] next meeting Tuesday Dec 08 @ 1400 UTC in #tripleo
by Marios Andreou 03 Dec '20

03 Dec '20

The next scheduled TripleO irc meeting is ** Tuesday 08th December at 1400 UTC in #tripleo. ** ** https://etherpad.opendev.org/p/tripleo-meeting-items ** Please add anything you want to raise at https://etherpad.opendev.org/p/tripleo-meeting-items This could be anything including review requests, blocking issues or to socialise ongoing or planned work. Our last meeting was held on Nov 24th - you can find the logs there http://eavesdrop.openstack.org/meetings/tripleo/2020/tripleo.2020-11-24-14.… thanks, marios

1 0

[ussuri] [neutron] deploy an additional compute node that resides in a different network
by Pavlos Basaras 03 Dec '20

03 Dec '20

1 1

[neutron] Drivers meeting agenda for 04.12.2020
by Slawek Kaplonski 03 Dec '20

03 Dec '20

Hi, Agenda for drivers meeting [1] this week have to new RFEs to discuss: * https://bugs.launchpad.net/neutron/+bug/1905115 * https://bugs.launchpad.net/neutron/+bug/1905295 And there is also "on demand" topic added by Rodolfo: "Smart-Nic Management Overall Design" (Nova spec). Neutron needs to add a new extension to provide to Nova the device profile information. This is a new string parameter added to the port blob and should be included when the port is created. Reference: https://review.opendev.org/c/openstack/nova-specs/+/742785/12/specs/wallaby… Rodolfo - is Your topic related to the RFE https://bugs.launchpad.net/neutron/+bug/1906602 ? See You tomorrow on the meeting :) [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers#Agenda -- Slawek Kaplonski Principal Software Engineer Red Hat

2 1

Re: [all] Dynamic Zuul results table in Gerrit 3
by Radosław Piliszek 03 Dec '20

03 Dec '20

On Thu, Dec 3, 2020 at 10:33 AM Marcin Juszkiewicz <marcin.juszkiewicz(a)linaro.org> wrote: > > W dniu 03.12.2020 o 10:22, Radosław Piliszek pisze: > > Hello Fellow OpenStack and OpenDev Folks! > > > > TL;DR click on [3] and enjoy. > > Rename to *.user.js so Tampermonkey will recognize it as userscript and > add window around with Install button. > I, personally, hate this "feature" of Tampermonkey but sure - if it makes it easier for you. ;-) Done. Anyone - just click on "Raw" and you will be pestered by Tampermonkey to install the script. > > However, inspired by gibi's work, I decided to finally sit down and > > fix it to work with Gerrit 3 and here it comes: [3]. > > Works well on Chrome with Tampermonkey. Not tested others. > > Firefox with Tampermonkey - script works. > Yay, thanks for confirming! > > I hope you will enjoy this little helper (I do). > > Nice job! > Well, thank you! :-) > It does not catch all Zuul jobs. For Kolla patches AArch64 jobs are not > listed. I have already replied on IRC but will repeat here for others. The dynamic part includes all the running queues. However, the static part parses only a single comment and AArch64 is in a different one. I am obviously biased (being x86-only folk) but I find it more problematic than worth it to hack it any further. I hope a proper solution arrives sooner. :-) > > I know the script looks super fugly but it generally boils down to a > > mix of styles of 3 people and Gerrit having funky UI rendering. > > > Finally, I'd also like to thank hrw (Marcin Juszkiewicz) for linking > > me to the original Michel's script in 2019. > > YW. > -yoctozepto

1 0

[CLOUDKITTY] - Prometheus metrics.yml sample?
by Gaël THEROND 02 Dec '20

02 Dec '20

Hi everyone, I'm currently finishing our cloudkitty implementation, but I'm facing an issue. For now, our cloudkitty-processor process raise a traceback like this: http://paste.openstack.org/show/Y2ZiYPtZSKzvZk93yNWC/ I can't find any reliable documentation describing how to use prometheus with cloudkitty, so I'm kind of using the guess/read the code way to integrate it, but I'm a bit confused so far. My current metric.yml look like this: http://paste.openstack.org/show/6X23ZfVm1iDMruGy3Gpp/ I've created the appropriate group/service/threshold etc but it still continues to raise the same error. I'm using this openstack_exporter: https://github.com/openstack-exporter/openstack-exporter/releases/tag/v1.1.0 I'm running a Train release Openstack platform if it can help. So, if anyone is having a successful cloudkitty/prometheus integration willing to give a hand, I'll be more than happy ;-) Thanks!

1 0

[largescale-sig] Next meeting: December 2, 15utc
by Thierry Carrez 02 Dec '20

02 Dec '20

Hi everyone, We'll have a Large Scale SIG meeting 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=20201202T15 Our main topic will be to discuss how to best collect operator scaling experiences. Feel free to add other topics to our agenda at: https://etherpad.openstack.org/p/large-scale-sig-meeting Talk to you all later, -- Thierry Carrez

1 1

IRONIC BAREMETAL partitioned image not spawning.
by Akshay 346 02 Dec '20

02 Dec '20

Hello Team, I hope you all are keeping safe and doing good. I have a OpenStack setup up and running with ironic enabled. I am able to spawn a bare metal node with centos8.2 whole-disk image but when I spawn bare metal with partitioned image, it fails to spawn it stating the following trace ( Full trace back attached in the email): "2020-12-01 12:35:34.603 1 ERROR ironic.conductor.utils [req-0d3a375e-90a3-485d-a7c3-895c97c88006 - - - - -] Deploy failed for instance 463bd844-7f80-4c57-98dd-6ca8cfdb6121. Error: [Errno 2] No such file or directory: 'sgdisk': 'sgdisk': FileNotFoundError: [Errno 2] No such file or directory: 'sgdisk': 'sgdisk'". I have also installed sgdisk (yum install gdisk) on the qcow2 from which I build the partitioned image. Can anyone please guide how to debug it? Regards Akshay DISCLAIMER: This electronic message and all of its contents, contains information which is privileged, confidential or otherwise protected from disclosure. The information contained in this electronic mail transmission is intended for use only by the individual or entity to which it is addressed. If you are not the intended recipient or may have received this electronic mail transmission in error, please notify the sender immediately and delete / destroy all copies of this electronic mail transmission without disclosing, copying, distributing, forwarding, printing or retaining any part of it. Hughes Systique accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus.

2 4

[kolla] cannot pull docker public hub images
by Adrian Andreias 02 Dec '20

02 Dec '20

Hi, None of the Kolla images on the Docker public registry are tagged. E.g. https://hub.docker.com/r/kolla/centos-source-nova-api Images don't even have the "latest" tag, though they were updated 15 hours ago. And therefore they can't be pulled: $ docker pull kolla/centos-source-nova-api Using default tag: latest Error response from daemon: manifest for kolla/centos-source-nova-api:latest not found: manifest unknown: manifest unknown Is there another public registry where ready-built Kolla images are available? Thanks Regards, Adrian Andreias https://fleio.com

4 6

Re: [neutron][openstack-ansible] Instances can only connect to provider-net via tenant-net but not directly
by Oliver Wenz 02 Dec '20

02 Dec '20

> Neutron sends this notification to the nova-api so You should check in nova-api > logs. > Whole workflow for that process of spawning vm is more or less like below: > 1. nova-compute asks neutron for port, > 2. neutron creates port and binds it with some mechanism driver - so it has > vif_type e.g. "ovs" or "linuxbridge" or some other, > 3. nova, based on that vif details plugs port to the proper bridge on host and > pauses instance until neutron will not do its job, > 4. neutron-l2-agent (linuxbrige or ovs) starts provisioning port and reports > to neutron-server when it is done, > 5. if there is no any provisioning blocks for that port in neutron db (can be > also one from the dhcp agent), neutron sends notification to nova-api that port > is ready, > 6. nova unpauses vm. > > In Your case it seems that on step 5 nova reports some error and that You > should IMO check. > Hi Slawek, thanks for the information and suggestion! I checked the nova-api-os-compute logs and it seems like there are network problems and an issue with wrong token scope: Dec 02 11:15:49 infra1-nova-api-container-83af52a6 nova-api-wsgi[84]: 2020-12-02 11:15:49.074 84 INFO nova.api.openstack.requestlog [req-1d56ad1c-03ea-4dcc-b9da-e4f6e73ccc52 920e739127a14018a55fb4422b0885e7 0f14905dab5546e0adec2b56c0f6be88 - default default] 192.168.110.201 "GET /v2.1/servers/2a1f6fbf-48f8-4e7f-bc36-7162bdaf7e20" status: 200 len: 1358 microversion: 2.1 time: 0.500669 Dec 02 11:15:49 infra1-nova-api-container-83af52a6 nova-api-wsgi[86]: 2020-12-02 11:15:49.256 86 INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: [Errno 104] Connection reset by peer Dec 02 11:15:49 infra1-nova-api-container-83af52a6 uwsgi[48]: Wed Dec 2 11:15:49 2020 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request /v2.1/flavors/7c20746e-f6db-4344-9aa1-be926696ecf4 (ip 192.168.110.201) !!! Dec 02 11:15:49 infra1-nova-api-container-83af52a6 nova-api-wsgi[86]: 2020-12-02 11:15:49.318 86 INFO nova.api.openstack.requestlog [req-832f794d-db9b-4690-bb0c-8320e7beed47 920e739127a14018a55fb4422b0885e7 0f14905dab5546e0adec2b56c0f6be88 - default default] 192.168.110.201 "GET /v2.1/flavors/7c20746e-f6db-4344-9aa1-be926696ecf4" status: 200 len: 473 microversion: 2.1 time: 0.095833 Dec 02 11:15:57 infra1-nova-api-container-83af52a6 nova-api-wsgi[79]: 2020-12-02 11:15:57.000 79 INFO nova.api.openstack.requestlog [req-2c061260-88f4-4183-a74a-ea59d1ff1ae0 b044fe42a4644837a3bd40beec378876 226e9c9f1fb94c8ab271490ad79c6873 - default default] 192.168.110.201 "HEAD /" status: 200 len: 417 microversion: - time: 0.001837 Dec 02 11:15:57 infra1-nova-api-container-83af52a6 nova-api-wsgi[88]: 2020-12-02 11:15:57.214 88 INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: [Errno 104] Connection reset by peer Dec 02 11:15:57 infra1-nova-api-container-83af52a6 uwsgi[48]: Wed Dec 2 11:15:57 2020 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request /v2.1/os-server-external-events (ip 192.168.110.201) !!! Dec 02 11:15:57 infra1-nova-api-container-83af52a6 uwsgi[48]: /openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/oslo_policy/policy.py:1007: UserWarning: Policy os_compute_api:os-server-external-events:create failed scope check. The token used to make the request was project scoped but the policy requires ['system'] scope. This behavior may change in the future where using the intended scope is required Dec 02 11:15:57 infra1-nova-api-container-83af52a6 uwsgi[48]: warnings.warn(msg) Dec 02 11:15:57 infra1-nova-api-container-83af52a6 nova-api-wsgi[88]: 2020-12-02 11:15:57.715 88 INFO nova.api.openstack.compute.server_external_events [req-759c5752-c80b-46f2-b3df-0fa126605895 d9a2e96567ec4670bc60dbcc8f66305f 474b7aa9b7894d6782402135c6ef4c2a - default default] Creating event network-changed:ed4a9455-a33c-454c-b74f-b314751cce3d for instance 2a1f6fbf-48f8-4e7f-bc36-7162bdaf7e20 on bc1blade15 Dec 02 11:15:57 infra1-nova-api-container-83af52a6 nova-api-wsgi[88]: 2020-12-02 11:15:57.734 88 INFO nova.api.openstack.requestlog [req-759c5752-c80b-46f2-b3df-0fa126605895 d9a2e96567ec4670bc60dbcc8f66305f 474b7aa9b7894d6782402135c6ef4c2a - default default] 192.168.110.201 "POST /v2.1/os-server-external-events" status: 200 len: 179 microversion: 2.1 time: 0.533910 Dec 02 11:16:09 infra1-nova-api-container-83af52a6 nova-api-wsgi[82]: 2020-12-02 11:16:09.007 82 INFO nova.api.openstack.requestlog [req-064600c9-196e-4388-978c-00b0f5560b2e 745ecbee83d041c6ba92f9e07ba744d5 a2fd11a3bfdd47c8893e18a6f3b7dfa3 - default default] 192.168.110.201 "HEAD /" status: 200 len: 417 microversion: - time: 0.001638 Dec 02 11:16:16 infra1-nova-api-container-83af52a6 nova-api-wsgi[77]: 2020-12-02 11:16:16.432 77 INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: [Errno 104] Connection reset by peer Dec 02 11:16:16 infra1-nova-api-container-83af52a6 uwsgi[48]: Wed Dec 2 11:16:16 2020 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request /v2.1/os-server-external-events (ip 192.168.110.201) !!! Dec 02 11:16:16 infra1-nova-api-container-83af52a6 uwsgi[48]: /openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/oslo_policy/policy.py:1007: UserWarning: Policy os_compute_api:os-server-external-events:create failed scope check. The token used to make the request was project scoped but the policy requires ['system'] scope. This behavior may change in the future where using the intended scope is required Dec 02 11:16:16 infra1-nova-api-container-83af52a6 uwsgi[48]: warnings.warn(msg) Dec 02 11:16:16 infra1-nova-api-container-83af52a6 nova-api-wsgi[77]: 2020-12-02 11:16:16.939 77 INFO nova.api.openstack.compute.server_external_events [req-71a40ea1-cf64-46d5-9675-d00d539f1922 d9a2e96567ec4670bc60dbcc8f66305f 474b7aa9b7894d6782402135c6ef4c2a - default default] Creating event network-vif-plugged:5cbc8608-8545-4eb3-a745-23ca912347ec for instance ea72988b-83eb-4640-adaa-e24e0c3d018d on bc1blade15 Dec 02 11:16:16 infra1-nova-api-container-83af52a6 nova-api-wsgi[77]: 2020-12-02 11:16:16.958 77 INFO nova.api.openstack.requestlog [req-71a40ea1-cf64-46d5-9675-d00d539f1922 d9a2e96567ec4670bc60dbcc8f66305f 474b7aa9b7894d6782402135c6ef4c2a - default default] 192.168.110.201 "POST /v2.1/os-server-external-events" status: 200 len: 183 microversion: 2.1 time: 0.526920 Dec 02 11:16:17 infra1-nova-api-container-83af52a6 nova-api-wsgi[71]: 2020-12-02 11:16:17.422 71 INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: [Errno 104] Connection reset by peer Kind regards, Oliver

2 1

[Openstack][CFP] Virtualization & IaaS Devroom
by Piotr Kliczewski 02 Dec '20

02 Dec '20

We are excited to announce that the call for proposals is now open for the Virtualization & IaaS devroom at the upcoming FOSDEM 2021, to be hosted virtually on February 6th 2021. This year will mark FOSDEM’s 21th anniversary as one of the longest-running free and open source software developer events, attracting thousands of developers and users from all over the world. Due to Covid-19, FOSDEM will be held virtually this year on February 6th & 7th, 2021. About the Devroom The Virtualization & IaaS devroom will feature session topics such as open source hypervisors and virtual machine managers such as Xen Project, KVM, bhyve, and VirtualBox, and Infrastructure-as-a-Service projects such as KubeVirt, Apache CloudStack, Foreman, OpenStack, oVirt, QEMU and OpenNebula. This devroom will host presentations that focus on topics of shared interest, such as KVM; libvirt; shared storage; virtualized networking; cloud security; clustering and high availability; interfacing with multiple hypervisors; hyperconverged deployments; and scaling across hundreds or thousands of servers. Presentations in this devroom will be aimed at users or developers working on these platforms who are looking to collaborate and improve shared infrastructure or solve common problems. We seek topics that encourage dialog between projects and continued work post-FOSDEM. Important Dates Submission deadline: 20th of December Acceptance notifications: 25th of December Final schedule announcement: 31st of December Recorded presentations upload deadline: 15th of January Devroom: 6th February 2021 Submit Your Proposal All submissions must be made via the Pentabarf event planning site[1]. If you have not used Pentabarf before, you will need to create an account. If you submitted proposals for FOSDEM in previous years, you can use your existing account. After creating the account, select Create Event to start the submission process. Make sure to select Virtualization and IaaS devroom from the Track list. Please fill out all the required fields, and provide a meaningful abstract and description of your proposed session. Submission Guidelines We expect more proposals than we can possibly accept, so it is vitally important that you submit your proposal on or before the deadline. Late submissions are unlikely to be considered. All presentation slots are 30 minutes, with 20 minutes planned for presentations, and 10 minutes for Q&A. All presentations will need to be pre-recorded and put into our system at least a couple of weeks before the event. The presentations should be uploaded by 15th of January and made available under Creative Commons licenses. In the Submission notes field, please indicate that you agree that your presentation will be licensed under the CC-By-SA-4.0 or CC-By-4.0 license and that you agree to have your presentation recorded. For example: "If my presentation is accepted for FOSDEM, I hereby agree to license all recordings, slides, and other associated materials under the Creative Commons Attribution Share-Alike 4.0 International License. Sincerely, <NAME>." In the Submission notes field, please also confirm that if your talk is accepted, you will be able to attend the virtual FOSDEM event for the Q&A. We will not consider proposals from prospective speakers who are unsure whether they will be able to attend the FOSDEM virtual event. If you are experiencing problems with Pentabarf, the proposal submission interface, or have other questions, you can email our devroom mailing list[2] and we will try to help you. Code of Conduct Following the release of the updated code of conduct for FOSDEM, we'd like to remind all speakers and attendees that all of the presentations and discussions in our devroom are held under the guidelines set in the CoC and we expect attendees, speakers, and volunteers to follow the CoC at all times. If you submit a proposal and it is accepted, you will be required to confirm that you accept the FOSDEM CoC. If you have any questions about the CoC or wish to have one of the devroom organizers review your presentation slides or any other content for CoC compliance, please email us and we will do our best to assist you. Call for Volunteers We are also looking for volunteers to help run the devroom. We need assistance with helping speakers to record the presentation as well as helping with streaming and chat moderation for the devroom. Please contact devroom mailing list [2] for more information. Questions? If you have any questions about this devroom, please send your questions to our devroom mailing list. You can also subscribe to the list to receive updates about important dates, session announcements, and to connect with other attendees. See you all at FOSDEM! [1] <https://penta.fosdem.org/submission/FOSDEM17>https://penta.fosdem .org/submission/FOSDEM21 [2] iaas-virt-devroom at lists.fosdem.org

2 1

[tacker] Please check my slide for the discussion with ETSI-NFV
by Yoshito Ito 01 Dec '20

01 Dec '20

Hi tacker team, As I mentioned in the previous IRC meeting, I uploaded my slide [1] for the discussion with ETSI NFV members. The meeting will be held on 4th Dec so I hope you to put your comments or questions on the etherpad [2] soon. [1] https://www2.slideshare.net/secret/zQLlzi7wwJ5FGQ [2] https://etherpad.opendev.org/p/tacker-meeting Thanks, Yoshito Ito

1 0

[tc] weekly update + meeting
by Mohammed Naser 01 Dec '20

01 Dec '20

Hi everyone, Here's an update for what happened in the OpenStack TC this week. You can get more information by checking for changes in openstack/governance repository. # Patches ## Open Reviews - Remove Qinling project team https://review.opendev.org/c/openstack/governance/+/764523 - Clarify the requirements for supports-api-interoperability https://review.opendev.org/c/openstack/governance/+/760562 - Add Resolution of TC stance on the OpenStackClient https://review.opendev.org/c/openstack/governance/+/759904 - Remove Searchlight project team https://review.opendev.org/c/openstack/governance/+/764530 - Update example and oslo code usage in JSON->YAML goal https://review.opendev.org/c/openstack/governance/+/764261 - Remove already done use-builtin-mock from goal https://review.opendev.org/c/openstack/governance/+/764262 - Generate the TC liaisons assignments https://review.opendev.org/c/openstack/governance/+/763810 - Add assert:supports-standalone https://review.opendev.org/c/openstack/governance/+/722399 - Remove assert_supports-zero-downtime-upgrade tag https://review.opendev.org/c/openstack/governance/+/761975 - Clarify impact on releases for SIGs https://review.opendev.org/c/openstack/governance/+/752699## General Changes - Correct Dan Smith IRC nick in TC liaisons https://review.opendev.org/c/openstack/governance/+/763809 - Propose Kendall Nelson for vice chair https://review.opendev.org/c/openstack/governance/+/762014 - Add election schedule exceptions in charter https://review.opendev.org/c/openstack/governance/+/751941 ## Project Updates - Add Magpie charm to OpenStack charms https://review.opendev.org/c/openstack/governance/+/762820 ## Other Reminders - [TC] Weekly meeting December 03. If you would like to add topics for discussion, please go to https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting and fill out your suggestions by Wednesday, December 02, at 2100 UTC. Thanks for reading! Mohammed & Kendall -- Mohammed Naser VEXXHOST, Inc.

1 0

[neutron] Team meeting agenda
by Slawek Kaplonski 01 Dec '20

01 Dec '20

Hi neutrinos, Just quick reminder that today at 2pm UTC we will have out weekly team meeting. Agenda is available at [1]. If You have anything to discuss there, please add it to the "On demand" section there. [1] https://wiki.openstack.org/wiki/Network/Meetings -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[neutron] bug deputy report Nov 23-29
by Oleg Bondarev 01 Dec '20

01 Dec '20

Please find new bugs summary for the week Nov 23-27. Nothing critical. 2 RFEs for neutron drivers team to discuss. High: - https://bugs.launchpad.net/neutron/+bug/1905700 - [OVN] ovn-metadata-agent: "RowNotFound: Cannot find Chassis with name..." when starting the agent - Gate failure - fix approved: https://review.opendev.org/c/openstack/neutron/+/764318 - https://bugs.launchpad.net/neutron/+bug/1905726 - Qos plugin performs too many queries - fixes on review: - https://review.opendev.org/c/openstack/neutron/+/764433 - https://review.opendev.org/c/openstack/neutron/+/764454 Medium: - https://bugs.launchpad.net/neutron/+bug/1905271 - [OVS] Polling cycle continuously interrupted by L2 population (when enabled) - fix on review: https://review.opendev.org/c/openstack/neutron/+/755313 - https://bugs.launchpad.net/neutron/+bug/1905551 - functional: test_gateway_chassis_rebalance fails - Unassigned - https://bugs.launchpad.net/neutron/+bug/1905568 - Sanity checks missing port_name while adding tunnel port - fix approved: https://review.opendev.org/c/openstack/neutron/+/764171 - https://bugs.launchpad.net/neutron/+bug/1905611 - OVN.ovsdb_probe_interval takes effect only after initial database dump - Unassigned Low: - https://bugs.launchpad.net/neutron/+bug/1905538 - Some OVS bridges may lack OpenFlow10 protocol - fix on review: https://review.opendev.org/c/openstack/neutron/+/764150 Wishlist: - https://bugs.launchpad.net/neutron/+bug/1905276 - Overriding hypervisor name for resource provider always requires a complete list of interfaces/bridges - fix on review - https://review.opendev.org/c/openstack/neutron/+/763563 - https://bugs.launchpad.net/neutron/+bug/1905268 - port list performance for trunks can be optimized - fix on review - https://review.opendev.org/c/openstack/neutron/+/763777 RFEs: - https://bugs.launchpad.net/neutron/+bug/1905295 - [RFE] Allow multiple external gateways on a router - https://bugs.launchpad.net/neutron/+bug/1905391 - [RFE] VPNaaS support for OVN Won't fix: - https://bugs.launchpad.net/neutron/+bug/1905552 - neutron-fwaas netlink conntrack driver would catch error while conntrack rules protocol is 'unknown' - fwaas is not supported Expired Bugs: - https://bugs.launchpad.net/bugs/1896592 - [neutron-tempest-plugin] test_dhcpv6_stateless_* clashing when creating a IPv6 subnet - https://bugs.launchpad.net/bugs/1853632 - designate dns driver does not use domain settings for auth Thanks, Oleg --- Advanced Software Technology Lab Huawei

2 1

[cinder] Project ID in cinder endpoints and system scopes
by Nicolas Parquet 01 Dec '20

01 Dec '20

Hello there, Wondering if anyone has ongoing work or information on the following bug: https://bugs.launchpad.net/keystone/+bug/1745905 We tried removing the project_id from cinder endpoints in order to test system scopes and see if more is needed than oslo policy configuration, but cannot get anything else than 404 responses. The bug description suggests it is just a documentation issue, but I could not get a working setup. I also don't this mentioned in ptg documentation regarding system scopes support. Any information or hint is welcome! Regards, -- Nicolas Parquet Gandi nicolas.parquet(a)gandi.net

2 2

nova novnc timeout
by Ankele zhang 30 Nov '20

30 Nov '20

Hello~ I have a OpenStack Rocky platform. My nova.cfg has configured "[consoleauth] token_ttl=360000 [workarounds] enable_consoleauth=true", I get the console url and access my VM console in web. the console url invalid after two or one minutes not 360000s. How can I resolve this? Look forward to hearing from you. Ankele!

2 2

[tripleo][ci] cm2 pip failures
by Wesley Hayutin 30 Nov '20

30 Nov '20

Greetings, FYI.. https://bugs.launchpad.net/tripleo/+bug/1906265 0/

2 2

[qa][all] pip 20.3 breaks jobs
by Balázs Gibizer 30 Nov '20

30 Nov '20

Hi, Today pip 20.3 is released[1] and jobs started failing during keystone install in devstack with: 2020-11-30 15:14:31.117 | + inc/python:pip_install:193 : sudo -H LC_ALL=en_US.UTF-8 SETUPTOOLS_USE_DISTUTILS=stdlib http_proxy= https_proxy= no_proxy= PIP_FIND_LINKS= SETUPTOOLS_SYS_PATH_TECHNIQUE=rewrite python3.6 -m pip install -c /opt/stack/old/requirements/upper-constraints.txt -e /opt/stack/old/neutron 2020-11-30 15:14:32.271 | Looking in indexes: https://mirror.gra1.ovh.opendev.org/pypi/simple, https://mirror.gra1.ovh.opendev.org/wheel/ubuntu-18.04-x86_64 2020-11-30 15:14:32.272 | DEPRECATION: Constraints are only allowed to take the form of a package name and a version specifier. Other forms were originally permitted as an accident of the implementation, but were undocumented. The new implementation of the resolver no longer supports these forms. A possible replacement is replacing the constraint with a requirement.. You can find discussion regarding this at https://github.com/pypa/pip/issues/8210. 2020-11-30 15:14:32.272 | ERROR: Links are not allowed as constraints Logstash signature: [2] It seems not all the jobs are effected but at least grenade on master is hit [3]. It seems that passing jobs are using pip from the base image instead of installing a fresh one from pypi. As a first glance the change "Flip the switch on new resolver"[4] seem to be related. Cheers, gibi [1] https://pip.pypa.io/en/stable/news/#id1 [2] http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3… [3] https://zuul.opendev.org/t/openstack/builds?job_name=grenade&branch=master [4] https://github.com/pypa/pip/pull/9019

3 2

senlin SR-IOV instance support
by Satish Patel 30 Nov '20

30 Nov '20

Folks, Does senlin support instance type SRIOV, I am successfully able to deploy using standard vm using virtio but for sriov instance we need to create a neutron port and then attach that port to VM. How does that process work with senlin? Currently I have the following profile: (if i want sriov instance then what i need to do?) type: os.nova.server version: 1.0 properties: name: cirros_server flavor: m1.small image: "cirros" key_name: ssh-key networks: - network: net1 metadata: test_key: test_value user_data: | #!/bin/sh echo 'hello, world' > /tmp/test_file ~S

2 2

[devstack][ussuri][keystone] ERROR: Links are not allowed as constraints
by Neil Jerram 30 Nov '20

30 Nov '20

With devstack pinned to stable/ussuri, on Ubuntu Bionic, stack.sh fails for me when it gets to the step of installing keystone: ... + lib/keystone:install_keystone:500 : setup_develop /opt/stack/keystone + inc/python:setup_develop:351 : local bindep + inc/python:setup_develop:352 : [[ /opt/stack/keystone == -bindep* ]] + inc/python:setup_develop:356 : local project_dir=/opt/stack/keystone + inc/python:setup_develop:357 : local extras= + inc/python:setup_develop:358 : _setup_package_with_constraints_edit /opt/stack/keystone -e + inc/python:_setup_package_with_constraints_edit:377 : local bindep + inc/python:_setup_package_with_constraints_edit:378 : [[ /opt/stack/keystone == -bindep* ]] + inc/python:_setup_package_with_constraints_edit:382 : local project_dir=/opt/stack/keystone + inc/python:_setup_package_with_constraints_edit:383 : local flags=-e + inc/python:_setup_package_with_constraints_edit:384 : local extras= ++ inc/python:_setup_package_with_constraints_edit:391 : cd /opt/stack/keystone ++ inc/python:_setup_package_with_constraints_edit:391 : pwd + inc/python:_setup_package_with_constraints_edit:391 : project_dir=/opt/stack/keystone + inc/python:_setup_package_with_constraints_edit:393 : '[' -n /opt/stack/requirements ']' + inc/python:_setup_package_with_constraints_edit:395 : local name ++ inc/python:_setup_package_with_constraints_edit:396 : awk '/^name.*=/ {print $3}' /opt/stack/keystone/setup.cfg + inc/python:_setup_package_with_constraints_edit:396 : name=keystone + inc/python:_setup_package_with_constraints_edit:398 : /opt/stack/requirements/.venv/bin/edit-constraints /opt/stack/requirements/upper-constraints.txt -- keystone '-e file:///opt/stack/keystone#egg=keystone' + inc/python:_setup_package_with_constraints_edit:402 : setup_package /opt/stack/keystone -e + inc/python:setup_package:430 : local bindep=0 + inc/python:setup_package:431 : local bindep_flag= + inc/python:setup_package:432 : local bindep_profiles= + inc/python:setup_package:433 : [[ /opt/stack/keystone == -bindep* ]] + inc/python:setup_package:438 : local project_dir=/opt/stack/keystone + inc/python:setup_package:439 : local flags=-e + inc/python:setup_package:440 : local extras= + inc/python:setup_package:444 : [[ -n -e ]] + inc/python:setup_package:444 : [[ -z '' ]] + inc/python:setup_package:444 : [[ ! -e =~ ^-.* ]] + inc/python:setup_package:449 : [[ ! -z '' ]] + inc/python:setup_package:454 : [[ 0 == 1 ]] + inc/python:setup_package:458 : pip_install -e /opt/stack/keystone Using python 3.6 to install /opt/stack/keystone because python3_enabled=True + inc/python:pip_install:200 : sudo -H LC_ALL=en_US.UTF-8 SETUPTOOLS_USE_DISTUTILS=stdlib http_proxy= https_proxy= no_proxy= PIP_FIND_LINKS= SETUPTOOLS_SYS_PATH_TECHNIQUE=rewrite /usr/local/bin/pip3.6 install -c /opt/stack/requirements/upper-constraints.txt -e /opt/stack/keystone WARNING: The directory '/home/semaphore/.pip_download_cache' or its parent directory is not owned or is not writable by the current user. The cache has been disabled. Check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag. DEPRECATION: Constraints are only allowed to take the form of a package name and a version specifier. Other forms were originally permitted as an accident of the implementation, but were undocumented. The new implementation of the resolver no longer supports these forms. A possible replacement is replacing the constraint with a requirement.. You can find discussion regarding this at https://github.com/pypa/pip/issues/8210. ERROR: Links are not allowed as constraints As far as I can work out, it's because install_keystone edits /opt/stack/requirements/upper-constraints.txt so that the line for keystone has "-e file:///opt/stack/keystone#egg=keystone", and pip then complains that file:// constraints are not supported. I'm sure there's a good reason but - as is often the case - I'm left wondering why this isn't broken for everyone! Any clues or suggestions gratefully received. Neil

1 0

OVS-DPDK poor performance with Intel 82599
by Satish Patel 30 Nov '20

30 Nov '20

Folks, I am playing with DPDK on my openstack with NIC model 82599 and seeing poor performance, i may be wrong with my numbers so want to see what the community thinks about these results. Compute node hardware: CPU: Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz Memory: 64G NIC: Intel 82599 (dual 10G port) [root@compute-lxb-3 ~]# ovs-vswitchd --version ovs-vswitchd (Open vSwitch) 2.13.2 DPDK 19.11.3 VM dpdk (DUT): 8vCPU / 8GB memory I have configured my computer node for all best practice available on the internet to get more performance out. 1. Used isolcpus to islocate CPUs 2. 4 dedicated core for PMD 3. echo isolated_cores=1,9,25,33 >> /etc/tuned/cpu-partitioning-variables.conf 4. Huge pages 5. CPU pinning for VM 6. increase ( ovs-vsctl set interface dpdk-1 options:n_rxq=4 ) 7. VM virtio_ring = 1024 After doing all above I am getting the following result using the Trex packet generator using 64B UDP stream (Total-PPS : 391.93 Kpps) Do you think it's an acceptable result or should it be higher on these NIC models? On the internet folks say it should be a million packets per second so not sure what and how those people reached there or i am missing something in my load test profile. Notes: I am using 8vCPU core on VM do you think adding more cores will help? OR should i add more PMD? Cpu Utilization : 2.2 % 1.8 Gb/core Platform_factor : 1.0 Total-Tx : 200.67 Mbps Total-Rx : 200.67 Mbps Total-PPS : 391.93 Kpps Total-CPS : 391.89 Kcps Expected-PPS : 700.00 Kpps Expected-CPS : 700.00 Kcps Expected-BPS : 358.40 Mbps This is my all configuration: grub.conf: GRUB_CMDLINE_LINUX="vmalloc=384M crashkernel=auto rd.lvm.lv=rootvg01/lv01 console=ttyS1,118200 rhgb quiet intel_iommu=on iommu=pt spectre_v2=off nopti pti=off nospec_store_bypass_disable spec_store_bypass_disable=off l1tf=off default_hugepagesz=1GB hugepagesz=1G hugepages=60 transparent_hugepage=never selinux=0 isolcpus=2,3,4,5,6,7,10,11,12,13,14,15,26,27,28,29,30,31,34,35,36,37,38,39" [root@compute-lxb-3 ~]# ovs-appctl dpif/show netdev@ovs-netdev: hit:605860720 missed:2129 br-int: br-int 65534/3: (tap) int-br-vlan 1/none: (patch: peer=phy-br-vlan) patch-tun 2/none: (patch: peer=patch-int) vhu1d64ea7d-d9 5/6: (dpdkvhostuserclient: configured_rx_queues=8, configured_tx_queues=8, mtu=1500, requested_rx_queues=8, requested_tx_queues=8) vhu9c32faf6-ac 6/7: (dpdkvhostuserclient: configured_rx_queues=8, configured_tx_queues=8, mtu=1500, requested_rx_queues=8, requested_tx_queues=8) br-tun: br-tun 65534/4: (tap) patch-int 1/none: (patch: peer=patch-tun) vxlan-0a410071 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=10.65.0.114, remote_ip=10.65.0.113) br-vlan: br-vlan 65534/1: (tap) dpdk-1 2/2: (dpdk: configured_rx_queues=4, configured_rxq_descriptors=2048, configured_tx_queues=5, configured_txq_descriptors=2048, lsc_interrupt_mode=false, mtu=1500, requested_rx_queues=4, requested_rxq_descriptors=2048, requested_tx_queues=5, requested_txq_descriptors=2048, rx_csum_offload=true, tx_tso_offload=false) phy-br-vlan 1/none: (patch: peer=int-br-vlan) [root@compute-lxb-3 ~]# ovs-appctl dpif-netdev/pmd-rxq-show pmd thread numa_id 0 core_id 1: isolated : false port: dpdk-1 queue-id: 0 (enabled) pmd usage: 0 % port: vhu1d64ea7d-d9 queue-id: 3 (enabled) pmd usage: 0 % port: vhu1d64ea7d-d9 queue-id: 4 (enabled) pmd usage: 0 % port: vhu9c32faf6-ac queue-id: 3 (enabled) pmd usage: 0 % port: vhu9c32faf6-ac queue-id: 4 (enabled) pmd usage: 0 % pmd thread numa_id 0 core_id 9: isolated : false port: dpdk-1 queue-id: 1 (enabled) pmd usage: 0 % port: vhu1d64ea7d-d9 queue-id: 2 (enabled) pmd usage: 0 % port: vhu1d64ea7d-d9 queue-id: 5 (enabled) pmd usage: 0 % port: vhu9c32faf6-ac queue-id: 2 (enabled) pmd usage: 0 % port: vhu9c32faf6-ac queue-id: 5 (enabled) pmd usage: 0 % pmd thread numa_id 0 core_id 25: isolated : false port: dpdk-1 queue-id: 3 (enabled) pmd usage: 0 % port: vhu1d64ea7d-d9 queue-id: 0 (enabled) pmd usage: 0 % port: vhu1d64ea7d-d9 queue-id: 7 (enabled) pmd usage: 0 % port: vhu9c32faf6-ac queue-id: 0 (enabled) pmd usage: 0 % port: vhu9c32faf6-ac queue-id: 7 (enabled) pmd usage: 0 % pmd thread numa_id 0 core_id 33: isolated : false port: dpdk-1 queue-id: 2 (enabled) pmd usage: 0 % port: vhu1d64ea7d-d9 queue-id: 1 (enabled) pmd usage: 0 % port: vhu1d64ea7d-d9 queue-id: 6 (enabled) pmd usage: 0 % port: vhu9c32faf6-ac queue-id: 1 (enabled) pmd usage: 0 % port: vhu9c32faf6-ac queue-id: 6 (enabled) pmd usage: 0 %

2 6

Re :[all][infra] CI test result table in the new gerrit review UI
by Bogdan Dobrelya 30 Nov '20

30 Nov '20

Hi stackers, Until we have that pretty formatter for CI results, here's [0] a quick script instead. It queries Zuul CI comments by a given Gerrit SSH login and a patch set number, and colorizes it in your console outputs. PS. I'm sorry for top posting. [0] https://gist.github.com/bogdando/ed345b1f974c8e97edd33b61e7bf8158 > On Thu, 2020-11-26 at 17:30 +0000, Tristan Cacqueray wrote: >> On Thu, Nov 26, 2020 at 15:59 Sean Mooney wrote: >> > On Thu, 2020-11-26 at 15:19 +0000, Jeremy Stanley wrote: >> > > On 2020-11-26 15:10:09 +0000 (+0000), Tristan Cacqueray wrote: >> > > [...] >> > > > Here is a CR to add the test result table back in the new gerrit UI: >> > > > >> > > > https://review.opendev.org/c/opendev/system-config/+/763891 >> > > > >> > > > This new implementation uses the javascript plugin extension API. >> > > >> > > Thanks--that was quick work! >> >> You're welcome :) >> >> > is that going to be moved to the zuul org in opendev as a part of the zuul projects >> > deliverables. >> > >> > i kind of think it makes sne to develop it there rather then on the rdo gerrit instance. >> > >> >> I'd be happy to move the project to the opendev gerrit. >> >> > looking at the impleation it does not look like this owrks teh ssame way by parsing the comment >> > https://softwarefactory-project.io/cgit/software-factory/zuul-results-gerri… >> > >> >> That is correct, this is using the Gerrit Js plugin api, which let you >> register a `showChange` callback, which is called with the change info >> https://gerrit-review.googlesource.com/Documentation/rest-api-changes.html#… >> >> Thus no need to hack through the dom to get the comments. >> >> Note that the gerrit related code is in another project here: >> https://softwarefactory-project.io/cgit/software-factory/re-gerrit/ >> >> > will this just show the results form zuul. it need to pars all the comments form the third party cis too. >> > basicaly you need to parse all coment form a author that end isn CI and comments form zuul >> >> It should do that already, though I haven't tested it with real data. I >> guess the next step would be to enable such plugin on review-dev. > so the author regular expression is only looking for zuul > https://softwarefactory-project.io/cgit/software-factory/re-gerrit/tree/src… > > so it lookes liek you would need to refactor that slightly to match comments form autors that end in ci too. > > each CI systems comemtn then need have there won tabel section with the job results for that ci to mimic the same behavior > we had in the old ui. > > >> >> Cheers, >> -Tristan -- Best regards, Bogdan Dobrelya, Irc #bogdando

1 0

XDG_SESSION_TYPE error on devstack installation
by Nitish Goel 30 Nov '20

30 Nov '20

Hi Team, I'm trying to install a devstack on a ubuntu 18.04 VM having python 3.6.9 but getting below error. Any suggestions? python - 3.6.9 stack user with sudo access. pip version - pip 20.2.4 from /usr/local/lib/python3.6/dist-packages/pip (python 3.6) https://stackoverflow.com/questions/64989221/xdg-session-type-error-on-devs… NFO keystone.cmd.bootstrap [None req-f46e9c41-1b14-4e5b-82b2-ada81e8b0dcd None None] Created region RegionOne INFO keystone.cmd.bootstrap [None req-f46e9c41-1b14-4e5b-82b2-ada81e8b0dcd None None] Created public endpoint http://10.61.62.241/identity INFO keystone.cmd.bootstrap [None req-f46e9c41-1b14-4e5b-82b2-ada81e8b0dcd None None] Created admin endpoint http://10.61.62.241/identity +./stack.sh:main:1084 create_keystone_accounts +lib/keystone:create_keystone_accounts:314 local admin_project ++lib/keystone:create_keystone_accounts:315 oscwrap project show admin -f value -c id Traceback (most recent call last): File "/usr/local/bin/openstack", line 5, in <module> from openstackclient.shell import main File "/usr/local/lib/python3.6/dist-packages/openstackclient/shell.py", line 24, in <module> from osc_lib import shell File "/usr/local/lib/python3.6/dist-packages/osc_lib/shell.py", line 24, in <module> from cliff import app File "/usr/local/lib/python3.6/dist-packages/cliff/app.py", line 24, in <module> import cmd2 File "/usr/local/lib/python3.6/dist-packages/cmd2/__init__.py", line 30, in <module> from .cmd2 import Cmd File "/usr/local/lib/python3.6/dist-packages/cmd2/cmd2.py", line 48, in <module> from .clipboard import can_clip, get_paste_buffer, write_to_paste_buffer File "/usr/local/lib/python3.6/dist-packages/cmd2/clipboard.py", line 12, in <module> _ = pyperclip.paste() File "/usr/local/lib/python3.6/dist-packages/pyperclip/__init__.py", line 680, in lazy_load_stub_paste copy, paste = determine_clipboard() File "/usr/local/lib/python3.6/dist-packages/pyperclip/__init__.py", line 568, in determine_clipboard os.environ["XDG_SESSION_TYPE"] == "wayland" and File "/usr/lib/python3.6/os.py", line 669, in __getitem__ raise KeyError(key) from None KeyError: 'XDG_SESSION_TYPE' ++functions-common:oscwrap:2346 return 1 +lib/keystone:create_keystone_accounts:315 admin_project= +lib/keystone:create_keystone_accounts:1 exit_trap +./stack.sh:exit_trap:491 local r=1 ++./stack.sh:exit_trap:492 jobs -p +./stack.sh:exit_trap:492 jobs= +./stack.sh:exit_trap:495 [[ -n '' ]] +./stack.sh:exit_trap:501 '[' -f /tmp/tmp.LRWsRkTTkV ']' +./stack.sh:exit_trap:502 rm /tmp/tmp.LRWsRkTTkV +./stack.sh:exit_trap:506 kill_spinner +./stack.sh:kill_spinner:401 '[' '!' -z '' ']' +./stack.sh:exit_trap:508 [[ 1 -ne 0 ]] +./stack.sh:exit_trap:509 echo 'Error on exit' Error on exit +./stack.sh:exit_trap:511 type -p generate-subunit +./stack.sh:exit_trap:512 generate-subunit 1606228299 592 fail +./stack.sh:exit_trap:514 [[ -z /opt/stack/logs ]] +./stack.sh:exit_trap:517 /usr/bin/python3.6 /opt/stack/devstack/tools/worlddump.py -d /opt/stack/logs +./stack.sh:exit_trap:526 exit 1

3 6

Re: [designate] DKIM TXT record problem
by pawel＠dpnet.pl 30 Nov '20

30 Nov '20

I have the same problem, would you like to share a command line example, how did you manage to add such a long txt record in the designate (more than 255 characters in one record)? -- Pawel D

1 0

[ironic] [tripleo] RFC: lzma vs gzip for compressing IPA initramfs
by Dmitry Tantsur 30 Nov '20

30 Nov '20

Hi folks, I've been playing with ways to reduce the size of our IPA images. While package removals can only save us tens of megabytes, switching from gzip to lzma reduces the size by around a third (from 373M to 217M in my testing). What's the caveat? The unpacking time increases VERY substantially. On my nested virt lab the 217M image took around 5 minutes to unpack. I'm not sure how much it will impact real bare metal, please feel free to test https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/764371 and tell me. So, what do you think? Switching to lzma by default will likely affect CI run time (assuming we still have DIB jobs somewhere...) and development environments, but it will also provide a visible reduction in the image size (which benefit all environments). Large TripleO images may particularly benefit from this (but also particularly affected by the unpacking time). Feedback is very welcome. 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

7 9

[openstack][neutron]How to establish existing Openstack in a single server to other multiple physical NIC port
by dangerzone ar 29 Nov '20

29 Nov '20

Hi, I have deployed packstack (All-In-One) openstack over single server and that openstack traffic is IN/Out via eth1 of the server and that's the network port configured during the packstack deployment. The server has 4 nic ports and only one (nic1) is used during openstack deployment. The openstack running good and my vm/vnf traffic can in/out via eth1. I would like to know how I can utilize other nic port (2,3,4) in my server so that openstack can leverage that port for my other VM/VNF that instantiate in my openstack. For example from the image attached, I want VM/VNF1 connect to nic2 and VM/VNF2 connect to nic3. Please advise how it can be done. I really hope someone could advise and help me further. Thank you. **This is standard openstack (deployed via packstack all-in-one) over single centos7 server that have 4 nic ports**

2 1

[telemetry] wallaby cycle planning session
by Matthias Runge 29 Nov '20

29 Nov '20

Hi there, one of the biggest challenges for the telemetry stack is currently the state of gnocchi, which is... undefined/unfortunate/under-contributed/...? Telemetry started long time ago as a simple component ceilometer, which was split into several components ceilometer, aodh, panko, and gnocchi. Julien wrote a story about this some time ago[1]. There has also been an attempt to fork gnocchi back to OpenStack[2]. To my knowledge, the original contributors are not paid anymore to work on gnocchi, and at the same time, moving on to do something else is totally fine. However, I am not sure if we (in OpenStack Telemetry) should or could maintain in addition to the rest of the telemetry stack a time-series database. I'd like to discuss this during a call. Please select time(s) that suit you best in this poll[3]. If you have questions or hints, don't hesitate to contact me. Thank you, Matthias [1] https://julien.danjou.info/lessons-from-openstack-telemetry-deflation/ [2] https://review.opendev.org/#/c/744592/ [3] https://doodle.com/poll/uqq328x5shr43awy

5 15

[training-labs] OpenStack training-labs expired link
by Jeremy SNIDARO 28 Nov '20

28 Nov '20

Hello, The scripts to setup the labs (labs-master\labs\osbash\wbatch\create_base.bat) is trying to download an version of ubuntu that is no longer available on the URL : http://cdimage.ubuntu.com/releases/18.04/release/ubuntu-18.04.4-server-amd6… The new URL should be : http://cdimage.ubuntu.com/releases/18.04/release/ubuntu-18.04.*5* -server-amd64.iso On github it is on the file labs/stacktrain/distros/ubuntu_18_04_server_amd64.py <https://github.com/openstack/training-labs/blob/master/labs/stacktrain/dist…> Regards, ----------------------------------------------------------------- Jérémy SNIDARO GNU/Linux System Administrator - DevOps jeremysnidaro.com - France 86000 Poitiers [image: LinkedIn] <https://www.linkedin.com/in/jeremy-snidaro/>

1 0

[openstack] [InteropWG] Planning Approval by Nov 30th through email and later at Dec 8th Board meeting
by prakash RAMCHANDRAN 27 Nov '20

27 Nov '20

Hi all, Hope you all had a good Thanks Giving and like to proceed from draft guidelines on the VIctoria Interop to Approval at next Board meeting on Dec 8th. https://wiki.openstack.org/wiki/Governance/Foundation/8Dec2020BoardMeeting Please review the draft before Nov 30th Monday noon as we would like this 2020.11.* date maintained and will request an approval by Nov 30th, https://review.opendev.org/c/osf/interop/+/762719 The Interop WG meeting on Dec 3 , we will focus on maintenance of ReftStack and any additional discussions you like to bring for OIF InteropWG wrt add-on modules and or independent k8s conformance for Open Infrastructure Projects. https://etherpad.opendev.org/p/interop ThanksPrakash For InteropWG

1 0

[all][nova][placement] Merging 'placement' IRC channel into 'nova'
by Ghanshyam Mann 27 Nov '20

27 Nov '20

Hello Everyone, As the placement project is under Nova governance now[1], can we merge the IRC channel 'placement' into nova? I think that can be done via redirect way? [1] https://review.opendev.org/c/openstack/governance/+/760917 -gmann

3 2

Re: [neutron][openstack-ansible] Instances can only connect to provider-net via tenant-net but not directly
by Oliver Wenz 27 Nov '20

27 Nov '20

> So this looks like issue during sending notification to Nova. You should check > in Nova logs now why it returned You 422 The relevant nova-compute log on the node where I try to start the instance looks like this: Nov 27 13:33:24 bc1blade15 nova-compute[4240]: 2020-11-27 13:33:24.870 4240 INFO nova.compute.claims [req-4125d882-0753-4a0a-844c-5a948681ffa1 920e739127a14018a55fb4422b0885e7 0f14905dab5546e0adec2b56c0f6be88 - default default] [instance: 20a23a18-0d13-4aba-b0be-37e243b21336] Claim successful on node bc1blade15.openstack.local Nov 27 13:33:26 bc1blade15 nova-compute[4240]: 2020-11-27 13:33:26.151 4240 INFO nova.virt.libvirt.driver [req-4125d882-0753-4a0a-844c-5a948681ffa1 920e739127a14018a55fb4422b0885e7 0f14905dab5546e0adec2b56c0f6be88 - default default] [instance: 20a23a18-0d13-4aba-b0be-37e243b21336] Creating image Nov 27 13:33:31 bc1blade15 nova-compute[4240]: 2020-11-27 13:33:31.463 4240 INFO os_vif [req-4125d882-0753-4a0a-844c-5a948681ffa1 920e739127a14018a55fb4422b0885e7 0f14905dab5546e0adec2b56c0f6be88 - default default] Successfully plugged vif VIFBridge(active=False,address=fa:16:3e:57:d5:f4,bridge_name='brq497a58ad-e5',has_traffic_filtering=True,id=c2e13a92-86bc-4c8e-ad74-1cad0a6bcffc,network=Network(497a58ad-e57c-4bf1-a1c7-dad58f4795ec),plugin='linux_bridge',port_profile=<?>,preserve_on_delete=False,vif_name='tapc2e13a92-86') Nov 27 13:33:33 bc1blade15 nova-compute[4240]: 2020-11-27 13:33:33.961 4240 INFO nova.compute.manager [req-633ff74b-b16d-4063-9f54-5ee618ea2bb9 - - - - -] [instance: 20a23a18-0d13-4aba-b0be-37e243b21336] VM Started (Lifecycle Event) Nov 27 13:33:34 bc1blade15 nova-compute[4240]: 2020-11-27 13:33:34.104 4240 INFO nova.compute.manager [req-633ff74b-b16d-4063-9f54-5ee618ea2bb9 - - - - -] [instance: 20a23a18-0d13-4aba-b0be-37e243b21336] VM Paused (Lifecycle Event) Nov 27 13:33:34 bc1blade15 nova-compute[4240]: 2020-11-27 13:33:34.388 4240 INFO nova.compute.manager [req-633ff74b-b16d-4063-9f54-5ee618ea2bb9 - - - - -] [instance: 20a23a18-0d13-4aba-b0be-37e243b21336] During sync_power_state the instance has a pending task (spawning). Again, the corresponding neutron-server log: Nov 27 13:39:02 infra1-neutron-server-container-cbf4b105 neutron-server[87]: 2020-11-27 13:39:02.106 87 WARNING neutron.notifiers.nova [-] Nova event: {'server_uuid': '20a23a18-0d13-4aba-b0be-37e243b21336', 'name': 'network-vif-deleted', 'tag': 'c2e13a92-86bc-4c8e-ad74-1cad0a6bcffc', 'status': 'failed', 'code': 422} returned with failed status I also looked in all the logs of the nova related services on the managament node for the instance id but didn't find it. So the nova-compute log seems to indicate that the instance can connect to the bridge successfully?!

2 1

Re: [tripleo] Copying tripleo container images to quay.io
by Bogdan Dobrelya 27 Nov '20

27 Nov '20

So I explored how exactly skopeo copy works with the WIP zstd:chunked compression format. The main case here is when copying *new* layers of the *same* image. What is not the case in TripleO CI. We build images from scratch and tag it only once, like current-tripleo. Here ends that build's lifecycle. Had we decided to change that to update existing images, we could come back and try that new feature of skopeo, or may be even consume it directly via buildah bud, when it's there. Another caveat is that only OCI compliant registries could accept such zstd:chunked compressed layers. But anyway that was a good try... Bogdan Dobrelya bdobreli at redhat.com writes: > Note that skopeo will shortly have the layers diffs [0] based "copy" > operations [1],[2],[3]. It also deduplicates things and uses local cache > to not repeat redundant data transfers. Would be great if TripleO > container registry could start using that super cool feature as early > adoption. > > We could make a build with these patches and try that for the subject > tooling for TCIB distribution over quay.io. > > IIUC, the process is like: > > * as input we have full layers from the source registry, built with TCIB; > * skopeo uses its super powers to redo it on fly into layers diff > * either skopeo as well, or maybe even tripleoclient prepare image CLI > pushes those optimized layers of the images to the target quay.io registry. > * ??? > * profit! > > [0] https://github.com/containers/image/pull/902 > [1] https://github.com/containers/image/pull/1084 > [2] https://github.com/containers/storage/pull/775 > [3] https://github.com/containers/skopeo/pull/1111 -- Best regards, Bogdan Dobrelya, Irc #bogdando

1 0

[tripleo] Please avoid merge patches for releases before Victoria
by Arx Cruz 27 Nov '20

27 Nov '20

Hello, We need these patches [1] landed first in order to merge other patches, otherwise CI will not be able to properly test it. We have already had two known issues [2] related to this problem, so I ask you for patience while we are merging those patches. [1] https://review.opendev.org/c/openstack/tripleo-quickstart/+/763747 https://review.opendev.org/#/c/763712 [2] https://launchpad.net/bugs/1903033 https://bugs.launchpad.net/tripleo/+bug/1905536 Kind regards, -- Arx Cruz Software Engineer Red Hat EMEA <https://www.redhat.com> arxcruz(a)redhat.com @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 1

[release] Release countdown for week R-20, Nov 23 - Nov 27
by Herve Beraud 26 Nov '20

26 Nov '20

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

1 0

[all][tc][goals] Migrate RBAC Policy Format from JSON to YAML: Week R-20 Update
by Ghanshyam Mann 26 Nov '20

26 Nov '20

Hello Everyone, As you all know, 'Migrate RBAC Policy Format from JSON to YAML' is one of the community-wide goals for Wallaby development cycle. I am starting this thread to report the progress of this work. Tracking: https://etherpad.opendev.org/p/migrate-policy-format-from-json-to-yaml Gerrit Topic: https://review.opendev.org/q/topic:%22policy-json-to-yaml%22+(status:open%2… Updates: ======== * Common code of upgrade checks and policy.json file fallback logic is moved from nova to oslo.upgradechecks (in version 1.2.0) and oslo.policy(in version 3.6.0) respectively. ** For upgrade checks, you just need to enable it from the project side. Example: https://review.opendev.org/c/openstack/keystone/+/764240/4/keystone/cmd/sta… ** For olso.policy fallback logic, you just need to bump the min version to 3.6.0. For project who already change the policy_file default in previous releases (like Cinder ) then you can disable this fallback logic via flag 'fallback_to_json_file' * I have started few projects to propose the changes and will continue to do that for other projects too. If you are interested to help, please write it in tracking etherpad [1]. * I am updating the goal documents also for oslo side common code and the latest example. - https://review.opendev.org/c/openstack/governance/+/764261 - This is an example you can refer: https://review.opendev.org/c/openstack/keystone/+/764240 [1] https://etherpad.opendev.org/p/migrate-policy-format-from-json-to-yaml -gmann

1 0

[neutron] Drivers meeting - 27.11.2020
by Slawek Kaplonski 26 Nov '20

26 Nov '20

Hi, As it's Thanksgiving week and Black Friday so our US folks will probably not be there and lets cancel the meeting this week. But we have couple of new RFEs which needs to be triaged: * https://bugs.launchpad.net/neutron/+bug/1905391 * https://bugs.launchpad.net/neutron/+bug/1905295 * https://bugs.launchpad.net/neutron/+bug/1905115 * https://bugs.launchpad.net/neutron/+bug/1900934 So please take some time and help with triaging them so we will be able to discuss them next week hopefully :) Have a great weekend! -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[ptl][release][stable][EM] Extended Maintenance - Stein
by Előd Illés 26 Nov '20

26 Nov '20

Hi, As Victoria was released 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 Stein is planned to enter into Extended Maintenance phase [1] (planned date: 2020-11-11). I have generated the list of *open* and *unreleased* changes in *stable/stein* for the follows-policy tagged repositories [2]. These lists could help the teams, who are planning to do a *final* release on Stein before moving stable/stein 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* (Stein) releases of repositories with *stein-em* tag. * After the transition stable/stein will be still open for bugfixes, 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.openstack.org/p/stein-final-release-before-em

2 2

[oslo] py-amqp TLS peer authentication
by Moises Guimaraes de Medeiros 26 Nov '20

26 Nov '20

Hi all, This email is about a potential MITM attack, I would like to get some input on my proposed solution. *Disclaimer: I'm not an oslo.messaging expert or even versed in its codebase but I have a good* * number of hours working with TLS already.* Back in September, there was a fix[1] in py-amqp to stop to use deprecated method ssl.wrap_socket. Although I didn't follow anything about oslo.messaging, the PR was brought to my attention by Hervé, another oslo core, who sees me as an SME on TLS among the oslo cores. I didn't follow the entire conversation back then, I was only able to give some quick input, but Hervé was able to finish the PR with the help of another developer. Then earlier this month, another PR[2] was reintroducing a couple of parameters that got dropped in the deprecation fix. At that point it was raised the possibility of a MITM attack in an issue[3] and by reintroducing the dropped parameters, the problem should be fixed. A couple of days went by and I started to have a hunch that there could still be more to fix. I went to py-amqp codebase instead of just looking to the diffs on GitHub and noticed a not straightforward logic on how verify_mode and check_hostname were being set. Today I had time to go back to the py-amqp codebase and rework the _wrap_socket_sni() method. I've put up this PR[4] and it is already failing in my travis[5] for integration tests which make me believe that the client sockets were actually not validating the server certs. There are a few more comments on the fix in the description of PR[4]. [1]: https://github.com/celery/py-amqp/pull/327 [2]: https://github.com/celery/py-amqp/pull/344 [3]: https://github.com/celery/py-amqp/issues/342 [4]: https://github.com/celery/py-amqp/pull/347 [5]: https://travis-ci.com/github/moisesguimaraes/py-amqp/builds/204747399 Thanks, -- Moisés Guimarães Software Engineer Red Hat <https://www.redhat.com> <https://red.ht/sig>

1 0

SFC for OVN
by Lazuardi Nasution 26 Nov '20

26 Nov '20

Hi, By https://docs.openstack.org/neutron/ussuri/admin/config-sfc.html, it is stated that SFC essentially is the SDN version of PBR. On the other side, PBR is supported by OVN. Is there any initiative of Neutron SFC driver for OVN which utilize native PBR support of OVN without having to alternate the OVN itself? For example, for having a port pair of port A to port B for flow classifier of HTTP traffic, we might make PBR which match HTTP traffic from port A address and set the next hop to port B address. The other way which might be used is destination NATing (redirection) on port A for HTTP traffic to port B address. OVN has native support for NAT too, but I think the PBR way is better. Best regards,

1 1

[tc] weekly update & agenda
by Mohammed Naser 26 Nov '20

26 Nov '20

Hi everyone, Here's an update for what happened in the OpenStack TC this week. You can get more information by checking for changes in openstack/governance repository. # Patches ## Open Reviews - Clarify the requirements for supports-api-interoperability https://review.opendev.org/c/openstack/governance/+/760562 - Add election schedule exceptions in charter https://review.opendev.org/c/openstack/governance/+/751941 - Add Resolution of TC stance on the OpenStackClient https://review.opendev.org/c/openstack/governance/+/759904 - Add assert:supports-standalone https://review.opendev.org/c/openstack/governance/+/722399 - Remove assert_supports-zero-downtime-upgrade tag https://review.opendev.org/c/openstack/governance/+/761975 - Add Magpie charm to OpenStack charms https://review.opendev.org/c/openstack/governance/+/762820 - Propose Kendall Nelson for vice chair https://review.opendev.org/c/openstack/governance/+/762014 - Clarify impact on releases for SIGs https://review.opendev.org/c/openstack/governance/+/752699 ## General Changes - Move Placement under Nova's governance https://review.opendev.org/c/openstack/governance/+/760917 ## Other Reminders - Our next [TC] Weekly meeting is scheduled for November 26. If you would like to add topics for discussion, please go to https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting and fill out your suggestions by Wednesday, November 26th, at 0000 UTC. Thanks for reading! Mohammed & Kendall -- Mohammed Naser VEXXHOST, Inc.

1 1

[Freezer][Keystone][Mistral][Monasca][Murano][Openstack-Chef][Openstack-Helm][Openstacksdk][Trove][Watcher][Zun] Action required: Gerrit code audit
by Mohammed Naser 26 Nov '20

26 Nov '20

Hello there, As per the `service-announce` on October 20 regarding Gerrit Outage Update email http://lists.opendev.org/pipermail/service-announce/2020-October/000011.html, all project teams are required to audit changes for projects from 2020-10-01 to 2020-10-21. I'm reaching out to those projects in particular who the TC believes have not completed their audit yet. Let us know if you need any type of assistance in completing the audit. In case you didn’t know you needed to do this, feel free to reach out for support. Regards, Mohammed -- Mohammed Naser VEXXHOST, Inc.

13 14