December 2020 - openstack-discuss

[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 04 Dec '20

04 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