September 2021 - openstack-discuss

[tc][neutron] Use Kea insted of Dibbler for IPv6 PD
by Lajos Katona 15 Sep '21

15 Sep '21

Hi, In Neutron we have a bug (see [1]) that states Dibbler is concluded (see [2]), and the developer of Dibbler suggests using Kea (see [3]) instead. Before we start checking technical things first thing is that Kea is MPL2.0 licensed (see [4]) and not sure if we can pull that as dependency to Openstack. Kea is an ISC project so looks safe, but I am not familiar with these legal things. How can we check and be sure? [1] https://bugs.launchpad.net/neutron/+bug/1916428 [2] https://github.com/tomaszmrugalski/dibbler#project-status [3] https://gitlab.isc.org/isc-projects/kea [4] https://www.isc.org/kea/ Thanks in advance Lajos Katona (lajoskatona)

3 3

[nova] "Migrating" ComputeNode within ComputeHost / vmwareapi ComputeNode per ESXi
by Wiesel, Fabian 15 Sep '21

15 Sep '21

Hi, I am looking at adding the option for the vmwareapi driver to expose the individual ESXi hosts. A compute-host would represent a cluster in vsphere, and each ESXi-host within a cluster would be a ComputeNode. The main question here is, how to handle a hypervisor initiated change of the compute-node and if the community is open to extending the compute-driver interface for such a use-case. The secondary one is, if there is interest in having the upstream vmwareapi driver getting this functionality. * What are we trying to solve by that? Our users are asking for that feature, because they want to know, if a payload of two VMs runs on the same physical host, as the performance characteristics are quite different. We also gain there from an operational and code perspective: - Nova would become aware of the actual resources per ESXi host instead of the aggregated ones. - Resources could also be more faithfully represented in the resource-tree (e.g., shared storage as an aggregate). - Capabilities, (cpu-flags, architecture,… ), Numa topology, and even small things like up-time can be faithfully reflected on a per-host basis. - The internal scheduling decisions in the driver for ephemeral storage and compute (for live-migration) can be handled by standard placement & nova scheduling. * Why do we need to change the driver interface? Main problem here is that VSphere might migrate a VM between two ESXi-hosts for various reasons. So, the driver would need a way to communicate such a change somehow. But even if we disable all kind of migrations on VMware side, we still need a way to migrate the VMs from the single compute-node for the whole cluster to the compute nodes for each individual ESXi-hosts. * Proposed Driver API Change The Compute-Manager is currently periodically polling the driver with ComputeDriver.get_info(self, instance, use_cache) which returns an InstanceInfo, which is essentially only the power-state. Adding two new optional fields to InstanceInfo could allow the driver to inform the manager about - the current compute-node - the compute-node the VM is migrated to This allows the Compute-Manager to take care of updating the node field and the resource-allocations accordingly. Additionally, we can notify the manager over Instance lifecycle events, allowing for a faster reflection of a compute-node change. The lifecycle events could be - EVENT_LIFECYCLE_COMPUTE_NODE_MIGRATION_STARTED - EVENT_LIFECYCLE_COMPUTE_NODE_MIGRATION_COMPLETED Or one could generalize the current life-migration events to include also such compute-node changes. I am looking forward for your feedback. Cheers, Fabian

1 0

[TripleO] Installation of Undercloud on CentOS 8.4
by Anirudh Gupta 14 Sep '21

14 Sep '21

Hi Team, I was trying to install Undercloud on CentOS 8.4 While installing the repos, I got the error "The host is not stream" So wanted to confirm if only CentOS 8 Stream is supported or is there still a way we can install TripleO on CentOS 8.4 or any specific version? Regards Anirudh Gupta

2 1

[tacker] Ayumu Ueha for Tacker Core
by Yasufumi Ogawa 14 Sep '21

14 Sep '21

Hi everyone, I'd like to propose Ayumu Ueha as a core reviewer. He has made huge contributions not only for reviewing actively but also developing key features of NFV Container support and helping us for fixing critical problems [1][2]. Assuming that there are no objections, we will add Ayumu to tacker core team next week. [1] https://review.opendev.org/q/owner:ayumu [2] https://www.stackalytics.io/?module=opendev.org%2fopenstack%2ftacker&user_i…

7 8

The code about BP Allow migrating PMEM's data
by Juntingqiu Qiujunting (邱军婷) 14 Sep '21

14 Sep '21

Hi all: Is there anything in the code logic that needs to be modified? If there is no problem with the implementation structure of the code, I start adding unit tests. https://review.opendev.org/c/openstack/nova/+/802225 Thank you Fossen. -----邮件原件----- 发件人: Balazs Gibizer [mailto:balazs.gibizer@est.tech] 发送时间: 2021年9月14日 16:45 收件人: Juntingqiu Qiujunting (邱军婷) <qiujunting(a)inspur.com> 抄送: smooney(a)redhat.com; Brin Zhang(张百林) <zhangbailin(a)inspur.com> 主题: Re: The code about BP Allow migrating PMEM's data Hi, Sorry I cannot read the content of your mail due to smime. Also please keep the discussion on openstack-discuss if possible. Cheers, gibi On Tue, Sep 14 2021 at 01:45:49 AM +0000, Juntingqiu Qiujunting (邱军婷) <qiujunting(a)inspur.com> wrote:

1 0

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

14 Sep '21

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

2 3

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

14 Sep '21

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

2 3

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

14 Sep '21

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

5 5

MTU configuration for instances
by shubjero 14 Sep '21

14 Sep '21

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

2 1

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

13 Sep '21

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

1 0