September 2021 - openstack-discuss

Cannot create a swift container on Horizon dashboard , mandatory "Storage Policy" dropdown field is empty
by Michel Niyoyita 15 Sep '21

15 Sep '21

Hello team , I am replacing swift by Ceph Radosgateway , and I am successful by creating containers through openstack and ceph CLI side . but once trying to create through the horizon dashboard I get errors: *Error: *Unable to fetch the policy details. , Unable to get the Swift service info and Unable to get the Swift container listing. Kindly help to solve the issue I deployed Openstack wallaby using kolla-ansible running on ubuntu 20.04 and ceph pacific using ansible running on ubuntu 20.04 Michel

1 0

[patrole][qa] Proposing Soniya Vyas to Patrole core
by Martin Kopec 15 Sep '21

15 Sep '21

Hi all, Soniya Vyas (IRC: soniya29) is very enthusiastic about Patrole project and since she has been very helpful, I'd like to propose her for Patrole core. You can vote/feedback on this email. If no objections within a week, I'll add her to the core list. Regards, -- Martin Kopec Senior Software Quality Engineer Red Hat EMEA

6 6

[nova] Backporting test refactors to stable/train
by Artom Lifshitz 15 Sep '21

15 Sep '21

Hey Elod and Vlad (and the ML, cc'ed) This is continuing the conversation Elod and I had on IRC. The immediate context is [1], which is a test refactor backport that in turn enables conflict-free backporting of at least two fixes. >From Red Hat's point of view, we will have to care about stable/train for *very* long time, so we'd like to do everything we can to make our lives easier, including backportings things are aren't strictly necessary (like test refactors) in order to greatly facilitate future backports, which tend to be of the "func reproducer test + actual fix" variety. Elod made the excellent point that while this approach does make backports to train much easier to both write and review, it also "postpones" all of the manual conflict resolution work onto anyone doing stable/stein backports. I went and gathered data. I looked at the last 6 months of backports in Gerrit. At the time of this writing, stable/train 72 [2] had and stable/stein had 24 [3]. Out of the latter, Vlad Gusev was the main non-Red Hat contributor. So my proposal is simple: I'm willing to help resolve conflicts in stable/stein backport for folks like Vlad, if it means making backports to stable/train easier. I'm confident that it would still mean an overall reduction in man-hours for backports, even if I become personally on the hook to deal with the fallout of backporting test refactors to stable/train. Cheers! [1] https://review.opendev.org/c/openstack/nova/+/791481 [2] https://review.opendev.org/q/project:openstack/nova+branch:stable/train+-ag… [3] https://review.opendev.org/q/project:openstack/nova+branch:stable/stein+-ag…

3 3

[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