June 2020 - openstack-discuss - lists.openstack.org

[kolla] Kolla klub meeting
by Mark Goddard 30 Jun '20

30 Jun '20

Hi, The next Kolla klub meeting is scheduled for Thursday at 15:00 UTC. We have the following topics on the agenda: * Gaël: Offline usage of Kolla & Kolla Ansible * Justinas: host OS lifecycle management * Mark: summary of the priorities agreed on for the Victoria cycle https://docs.google.com/document/d/1EwQs2GXF-EvJZamEx9vQAOSDB5tCjsDCJyHQN5_… Thanks, Mark

1 0

[neutron] Team meeting - Tuesday 30.06.2020
by Slawek Kaplonski 30 Jun '20

30 Jun '20

Hi, Our today team meeting overlaps with opened event sessions [1] so lets cancel this meeting. See You all on the meeting next week. [1] https://www.openstack.org/events/opendev-2020/opendev-schedule — Slawek Kaplonski Senior software engineer Red Hat

1 0

[neutron] DVR / IPv6 on provider network instead?
by Eric K. Miller 30 Jun '20

30 Jun '20

Hi, Should I assume that the statement: "IPv6 traffic is not distributed, even when DVR is enabled. IPv6 routing does work, but all ingress/egress traffic must traverse through the centralized Controller node. Customers that are extensively using IPv6 routing are advised not to use DVR at this time." is still true in Stein and later (we are running Stein for now, which is why I explicitly mentioned this version)? If so, is there a possibility of using a provider network that is connected to all compute nodes where IPv6 subnets are issued to tenants from a subnet pool, with traffic being routed directly to an external router (not a Neutron router) using Linux Bridge instead of OVS? Yet, still use port security? Just trying to figure out the best way to support IPv6 without forwarding all traffic through a single network node, while using DVR for IPv4. Also, unrelated, but hopefully a quick question... is the "internal" or "external" label on a network just used for filtering lists, such as for "openstack network list --external"? or does it change the behavior of anything? Thanks! Eric

2 2

[neutron] Bug deputy - week of June 22nd
by Slawek Kaplonski 30 Jun '20

30 Jun '20

Hi, Below is my bug deputy summary. It was pretty busy week in Neutron regarding bugs. *High* https://bugs.launchpad.net/neutron/+bug/1885114 - job neutron-tempest-plugin-scenario-openvswitch-iptables_hybrid-ussuri may not be using ussuri Assigned Fixed: https://review.opendev.org/738169 https://bugs.launchpad.net/neutron/+bug/1884906 - L3 agent cannot be manually scheduled Assigned Fixed proposed: https://review.opendev.org/737736 https://bugs.launchpad.net/neutron/+bug/1884808 - [SSL] neutron-rpc-server: RecursionError: maximum recursion depth exceeded while calling a Python object Stable/rocky only, issue caused by old eventlet, Assigned Fix proposed: https://review.opendev.org/#/c/737651/ https://bugs.launchpad.net/neutron/+bug/1884708 - explicity_egress_direction prevents learning of local MACs and causes flooding of ingress packets Unnasigned, It seems that fixes https://bugs.launchpad.net/neutron/+bug/1732067 and https://bugs.launchpad.net/neutron/+bug/1866445 broke other scenarios, *We need someone to take a look into that one* *Medium* https://bugs.launchpad.net/neutron/+bug/1884986 - [OVN] functional test failing TestNBDbMonitorOverTcp test_floatingip_mac_bindings Marked as medium even if it's gate failure because it don't happens often, Assigned, Patch proposed: https://review.opendev.org/738415 https://bugs.launchpad.net/neutron/+bug/1884764 - Some overcloud nodes are missing in the ansible inventory file generated for migration to ML2OVN Assigned, Patches proposed: https://review.opendev.org/#/c/738212/ and https://review.opendev.org/#/c/738192/ https://bugs.launchpad.net/neutron/+bug/1884723 - [OVS] multicast between VM instances on different compute nodes is broken with IGMP snooping enabled Assigned, No patch proposed yet, https://bugs.launchpad.net/neutron/+bug/1884527 - Related dvr routers aren't created on compute nodes Regression introduced with fix for other bug, Assigned, Patch proposed: https://review.opendev.org/737286 *Low* https://bugs.launchpad.net/neutron/+bug/1885547 - [fullstack] OVS interface events isolation error with more than one OVS agent Assigned, Patch https://review.opendev.org/#/c/738446/ *Whishlist* https://bugs.launchpad.net/neutron/+bug/1885261 - Add stateless firewall support to OVS firewall Unassigned, https://bugs.launchpad.net/neutron/+bug/1885262 - Add stateless firewall support to OVN Unassigned, *Opinion* https://bugs.launchpad.net/neutron/+bug/1884504 - nova assume ports with vnic_type=direct-physical use the libvirt interface element when processing network-vif-deleted events *Incomplete* https://bugs.launchpad.net/neutron/+bug/1884532 - inconsistent data in ipamallocations I asked for some more info Would be good if someone who knows IPAM could take a look, *Older bugs which needs some attention* https://bugs.launchpad.net/neutron/+bug/1883321 - Neutron OpenvSwitch DVR - connection problem dvr issue to check by L3 team, https://bugs.launchpad.net/neutron/+bug/1671448 - [RFE] Neutron quota api should be configurable via policy.json — Slawek Kaplonski Senior software engineer Red Hat

1 0

[tc] weekly update
by Mohammed Naser 29 Jun '20

29 Jun '20

Hello 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. # OPEN REVIEW - Add "tc:approved-release" tag to manila https://review.opendev.org/#/c/738105/ - Create starter-kit:kubernetes-in-virt tag https://review.opendev.org/#/c/736369/ - [draft] Add assert:supports-standalone https://review.opendev.org/#/c/722399/ - Add legacy repository validation https://review.opendev.org/#/c/737559/ # PROJECT UPDATES - Add deprecated cycle for deprecated deliverables https://review.opendev.org/#/c/737590/ - No longer track refstack repos in governance https://review.opendev.org/#/c/737962/ - Add Neutron Arista plugin charm to OpenStack charms https://review.opendev.org/#/c/737734/ - Retire puppet-congress https://review.opendev.org/#/c/737145/ # GOAL UPDATES - Update policy in code goal for glance https://review.opendev.org/#/c/738278/ # GENERAL CHANGES - Add storyboard link to migrate-to-focal goal https://review.opendev.org/#/c/738129/ - TC Guide Follow-Ups https://review.opendev.org/#/c/737650/ - Tools: update check-review-status to drop grace period https://review.opendev.org/#/c/736737/ - Remove grace period on resolutions https://review.opendev.org/#/c/735361/ Thanks all. -- Mohammed Naser VEXXHOST, Inc.

1 0

Delegating and routing an IPv6 prefix to an instance
by Christian Rohmann 29 Jun '20

29 Jun '20

Hello OpenStack-Discuss, I have a use case in which an instance / VM is hosting i.e. an OpenVPN gateway which shall be doing some routing / networking by itself. For that purpose one would like to have a global unique IPv6 prefix delegated and routed to it to, which it can in turn give out to its VPN clients. This can and should not be cut out of the on-link network that is provided by Neutron and used to connect the instance itself. If you look at https://community.openvpn.net/openvpn/wiki/IPv6, which has a section *Details: IPv6 routed block* explaining just how that is one intended approach on how to do it. I am now wondering if the existing DHCPv6 prefix delegation implemented in OpenStack is capable of providing a prefix to an instance. Digging a little into what can be found online I ran into this Etherpad doc https://etherpad.opendev.org/p/neutron-kilo-prefix-delegation (linked to on https://wiki.openstack.org/wiki/Neutron/IPv6/PrefixDelegation) There is a list of use-cases, the second one being exactly what I described above: > [...] > > Use cases: > > We need to allocate addresses to ports from an external or > providernetwork, and route them via Neutron routers. > > We wish to allocate whole prefixes to devices (and their specific > neutron port) on demand. A port must be authorised via the API for a > prefix. The prefix could be issued to the device via PD (since the > device has to discover the prefix it's been given). > > [...] But to my understanding the spec used to implement the current IPv6 networking and also prefix delegation mechanism, also mentioned this use case as an "limitation and future enhancement" - see: https://specs.openstack.org/openstack/neutron-specs/specs/liberty/ipv6-pref… Does anyone have any thoughts on this matter of dedicating a prefix and and routingits traffic to a VM, but not just a subnet? Regards Christian

4 8

[all][qa] devstack dropping python 2 support
by Ghanshyam Mann 29 Jun '20

29 Jun '20

Hello Everyone, Devstack has been default to python3 since ussuri release and Victoria cycle is time to drop the support of python2 completely. - https://review.opendev.org/#/c/737455/ Being ussuri as python3-only release and all grenade jobs has been migrated to python3 in ussuri, we are all good here but in case your project is still using the py2 jobs or replying on python2 support in devstack in any extend, do ping us on #openstack-qa channel. We will be keeping USE_PYTHON3 variable support till all consumer remove this, like storlets to adjust the requirement. NOTE: branchless repo keeping common jobs for master and stable branch gate with USE_PYTHON3=False need to keep setting this var for configuring the devstack with right python. For example, tempest-full job definition in tempest master. Such jobs should be run till stable/train only as ussuri onward we tests things on python3 only. -gmann

1 0

Monasca duplicate metrjcs
by junaid soomro 29 Jun '20

29 Jun '20

Hello everyone, I am new to this. my scenario is when i try to get io.read_bytes metric from monasca api it gives me more than one metrics of a singke hostname. Although device is different vda vdb etc. This is fine but when i remove the volume from the vm. Monasca api still sbows its metrics. Ideally it should remove the vdb because i removed it but it does not. why does this happen? Thank you

2 1

RE: [neutron] DVR / IPv6 on provider network instead?
by Eric K. Miller 29 Jun '20

29 Jun '20

> If so, is there a possibility of using a provider network that is connected to all compute nodes where IPv6 subnets are issued to tenants from a subnet pool, with traffic being routed directly to an external router (not a Neutron router) using Linux Bridge instead of OVS? Yet, still use port security? > Just trying to figure out the best way to support IPv6 without forwarding all traffic through a single network node, while using DVR for IPv4. I believe I have a solution, which works for IPv4, where public IP addresses are assigned to a VM's port without the use of floating IPs. I think this approach can work for IPv6, with an upstream DHCPv6 server. My IPv4 approach was to create an internal VLAN on our firewalls, where a public subnet is assigned (statically routed), and a gateway IP is assigned to the firewall. This VLAN is then assigned to a provider network. An OpenStack subnet is created on the provider network for the public subnet range with an allocation range associated with the IPs we want to hand out to VMs, with DHCP enabled. The subnet's gateway property is set to "None", along with DNS servers set, and a "host-route" is added for a default gateway, using our firewall's IP as the gateway. When a server is created on this network, an IP is allocated from the public subnet, the gateway is assigned to our firewall's IP, DNS is set correctly, and security groups work fine on the port. Best of all, traffic is sent/received from the host, not through the network node, so this is a reasonably scalable solution. Eric

1 0

[cyborg][nova] Support flexible use scenario for Mdev(such as vGPU)
by Feng, Shaohe 28 Jun '20

28 Jun '20

Hi all, Currently openstack support vGPU as follow: https://docs.openstack.org/nova/latest/admin/virtual-gpu.html In order to support it, admin should plan ahead and configure the vGPU before deployable as follow: https://docs.openstack.org/nova/latest/configuration/config.html#devices.en… This is very inconvenient for the administrator, this method has a limitation that a same PCI address does not provide two different types. Cyborg as an accelerator management tool is more suitable for mdev device management. One solution as follow： Firstly, we need a vender driver(this can be a plugin), it is used to discovery its special devices and report them to placement for schedule. The difference from the current implementation is that: 1. report the mdev_supported_types as traits to resource provider. How to discover a GPU type: $ ls /sys/class/mdev_bus/*/mdev_supported_types /sys/class/mdev_bus/0000:84:00.0/mdev_supported_types: nvidia-35 nvidia-36 nvidia-37 nvidia-38 nvidia-39 nvidia-40 nvidia-41 nvidia-42 nvidia-43 nvidia-44 nvidia-45 so here we report nvidia-3*, nvidia-4* as traits to resource provider. 2. Report the number of allocable resources instead of vGPU unit numbers to resource provider inventory Example for the NVidia V100 PCIe card (one GPU per board) : Virtual GPU Type Frame Buffer (Gbytes) Maximum vGPUs per GPU Maximum vGPUs per Board V100D-32Q 32 1 1 V100D-16Q 16 2 2 V100D-8Q 8 4 4 V100D-4Q 4 8 8 V100D-2Q 2 16 16 V100D-1Q 1 32 32 so here we report 32G Buffers(an example, maybe other resources) to resource provider inventory 3. driver should also support a function to create certain mdev type, such as (V100D-1Q, V100D-2Q,) Secondly, we need a mdev extend ARQ(it can be a plugin): Here is an example for fpga ext arq: https://review.opendev.org/#/c/681005/26/cyborg/objects/extarq/fpga_ext_arq… The difference is that, we replace the _do_programming to _do_create_mdev For _do_programming, it is used to create a new FPGA function. For _do_create_mdev, it is used to create a new type mdev, it will call the implementation function in vendor driver. At last we need to support a mdev handler for xml generation in nova, we can refer to the cyborg PCI handler in nova So after the above changes： Admin can create different SLA devices profiles such as: {“name”: “Gold_vGPU”, “groups”: [ {“resources:vGPU_BUFFERS”: “16”, “traits: V100D-16Q,”: “required”, }] } And {“name”: “Iron_vGPU”, “groups”: [ {“resources:vGPU_BUFFERS”: “1”, “traits: V100D-1Q,”: “required”, }] } Then a tenant can use Gold_vGPU to create with a VM with V100D-16Q vGPU And another tenant can use Iron_vGPU to create with a VM with V100D-1Q vGPU When ARQ binding during the VM creating, the Cyborg will call the vendor driver to create expected mdev vGPU. And these 2 mdev vGPU can be on same physical GPU card. The mdev extend ARQ and vendor driver can be plugin, they are loose couple with the upstream code. So the downstream can get the upstream code to customize the own mdev extend ARQ and vendor driver. Here vGPU is just an example, it can be other mdev devices. BR Shaohe Feng

3 11

RE: [neutron] DVR / IPv6 on provider network instead?
by Eric K. Miller 28 Jun '20

28 Jun '20

> Also, unrelated, but hopefully a quick question... is the "internal" or "external" label on a network just used for filtering lists, such as for "openstack network list --external"? or does it change the behavior of anything? Regarding my second question, I found some information that indicates --external will share the network with all projects. Whereas the --shared option is only used for sharing a network with a specified list of projects using RBAC rules. It also looks like networks marked as external, not internal, can be specified for the --external-gateway network when creating/updating a router. This has some good info too: https://superuser.openstack.org/articles/tenant-networks-vs-provider-networ… Eric

1 0

[ops][cinder] removal of brocade fczm driver
by Brian Rosmaita 27 Jun '20

27 Jun '20

Brocade no longer supports their cinder Fibre Channel Zone Manager driver [0]. It was marked 'unsupported' in Ussuri and deprecated for removal during the Victoria development cycle. (We just discovered this week that it is in fact unusable in Ussuri as it does not run in Python 3. It does pass all unit tests in Python 3, though.) Its removal will leave cinder with only one FCZM driver, so there has been some interest among Cinder project members in fixing the driver so it will at least run in Python 3.6 and 3.8. However, we don't know at the moment how much effort that will take. Further, without a third-party CI continually testing this driver, we cannot guarantee that once fixed, it will continue to function correctly. (No human can guarantee that any software of sufficient complexity functions correctly, but you know what I mean.) The point of this email is threefold: 1. If nobody is using the Brocade FCZM driver, then maybe we should just go ahead and remove it. So if you are using it, please let us know. 2. According to [0], for OpenStack users after Train, "Brocade encourages customers to perform SAN Zoning operations using other available tools or APIs." So if you are a Brocade user who has successfully configured another solution to replace the Brocade FCZM, the Cinder team (and the wider OpenStack community) would be interested in hearing about it. 3. If you are a consumer of the current cinder Brocade FCZM and are interested in its continued existence, the Cinder team would be interested in discussing with you how we could set up a third-party CI for it. As I said earlier, without the third-party CI, we really have no idea whether this thing works or not. I've already posted a patch to remove the Brocade FCZM driver [1]. (Just so you know we're serious about this.) At our R-16 mid-cycle meeting earlier this week, the Cinder team agreed to make a final decision at our next mid-cycle at week R-9. (Yes, we have two mid-cycles and neither is at the middle of the cycle -- we're already meeting in virtual space, so we also meet in virtual time.) So please communicate your thoughts to us before week R-9 by replying to this email on the mailing list. cheers, brian [0] https://docs.broadcom.com/doc/12397527 [1] https://review.opendev.org/#/c/738148/

1 0

[all][interop] Tasks completed and help for Interop Survey questions
by prakash RAMCHANDRAN 26 Jun '20

26 Jun '20

Hi all, It was bit odd to use meetpad instead of irc today, still need to understand how to share multiple screens or desktop on the meetpad.Any help is welcome as hat the procedure will be. Plus apology to Mark for late update on irc to meetpad. Weekly we will be using - (https://etherpad.opendev.org/p/interop) Interop Working Group - Weekly Friday 10-11 AM or UTC 17-18 Lnink: https://meetpad.opendev.org/Interop-WG-weekly-meeting But communication was really better than irc with chat plus verbal+video talk. How to add ircbot to meetpad any suggestions? Following is action Items to follow up. AI-01- GM to update/close? launchpad item - https://blueprints.launchpad.net/refstack/+spec/interop-2020.06With following two references to storyboard for all API guidelines for 2020.06.json.https://storyboard.openstack.org/#!/story/2007509https://story… AI-02 - Survey Questions please add what you seek for your projects? - https://storyboard.openstack.org/#!/story/2007511 6/26/2020 - AT todays Interop call it was decided to add following questions and is being circulated for updates via openstack-discuss list.level 1 Q &A1.Do you use OpenStack Marketplace data for your decision on use of OpenStack Cloud?2.Do you look at Interoperability reports available to you on different offerings in Marketplace portal?3. If you offer OpenStack Cloud do you use the OpenStack logo programs.?4. If you are using Object Storage for your cloud do you use Swift? What would you like to see improve in current Marketplace Logo Program?[1] Do you want to add Interop for kubernetes API conformance for OpenStack and Open Infrastructure Projects?[2] Do you want to add Interop for bare metal service?[3][4] (Add above your suggestions)level 2 Q&A1. Do you use data on add-on programs in the OpenStack Marketplace?1.1 If yes which ones? AI-03 - (for Core + Add-ons for OpenStack Integrated Projects) - Can you volunteer to add tag assert:supports-api-interoperability to your projects?Any comments on what Projects need to do to claim this based on 2020.06 - interop - https://opendev.org/osf/interop/src/branch/master/2020.06.json Can someone take a crack at documenting how to for one project like nova compute api does now? AI-04 - Seeking volunteers to maintain - Refstack - https://opendev.org/osf/refstack AI-05 - Can someone volunteer to present at next Interop meeting Friday 3rd at 17 UTC (10 AM PDT) - https://github.com/cncf/k8s-conformance Any Other suggestions for future events? ThanksInterop team: Prakash/Mark/Ghanshyam/Arkady

1 0

[openstack-discuss][airship-discuss][openstack-helm] Ceph Bluestore
by Roman Gorshunov 26 Jun '20

26 Jun '20

Hello Dominik, Thanks for the question. Please, let me redirect it to the OpenStack-Helm project mailing list, as Airship only consumes Ceph charts from openstack-helm-infra repository (previously from openstack-helm repo). Technically I see that ceph-osd in OpenStack-Helm supports Bluestore [0], so if you would want to deploy with Bluestore, you would need to change Armada documents (e.g. [1][2]) to use Bluestore. [0] https://opendev.org/openstack/openstack-helm-infra/src/branch/master/ceph-o… <https://opendev.org/openstack/openstack-helm-infra/src/branch/master/ceph-o…> [1] https://opendev.org/airship/treasuremap/src/branch/master/site/seaworthy/so… <https://opendev.org/airship/treasuremap/src/branch/master/site/seaworthy/so…> [2] https://opendev.org/airship/treasuremap/src/branch/master/site/seaworthy/so… <https://opendev.org/airship/treasuremap/src/branch/master/site/seaworthy/so…> Best regards, Roman Gorshunov > On 25 Jun 2020, at 17:36, Dominik Bender <db(a)db-itsolutions.com> wrote: > > Hello everyone, > > I need some help with Ceph configuration. What changes need to be made in the charts to use bluestore? > In general I would still be interested in why bluestore is not yet standard in treasuremap? > > Thanks in advance > > -- > Dominik Bender > > > _______________________________________________ > Airship-discuss mailing list > Airship-discuss(a)lists.airshipit.org > http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss

1 0

OpenStack on CentOS 8 VM using packstack
by Pradeep Antil 26 Jun '20

26 Jun '20

Hi Techies, I am trying to deploy the latest Openstack "ussuri" on CentOS 8 VM using packstack. I have successfully installed it but the issue is that i want to i want to add my interface "enp0s3" to ovs bridge br-ex. On CentOS 7 we can do this via ifcfg-* files using network-scripts. But i am not sure how this can be done on CentOS 8 VM as in this release network is controlled via network manager. On br-ex i will attach an external provider network or a flat network. [image: image.png] I have referred the below steps for the deployment. dnf update -y dnf config-manager --enable PowerTools dnf install -y centos-release-openstack-ussuri dnf update -y dnf install -y openstack-packstack reboot packstack --gen-answer-file=/root/answer.txt Edit answer file CONFIG_NEUTRON_ML2_TYPE_DRIVERS=vxlan,flat CONFIG_NEUTRON_ML2_TENANT_NETWORK_TYPES=vxlan CONFIG_PROVISION_DEMO=n CONFIG_KEYSTONE_ADMIN_PW=P@ssw0rd packstack --answer-file=/root/answer.txt Following is the output of ovs command and interfaces on my centos 8 system [image: image.png] -- Best Regards Pradeep Kumar

2 1

[tc][networking-l2gw] Finish the retirement for networking-l2gw and networking-l2gw-tempest-plugin
by Ghanshyam Mann 26 Jun '20

26 Jun '20

Hello Everyone, networking-l2gw and networking-l2gw-tempest-plugin projects were retired in Ocata[1] but their retirement was not completed. I have started the retirement completion as discussed in TC and neutron team. - https://review.opendev.org/#/q/topic:complete-retirement-networking-l2gw+(s… Please let me know any injection to that. Their development can be continued under opendev as mentioned in this doc - https://governance.openstack.org/tc/reference/dropping-projects.html#contin… [1] https://review.opendev.org/#/c/392010/2 -gmann

5 9

[blazar] Broken CI
by Pierre Riteau 26 Jun '20

26 Jun '20

Hello, The blazar devstack CI jobs are currently failing due to issues related to uwsgi. logs/screen-blazar-a.txt shows: Jun 25 09:26:47.037179 ubuntu-bionic-limestone-regionone-0017387278 systemd[1]: Starting Devstack devstack(a)blazar-a.service... Jun 25 09:26:47.038997 ubuntu-bionic-limestone-regionone-0017387278 systemd[18254]: devstack(a)blazar-a.service: Failed to execute command: No such file or directory Jun 25 09:26:47.039047 ubuntu-bionic-limestone-regionone-0017387278 systemd[18254]: devstack(a)blazar-a.service: Failed at step EXEC spawning /usr/local/bin/uwsgi: No such file or directory Jun 25 09:26:47.039445 ubuntu-bionic-limestone-regionone-0017387278 systemd[1]: devstack(a)blazar-a.service: Main process exited, code=exited, status=203/EXEC Jun 25 09:26:47.039454 ubuntu-bionic-limestone-regionone-0017387278 systemd[1]: devstack(a)blazar-a.service: Failed with result 'exit-code'. Jun 25 09:26:47.039734 ubuntu-bionic-limestone-regionone-0017387278 systemd[1]: Failed to start Devstack devstack(a)blazar-a.service. I think it's our devstack plugin that needs fixing. In the meantime no need to recheck patches, they will keep failing until resolved. Pierre Riteau (priteau)

2 2

[all][tc][goals] Migrate CI/CD jobs to new Ubuntu LTS Focal: Week R-16 Update
by Ghanshyam Mann 26 Jun '20

26 Jun '20

Hello Everyone, Please find the updates on Ubuntu Focal migration community goal. Tracking: https://storyboard.openstack.org/#!/story/2007865 Progress: ======= * devstack and tempest base patches are ready for testing on projects side. Thanks frickler for doing the base work. * neutron, nova project started the testing. Bugs: ==== 1. There is open bug for nova/cinder where three tempest tests are failing for volume detach operation. There is no clear root cause found yet -https://bugs.launchpad.net/cinder/+bug/1882521 We have skipped the tests in tempest base patch to proceed with the other projects testing but this is blocking things for the migration. 2. We encountered the nodeset name conflict with x/tobiko, i have proposed it to consume it form devstack -https://review.opendev.org/#/c/738128/ What work to be done on project side: ============================= This goal is more of testing the jobs on focal and fixing bugs if any otherwise migrate jobs by switching the nodeset to focal node sets defined in devstack. 1. Start a patch in your repo by making depends-on on either of below: devstack base patch if you are using only devstack base jobs not tempest: https://review.opendev.org/#/c/731207/ OR tempest base patch if you are using the tempest base job (like devstack-tempest): https://review.opendev.org/#/c/734700/ Example: https://review.opendev.org/#/c/738126/ 2. If none of your project jobs override the nodeset then above patch will be testing patch(do not merge) otherwise change the nodeset to focal. Example: https://review.opendev.org/#/c/737370/ 3. If the jobs are defined in branchless repo like tempest plugins then you need to override the branches variant to adjust the nodeset on jobs so that only Victoria onwards those jobs run on focal not old stable. Once we finish the testing on projects side and no failure then we will merge the devstack and tempest base patches. Important things to note: =================== * Do not forgot to add the story and task link to your patch so that we can track it smoothly. * Use gerrit topic 'migrate-to-focal' * Do not backport any of the patch. References: ========= Goal doc: https://governance.openstack.org/tc/goals/selected/victoria/migrate-ci-cd-j… Storyboard tracking: https://storyboard.openstack.org/#!/story/2007865 -gmann

1 0

[tc] Monthly meeting
by Mohammed Naser 26 Jun '20

26 Jun '20

Hi everyone, Our monthly TC meeting is scheduled for next Thursday, July 2nd, at 1400 UTC. 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, July 1st, at 1900 UTC. Thank you, Regards, Mohammed -- Mohammed Naser VEXXHOST, Inc.

1 0

[cinder] priorities for the next 2 weeks
by Brian Rosmaita 25 Jun '20

25 Jun '20

As mentioned at yesterday's virtual mid-cycle, our top priority right now is to get the milestone-1 items reviewed and re-reviewed. And the specs freeze is next week ... so our *two* top priorities are to get the milestone-1 items reviewed and also review specs. Here is a handy list: volume-local-cache - https://review.opendev.org/#/c/663549/ os-brick - https://review.opendev.org/#/c/700799/ cinder - https://review.opendev.org/#/c/715762/ tempest test case NFS encrypted volume support - https://review.opendev.org/#/c/597148/ brick gpg encryption support - https://review.opendev.org/#/c/709432/ new backend driver - Hitachi - https://review.opendev.org/#/c/712832/ specs: https://review.opendev.org/#/q/project:openstack/cinder-specs+status:open

1 0

[cinder] victoria mid-cycle part 1 summary available
by Brian Rosmaita 25 Jun '20

25 Jun '20

In case you missed yesterday's R-16 virtual mid-cycle session, I've posted a summary: https://wiki.openstack.org/wiki/CinderVictoriaMidCycleSummary It includes a link to the recording (in case you want to see what you missed or if you want to re-live the excitement). Part 2 of the mid-cycle will be held the week of R-9. cheers, brian

1 0

OSF Community Meeting 1 Recording & Slides
by Allison Price 25 Jun '20

25 Jun '20

Hi everyone, Thank you for joining today’s OSF Community Meeting. If you missed the meeting, you have a few options on getting updated on what was covered. You can listen to the recording [1] and check out the slides [2] that were presented this morning. I have also attached a PDF of the slides if that’s easier to access. There will be a second OSF Community Meeting covering the same material tomorrow, Friday, June 26 at 0200 UTC (today, June 25 at 7pm PT). You can find the lineup of speakers and dial-in information here [3]. Stay tuned for the next OSF Community Meeting in July that will cover the OpenStack 10th birthday, and the next all project, quarterly update that will be held in September. Cheers, Allison [1] https://zoom.us/rec/share/vJF_FqPgxGJJQ9bntR7vaqM7N7i_X6a81yQa8vtcxU06amK9p… <https://zoom.us/rec/share/vJF_FqPgxGJJQ9bntR7vaqM7N7i_X6a81yQa8vtcxU06amK9p…> Password: 7W!T*i74 [2] https://docs.google.com/presentation/d/16V82OIYfthb3fFlVoes9jZGKMgDIJZ55F8f… [3] https://etherpad.opendev.org/p/OSF_Community_Meeting_Q2 <https://etherpad.opendev.org/p/OSF_Community_Meeting_Q2> Allison Price OpenStack Foundation allison(a)openstack.org

1 0

Python OpenStack SDK does not return Hypervisor hostname
by Anil Jangam 25 Jun '20

25 Jun '20

I have written a client code as follows. # Get Hypervisor details try: print(f"+----------------------------------------------------------+") print(f"| Hypervisor details |") print(f"+----------------------------------------------------------+") for hypervisor in conn.list_hypervisors(): print(f"Hypervisor is: {hypervisor}") print(f"Hypervisor status: {hypervisor.status}") print(f"Hypervisor vcpus: {hypervisor.vcpus_used}") print(f"Hypervisor type: {hypervisor.hypervisor_type}") print(f"Hypervisor id: {hypervisor.id}") print(f"Hypervisor state: {hypervisor.state}") print(f"Hypervisor host IP: {hypervisor.host_ip}") print(f"Hypervisor running VMs: {hypervisor.running_vms}") print(f"Hypervisor running VMs: {hypervisor.vcpus}") print(f"Hypervisor hostname: {hypervisor.hypervisor_hostname}") print(f"") except EndpointNotFound as exp: print("Error: {}".format(exp)) print(f"") When I print the 'hypervisor' object itself, most of the values are printed as shown below, however when I try to access 'hypervisor.hypervisor_hostname', it throws an exception. +----------------------------------------------------------+ | Hypervisor details | +----------------------------------------------------------+ Hypervisor is: openstack.compute.v2.hypervisor.Hypervisor(status=enabled, service={'host': 'cl3-Compute3', 'disabled_reason': None, 'id': '34db399d-25b9-4004-98b9-2d8bbce7b228'}, vcpus_used=0, hypervisor_type=QEMU, local_gb_used=0, vcpus=52, hypervisor_hostname=cl3-Compute3, memory_mb_used=25600, memory_mb=262032, current_workload=0, state=up, host_ip=192.168.10.116, cpu_info={'arch': 'x86_64', 'model': 'Broadwell', 'vendor': 'Intel', 'features': ['pge', 'avx', 'xsaveopt', 'clflush', 'sep', 'rtm', 'tsc_adjust', 'tsc-deadline', 'dtes64', 'invpcid', 'tsc', 'fsgsbase', 'xsave', 'smap', 'vmx', 'erms', 'xtpr', 'cmov', 'hle', 'smep', 'pcid', 'est', 'pat', 'monitor', 'smx', 'pbe', 'lm', 'msr', 'adx', '3dnowprefetch', 'nx', 'fxsr', 'syscall', 'tm', 'sse4.1', 'pae', 'sse4.2', 'pclmuldq', 'acpi', 'fma', 'vme', 'popcnt', 'mmx', 'osxsave', 'cx8', 'mce', 'de', 'rdtscp', 'ht', 'dca', 'lahf_lm', 'abm', 'rdseed', 'pdcm', 'mca', 'pdpe1gb', 'apic', 'sse', 'f16c', 'pse', 'ds', 'invtsc', 'pni', 'tm2', 'avx2', 'aes', 'sse2', 'ss', 'ds_cpl', 'arat', 'bmi1', 'bmi2', 'ssse3', 'fpu', 'cx16', 'pse36', 'mtrr', 'movbe', 'rdrand', 'x2apic'], 'topology': {'cores': 14, 'cells': 2, 'threads': 2, 'sockets': 1}}, running_vms=0, free_disk_gb=852, hypervisor_version=2012000, disk_available_least=849, local_gb=852, free_ram_mb=236432, id=1130407d-5afd-41f9-bc0c-2d7babda3ce7, location=Munch({'cloud': 'defaults', 'region_name': 'RegionOne', 'zone': None, 'project': Munch({'id': '6d4f1b107bbf4b94832f7ef72df61ef2', 'name': '5g', 'domain_id': None, 'domain_name': 'default'})})) Hypervisor status: enabled Hypervisor vcpus: 0 Hypervisor type: QEMU Hypervisor id: 1130407d-5afd-41f9-bc0c-2d7babda3ce7 Hypervisor state: up Hypervisor host IP: 192.168.10.116 Hypervisor running VMs: 0 Hypervisor running VMs: 52 Traceback (most recent call last): File "/Users/workspace/testprogs/python/opsviz/ops_worker.py", line 321, in <module> main() File "/Users/workspace/testprogs/python/opsviz/ops_worker.py", line 317, in main print_servers() File "/Users/workspace/testprogs/python/opsviz/ops_worker.py", line 115, in print_servers print(f"Hypervisor hostname: {hypervisor.hypervisor_hostname}") File "/Users/inventory/lib/python3.7/site-packages/openstack/resource.py", line 588, in __getattribute__ raise e File "/Users/inventory/lib/python3.7/site-packages/openstack/resource.py", line 582, in __getattribute__ return object.__getattribute__(self, name) AttributeError: 'Hypervisor' object has no attribute 'hypervisor_hostname' Is there anything wrong with the use of the API? How do I get the hypervisor hostname in my application code? Thank you.

3 6

[kolla] Introducing Kolla Kalls
by Radosław Piliszek 25 Jun '20

25 Jun '20

Hi fellow OpenStackers! During yesterday's Kolla meeting [1] I have proposed to have more focused, voice-based sessions related to Kolla development, similarly to what we have for operators with Kolla Klub [1]. The immediate response was rather positive and the name Kolla Kalls has been coined. Since Kolla Klub is running every other Thursday at 15:00 UTC, we decided to use the alternate weeks slot for Kolla Kalls but this can change if need arises. Kolla Kalls got their wiki page already [3] where the agenda will be posted. The first Kall is scheduled on July 9, 15:00 UTC (i.e. in two weeks time from today). The agenda for the first Kall is mostly about trying this meeting approach out. The hottest topic from our PTG is the quality/completeness of our documentation so it is a good topic for our first few sessions. It is likely going to involve CI testing discussions as well. The platform has not been decided on yet. We plan to give OpenDev's Meetpad a test ride and fall back to Google Meet which we practiced well with Kolla Klub and similar events - if Jitsu breaks for us. I learnt Meetpad does not (yet) support recording but we plan to document the meeting in a text form anyhow so we should be fine. Everyone interested in developing Kolla projects, that is Kolla, Kolla-Ansible and/or Kayobe is welcome to join the Kalls. The Kalls will be development-oriented and focus on topics such as implementation discussion, change planning, release planning and housekeeping. [1] http://eavesdrop.openstack.org/meetings/kolla/2020/kolla.2020-06-24-15.01.h… [2] https://docs.google.com/document/d/1EwQs2GXF-EvJZamEx9vQAOSDB5tCjsDCJyHQN5_… [3] https://wiki.openstack.org/wiki/Meetings/Kolla/Kall -yoctozepto

1 0

[neutron] Drivers meeting agenda - 26.06.2020
by Slawek Kaplonski 25 Jun '20

25 Jun '20

Hi Neutron drivers, Below is agenda for tomorrow’s meeting. We have 2 RFE to discuss: https://bugs.launchpad.net/neutron/+bug/1882804 - RFE: allow replacing the QoS policy of bound port This one is follow-up after virtual PTG and discussions with Nova team, https://bugs.launchpad.net/neutron/+bug/1828494 - L3 agent’s capacity lets discuss again this proposal with “routers_max” parameter instead of bandwidth (See last comment there) There is also proposed spec (https://review.opendev.org/#/c/729532/) for: https://bugs.launchpad.net/neutron/+bug/1880532 - [RFE]L3 Router should support ECMP Please review it if You can and we will get back to this RFE next week. Ok, that’s all for today. See You all tomorrow on the meeting. — Slawek Kaplonski Senior software engineer Red Hat

1 0