- openstack-discuss - lists.openstack.org

[cinder] [replication] Error in cinder replication | Openstack Victoria
by Swogat Pradhan 26 Jun '21

26 Jun '21

Hi, I am trying to configure cinder replication with ceph as backend and i followed this URL to configure the cinder replication: https://netapp.io/2016/10/14/cinder-replication-netapp-perfect-cheesecake-r… and http://www.sebastien-han.fr/blog/2017/06/19/OpenStack-Cinder-configure-repl… i created a Volume type - REPL, with replication enabled <is> True and colume backend name parameter. But when i am trying to create a volume using the created volume type the volume is getting created in ceph but in cinder the status is showing error. and when checked log getting the following error: 2021-06-24 17:59:39.556 28472 ERROR cinder.volume.drivers.rbd [req-6e6b901e-f2dd-43a4-a089-6c734b279e17 d576181b6a444541b8ec7f37d750a4c1 a9ac2eba50d84d64ac44b179bbcc9183 - default default] Error creating rbd image volume-361f35c4-a589-4653-b404-fb93d2f598cf.: cinder.exception.ReplicationError: Volume 361f35c4-a589-4653-b404-fb93d2f598cf replication error: Failed to enable image replication I tried to create a volume using volume type- default and then later changed the volume type using command 'cinder retype' to the created volume type and it changed without any issue. I am using openstack victoria . With regards, Swogat Pradhan

4 5

[all][tc] What's happening in Technical Committee: summary 25th June, 21: Reading: 5 min
by Ghanshyam Mann 26 Jun '21

26 Jun '21

Hello Everyone, Here is last week's summary of the Technical Committee activities. 1. What we completed this week: ========================= * Deprecated panko and puppet-panko project[1] 2. TC Meetings: ============ * TC held this week meeting on Thursday; you can find the full meeting logs in the below link: - https://meetings.opendev.org/meetings/tc/2021/tc.2021-06-24-15.00.log.html * We will have next week's meeting on July 1st, Thursday 15:00 UTC[2]. 3. Activities In progress: ================== TC Tracker for Xena cycle ------------------------------ TC is using the etherpad[3] for Xena cycle working item. We will be checking and updating the status biweekly in the same etherpad. Open Reviews ----------------- * Five open review for ongoing activities[4]. Migration from Freenode to OFTC ----------------------------------------- * Not much progress on project side wiki/doc page which is only thing left for this migration. * All the required work for this migration is tracked in this etherpad[5] 'Y' release naming process ------------------------------- * Y release naming election is closed now. As a last step, the foundation is doing trademark checks on elected ranking. Deprecate OpenStack-Ansible nspawn repositories ------------------------------------------------------------ * OpenStack-Ansible nspawn repositories is in process of retirement[6] Test support for TLS default: ---------------------------------- * Rico has started a separate email thread over testing with tls-proxy enabled[7], we encourage projects to participate in that testing and help to enable the tls-proxy in gate testing. Retiring governance's in-active repos ------------------------------------------- * The Technical Committee retiring the governance's in-active repos which are not required in current structure[8]. Adding Ceph Dashboard charm to OpenStack charms --------------------------------------------------------------- * Proposal to add Ceph Dashboard charm to OpenStack charms[9] Other Changes ------------------ * Charter change to handle the vacant seat situation[10] * Add DPL model also in 'Appointing leaders' section[11] 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[12]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [13] 3. Office hours: The Technical Committee offers a weekly office hour every Tuesday at 0100 UTC [14] 4. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://review.opendev.org/c/openstack/governance/+/796408 [2] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [3] https://etherpad.opendev.org/p/tc-xena-tracker [4] https://review.opendev.org/q/project:openstack/governance+status:open [5] https://etherpad.opendev.org/p/openstack-irc-migration-to-oftc [7] https://review.opendev.org/c/openstack/governance/+/797731 [7] http://lists.openstack.org/pipermail/openstack-discuss/2021-June/023000.html [8] https://etherpad.opendev.org/p/governance-repos-cleanup [9] https://review.opendev.org/c/openstack/governance/+/797913 [10] https://review.opendev.org/c/openstack/governance/+/797912 [11] https://review.opendev.org/c/openstack/governance/+/797985 [12] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [13] http://eavesdrop.openstack.org/#Technical_Committee_Meeting [14] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours -gmann

1 0

[tc][all][goal] Migrate RBAC Policy Format from JSON to YAML: COMPLETED
by Ghanshyam Mann 25 Jun '21

25 Jun '21

Hello Everyone, I am happy to update that we have completed the community wide goal for "Migrate RBAC Policy Format from JSON to YAML". - https://governance.openstack.org/tc/goals/selected/wallaby/migrate-policy-f… Thanks to all the projects/contributors involved in this work. Completion Report: =============== * Projects completed: 33 * Projects do not need any changes: 16 * project left: 0 * This is the complete work we did for this goal: ** Gerrit Topic: https://review.opendev.org/q/topic:%22policy-json-to-yaml%22+(status:open%2… ** Tracking Etherpad: https://etherpad.opendev.org/p/migrate-policy-format-from-json-to-yaml -gmann

1 0

[nova][os-vif][stable] Adding os-vif-core to os-vif stable branches
by Stephen Finucane 25 Jun '21

25 Jun '21

Happy Friday, Per $subject, I'd like to propose that we add os-vif-core to the list of teams with +2 rights on os-vif stable branches. Currently this list is restricted to "Project Bootstrappers", nova-stable-maint and stable-maint-core. os-vif doesn't see many backports, but it is a rather specialist library that requires some domain-specific knowledge to grok and the existing stable reviewers typically insist on reviews from core reviewers before approving changes. By making this change, we can avoid this little dance. We have discussed this already on #openstack-nova, but if there are any concerns, please raise them now. If not, I'll seek to have the relevant changes merged to openstack/project-config by the end of next week. I'll post these changes shortly. Cheers, Stephen [1] https://meetings.opendev.org/irclogs/%23openstack-nova/%23openstack-nova.20…

3 3

[cinder] upcoming driver deadlines
by Brian Rosmaita 25 Jun '21

25 Jun '21

This is a reminder that the cinder New Driver Merge Deadline is Thursday 15 July 2021 [0]. Please make sure *right now* that you've filed a Launchpad blueprint for your driver and that your blueprint shows up in this list: https://blueprints.launchpad.net/cinder/xena (if it doesn't, contact me off list) If you're adding a new feature to a driver, you should also file a Lanuchpad blueprint (it helps us prioritize reviews). See the Xena release schedule for more info about the Cinder Driver Features Declaration [1]. New features for current drivers follow the regular Feature Freeze policy (that is, must be merged by Milestone 3). cheers, brian [0] https://releases.openstack.org/xena/schedule.html#x-cinder-driver-deadline [1] https://releases.openstack.org/xena/schedule.html#x-cinder-driver-features-…

1 0

[dev][nova] PCI IRQ Affinity for VMS with dedicated CPUs
by Soares Sarto, Ricardo 25 Jun '21

25 Jun '21

Hello Everyone, Does NOVA provide any intelligent affining of IRQs of PCI Devices to CPUs pinned to VMs? i.e. for VMs that have pci-passthrough interfaces to PCI devices and are using ‘dedicated’ CPU policy, does NOVA automatically affine the IRQs for those PCI devices the CPUs that are allocated to the VM? Furthermore, is there any flavor extraspec that can further scope the IRQ affinity of the PCI Devices to a subset of the VM’s dedicated cpus? If not, is this a new capability that the NOVA team would be open to? -rsoaress

2 1

[neutron] can floating IP port forwarding work when agent_mode is dvr or dvr_snat but on compute node?
by Yi Yang (杨燚)-云服务集团 25 Jun '21

25 Jun '21

Hi, folks I’m working on https://bugs.launchpad.net/neutron/+bug/1931953, per my check for neutron-specs/specs/rocky/port-forwarding.rst, it seems port forwarding function only can be done on network node, so I don’t think we need to do it on compute node, can anybody help confirm this? Per my understanding, if a FIP is set port forwarding to two VMS across two compute node, physical switch has no way to know which compute node it should send to if destination IP is this FIP, right? But on centralized mode, this isn’t an issue.

2 2

[ironic] Ansible deploy_interface error output
by Ivan Iotchenko 25 Jun '21

25 Jun '21

Hello We are using Ironic (Train) and Ansible deploy interface. Everything works just awesome and we were able to include all the things we need into deployment/undeployment process (with respect to flexibility provided by Ansible). However, there is an issue. If you have failures during the process - you will be presented with full Ansible output which can be large enough (and thus cut). Almost every failure requires you to review log files (Ironic/Ansible). This is fine if deployment is being done by Ironic admin or person who have required experience. For other users it can be a blocker. Usually you just cannot determine root cause from the error message in last_failure field, which you can get both from console or UI. Error output was pretty straightforward with direct deploy interface. Is there a way to made Ansible error output better? E.g. to make it short and descriptive (“DNS registration failed bla-bla-bla”) Thanks, Ivan

1 0

Regarding Bind server in ubuntu
by Adivya Singh 24 Jun '21

24 Jun '21

hi Team, I am facing one issue in Bind Server installation in ubuntu, I am not able to resolve the reserve DNS names , I am suspecting there is a issue in SOA , when i am doing dig from the public IP to the private subnet IP, it does not return anything like dig -x <Floating IP><private IP> regards Adivya Singh

2 1

[kolla] Wallaby releases available
by Mark Goddard 24 Jun '21

24 Jun '21

Hi, I'm pleased to announce the availability of the first Wallaby releases for all Kolla deliverables: * kolla 12.0.0 (https://docs.openstack.org/releasenotes/kolla/wallaby.html#relnotes-12-0-0-…) * kolla-ansible 12.0.0 (https://docs.openstack.org/releasenotes/kolla-ansible/wallaby.html#relnotes…) * kayobe 10.0.0 (https://docs.openstack.org/releasenotes/kayobe/wallaby.html#relnotes-10-0-0…) A lot of hard work was involved in these releases which add support for two new OS versions: CentOS Stream and Debian Bullseye. Many thanks to everyone who contributed to these releases. And now onto Xena! Thanks, Mark

1 0

[nova] SCS standardized flavor naming
by Dmitriy Rabotyagov 24 Jun '21

24 Jun '21

Hi! > The point is, a new customer will *not* spend time reading the spec. > Typically, they will want to just fire-up a VM quickly without reading > too much docs... While I find Thomases flavor naming also not really intuitive for customers - out of nvt4-a8-ram24-disk50-perf2 I could guess only disk size and amout of ram (is it in gygabytes?) but "SCS-16T:64:200s-GNa:64-ib" doesn't make any sense to me at all (if I haven't read [1] ofc). I totally agree that no user in Public cloud would read any spec before launching their VM and it would be super hard to force them to do so. So flavor naming should be as explicit and readable as possible and assuming that person who will use cloud has no idea about specs we're making. These specs should be designed for cloud providers to comply and have same standards so users feel comfortable and secure, but don't assume regular users to have special skills in reading what engineers come up to. If regular users would find this hard to use, companies might choose hapiness of customers over some compliance. As nova doesn't have any text description for flavors, so flavor name is everything we have to expose to the customers and it should be clean and readable from the first sight. > nvt4-a8-ram24-disk50-perf2 > > This means: > - nvt4: nvidia T4 GPU > - a8: AMD VCPU 8 (we also have i4 for example, for Intel) > - ram24: 24 GB of RAM > - disk50: 50 GB of local system disk > - perf2: level 2 of IOps / IO bandwidth So what I'd suggest to cover that usecase would be smth like: 8vCPU-24576RAM-50SSD-pGPU:T4-10kIOPS-EPYC4 > SCS-8C:32:2x200S-bms-i2-GNa:64-ib > [4] In case you wonder: 8 dedicated cores, 32GiB RAM, 2x200GB SSD disks > on bare metal sys, intel Cascade Lake, nVidia GPU with 64 Ampere SMs > and InfiniBand. Would be probably smth like: 8pCPU-32768RAM-2x200SSD-2vGPU:A100-IB-Cascade [1] https://github.com/SovereignCloudStack/Operational-Docs/blob/main/flavor-na… -- Kind Regards, Dmitriy Rabotyagov

3 3

[all][tc] Technical Committee next weekly meeting on June 24th at 1500 UTC
by Ghanshyam Mann 24 Jun '21

24 Jun '21

Hello Everyone, Technical Committee's next weekly meeting is scheduled for June 24th at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, June 23rd, at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann

1 1

[nova][libvirt][cinder] Volume-based live migration and multi-attach
by Mariusz Karpiarz 24 Jun '21

24 Jun '21

Hi all, For live migration of volume-based instances (a Cinder volume used for the main OS disk) to work does the Cinder backend need to support multi-attach or at any point of the migration process are there multiple processes accessing the same volume?

2 1

[neutron] OVS tunnels and VLAN provider networks on the same interface
by Krzysztof Klimonda 24 Jun '21

24 Jun '21

Hi All, What is the best practice for sharing same interface between OVS tunnels and VLAN-based provider networks? For provider networks to work, I must "bind" entire interface to vswitchd, so that it can handle vlan bits, but this leaves me with a question of how to plug ovs tunnel interface (and os internal used for control<->compute communication, if shared). I have two ideas: 1) I can bind entire interface to ovs-vswitchd (in ip link output it's marked with "master ovs-system") and create vlan interfaces on top of that interface *in the system*. This seems to be working correctly in my lab tests. 2) I can create internal ports in vswitchd and plug them into ovs bridge - this will make the interface show up in the system, and I can configure it afterwards. In this setup I'm concerned with how packets from VMs to other computes will flow through the system - will they leave openvswitch to host system just to go back again to be sent through a tunnel? I've tried looking for some documentation regarding that, but came up empty - are there some links I could look at to get a better understanding of packet flow and best practices? Best Regards, -- Krzysztof Klimonda kklimonda(a)syntaxhighlighted.com

5 9

[keystone] "identity_provider failed validation" getting scoped token, on Rocky/Python3
by Marek Szuba 24 Jun '21

24 Jun '21

Dear everyone, I run a small OpenStack cloud on Debian Buster, using standard distro packages - i.e. Rocky. My Keystone is configured as a federated-identity Service Provider, with the IdP accessed using OpenID. Having got things working successfully using local users I went on to testing federation - and found out that using the OpenStack CLI to get a scoped token from an unscoped one reports a server error 500, and logging in to Horizon shows usage and event data couldn't be retrieved. On the server side, in both cases Keystone log shows the following: INFO keystone.common.wsgi [req-foo bar baz - Federated default] POST https://osc.example.com:5000/v3/auth/tokens ERROR keystone.common.wsgi [req-foo bar baz - Federated default] identity_provider failed validation: <function FederatedCredential.<lambda> at 0xdeadbeef>: ValueError: identity_provider failed validation: <function FederatedCredential.<lambda> at 0xdeadbeef> ERROR keystone.common.wsgi Traceback (most recent call last): ERROR keystone.common.wsgi File "/usr/lib/python3/dist-packages/keystone/common/wsgi.py", line 148, in __call__ ERROR keystone.common.wsgi result = method(req, **params) ERROR keystone.common.wsgi File "/usr/lib/python3/dist-packages/keystone/auth/controllers.py", line 67, in authenticate_for_token ERROR keystone.common.wsgi self.authenticate(request, auth_info, auth_context) ERROR keystone.common.wsgi File "/usr/lib/python3/dist-packages/keystone/auth/controllers.py", line 236, in authenticate ERROR keystone.common.wsgi auth_info.get_method_data(method_name)) ERROR keystone.common.wsgi File "/usr/lib/python3/dist-packages/keystone/auth/plugins/token.py", line 46, in authenticate ERROR keystone.common.wsgi PROVIDERS.identity_api ERROR keystone.common.wsgi File "/usr/lib/python3/dist-packages/keystone/auth/plugins/mapped.py", line 101, in handle_scoped_token ERROR keystone.common.wsgi send_notification(taxonomy.OUTCOME_SUCCESS) ERROR keystone.common.wsgi File "/usr/lib/python3/dist-packages/keystone/notifications.py", line 685, in send_saml_audit_notification ERROR keystone.common.wsgi user=user_id, groups=group_ids) ERROR keystone.common.wsgi File "/usr/lib/python3/dist-packages/pycadf/credential.py", line 84, in __init__ ERROR keystone.common.wsgi setattr(self, FED_CRED_KEYNAME_IDENTITY_PROVIDER, identity_provider) ERROR keystone.common.wsgi File "/usr/lib/python3/dist-packages/pycadf/cadftype.py", line 66, in __set__ ERROR keystone.common.wsgi (self.name, self.func)) ERROR keystone.common.wsgi ValueError: identity_provider failed validation: <function FederatedCredential.<lambda> at 0xdeadbeef> i.e. the request has succeeded but then things fall over when an audit notification is to be sent. Having poked around the sources of keystone.notifications.send_saml_audit_notifications() and the code it references, I found out the following: - the lambda function which triggers the error checks if 'identity_provider' is a six string type; - when this error occurs the value of 'identity_provider' is indeed the name of my IdP - but as *bytes* rather than str! - this doesn't happen every time this IdP name is used - if I add a simple identity_provider = identity_provider.decode('utf-8') to the relevant function I start getting errors suggesting that under some circumstances, 'identity_provider' is str as it should be. All in all, it seems like this particular bit of Keystone code in Rocky does not properly support Python3. Unfortunately an upgrade to a newer OpenStack version is non-trivial for me for several reasons, only some of which are under my control - and the stop-gap measure of having patched the relevant function with "if identity_provider is bytes, decode it to str" means I've had to put the relevant Debian package on hold, thus blocking potential updates. Therefore, I look forward to hearing from you any and all ideas which might help address this problem in less radical fashion. Thank you in advance! -- MS

1 0

Regarding dhcp not forwarding the IP in openstack
by Adivya Singh 24 Jun '21

24 Jun '21

Hi Team, I have a issue where, the dhcp are not forwarding the IP for some reason, and the dhcp are not responding properly in a hypervisor I can see that, all the interfaces are up tap devices are ip, can u please suggest what should we do to resolve the issue Regards Adivya Singh

2 1

[all][tripleo][validations] Communication from the Validations Framework team! o/
by Gaël Chamoulaud 24 Jun '21

24 Jun '21

Greetings everyone! For those who do not know about the Validations Framework yet: The Validations Framework is at the same time, A collection of Ansible roles and playbooks to detect and report potential issues during a TripleO deployment and A Python library to manipulate them through a Command Line Interface. * Validations are used to efficiently and reliably verify various facts about the cloud (or any other products) on the level of individual nodes and hosts. * Validations are non-intrusive by design, and recommended when performing large scale changes to the cloud, for example upgrades, or to aid in the diagnosis of various issues. Historically, this project was created during the Newton cycle for a direct use with OpenStack/TripleO and became the Validations Framework since Stein. We strongly feel and think that this project can be beneficial to other environments, projects or products... If you read this line it's probably because you are still interested, so if you want to talk with us about the Validations Framework, how to create a new validation for your product and/or integrate our CLI in your workflow, please feel free to reach us on this mailing list or come join us on IRC: * IRC channel #validation-framework at Libera (For all subject-matters) * IRC channel #tripleo at OFTC (OpenStack and TripleO discussions) We are looking forward seeing you around! [1] - https://opendev.org/openstack/tripleo-validations [2] - https://docs.openstack.org/tripleo-validations/latest/ [3] - https://opendev.org/openstack/validations-libs [4] - https://docs.openstack.org/validations-libs/latest/ [5] - https://opendev.org/openstack/validations-common [6] - https://docs.openstack.org/validations-common/latest/ Best Regards, Cédric Jeanneret, David J. Peacock, Jan Buchta, Jiri Podivin, Mathieu Bultel, and I! -- Gaël Chamoulaud - (He/Him/His)

1 0

[neutron] Drivers meeting 25.06.2021 cancelled
by Slawek Kaplonski 24 Jun '21

24 Jun '21

Hi, I will be on PTO tomorrow thus I will not be able to chair the meeting. Let's cancel it this week and see You again next Friday. -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[cinder] status of some unapproved Xena specs
by Brian Rosmaita 24 Jun '21

24 Jun '21

As attentive members of the OpenStack community know, Friday 25 June is the Xena spec freeze for cinder [0]. There are four specs that have been discussed on and off at PTGs and midcycle meetings that don't appear ready for approval in Xena. The discussion of these specs at today's cinder meeting is here: https://meetings.opendev.org/meetings/cinder/2021/cinder.2021-06-23-14.00.l… The specs I'm talking about are these: 1. Support revert any snapshot https://review.opendev.org/c/openstack/cinder-specs/+/736111 discussion: https://wiki.openstack.org/wiki/CinderXenaMidCycleSummary#Support_revert_an… 2. Migration support for a volume with replication status enabled https://review.opendev.org/c/openstack/cinder-specs/+/766130 discussion: https://wiki.openstack.org/wiki/CinderXenaMidCycleSummary#Migration_support… 3. Update original volume az https://review.opendev.org/c/openstack/cinder-specs/+/778437 discussion: https://wiki.openstack.org/wiki/CinderXenaMidCycleSummary#Migration_support… 4. Allow volumes to be part of multiple volume groups https://review.opendev.org/c/openstack/cinder-specs/+/792722 I think this spec isn't getting much attention because it has a -1 from Zuul, and the last few sections still contain the boilerplate language from the spec template, which makes it look like the spec is still in progress. When these have come up for discussion at previous meetings, there is general support among the cinder team, though there are details that we feel need to be worked out on the specs. These details have been noted on the Gerrit reviews and in the previous PTG and midcycle discussion summaries. While some points have been addressed, other important points have not. This makes me think that there is a communication problem between the team and the spec proposers. I encourage people proposing specs that are having problems in review to put their spec on the weekly cinder meeting agenda [1] so that we can discuss them interactively and hopefully explain more clearly what issues the cinder team has with the specs as currently proposed. If attending the weekly cinder meeting (1400 UTC on Wednesdays) is difficult because of time zone issues, please let me know and we can figure something out (maybe an occasional spec review meeting held at some time other than 1400 UTC). Or maybe there's an alternative communication medium we haven't explored yet. The cinder team encourages community participation in cinder development, and it distresses us to see these specs languishing. cheers, brian [0] https://releases.openstack.org/xena/schedule.html#x-cinder-spec-freeze [1] https://etherpad.opendev.org/p/cinder-xena-meetings

1 0

[largescale-sig] Next meeting: June 23, 15utc on #openstack-operators
by Thierry Carrez 23 Jun '21

23 Jun '21

Hi everyone, Our next Large Scale SIG meeting will be this Wednesday in #openstack-operators on OFTC IRC, at 15UTC. Please note the new channel to be used! You can doublecheck how that time translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20210623T15 A number of topics have already been added to the agenda, including discussing our next OpenInfra.Live show. Feel free to add other topics to our agenda at: https://etherpad.openstack.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

1 1

[TC] Open Infra Live- Open Source Governance
by Kendall Nelson 23 Jun '21

23 Jun '21

Hello TC Folks :) So I have been tasked with helping to collect a couple volunteers for our July 29th episode of Open Infra Live (at 14:00 UTC) on open source governance. I am also working on getting a couple members from the k8s steering committee to join us that day. If you are interested in participating, please let me know! I only need like two volunteers, but if we have more people than that dying to join in, I am sure we can work it out. Thanks! -Kendall Nelson (diablo_rojo)

4 5

[cinder] CI coverage for SPDK
by Balazs Gibizer 23 Jun '21

23 Jun '21

Hi Cinder Team, I'm wondering what CI coverage cinder has for SPDK driver. The code mentions that Mellanox CI[1] but I'm not able to find a run from that CI in the recent cinder patches. Is this driver still covered somewhere? Cheers, gibi [1] https://github.com/openstack/cinder/blob/393c2e4ad90c05ebf28cc3a2c65811d7e1…

3 3

[cinder] Bug deputy report for week of 2021-23-06
by Sofia Enriquez 23 Jun '21

23 Jun '21

Hello, This is a bug report from 2021-16-06 to 2021-23-06. You're welcome to join the Cinder Bug Meeting today. Weekly on Wednesday at 1500 UTC on #openstack-cinder Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- High: - CI features discussed last week: - https://bugs.launchpad.net/cinder/+bug/1932188 "lvm commands crash, causing failure" Assigned to Sofia Enriquez and Eric Harney - https://bugs.launchpad.net/os-brick/+bug/1929223 "scaleio connector disables HTTPS certificate validation". Unassigned Medium: - https://bugs.launchpad.net/cinder/+bug/1932964 "SolidFire duplicate volume name exception on migration and replication". Assigned to Fábio Oliveira Low: - https://bugs.launchpad.net/cinder/+bug/1933265 "cinder-backup ceph snapshot delete". Unassigned Wishlist: - https://bugs.launchpad.net/cinder/+bug/1933052 "cinder_internal_tenant_* is not predictable". Unassigned Cheers, Sofia -- L. Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @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 0

[Kolla][nova] /var/lib/nova/instances on nfs
by Ignazio Cassano 23 Jun '21

23 Jun '21

Hello Stackers, is there any configuration parameter in kolla for sharing nova on nfs between compute nodes ? Or I must insert an entry in fstab ? Thanks Ignazio

3 5

[cinder] topics for wednesday's cinder meeting
by Brian Rosmaita 22 Jun '21

22 Jun '21

Hello Cinder Team, There are two topics on the agenda for tomorrow that you may want to look at in advance. First, the specs deadline is Friday, so everyone should be looking at specs: https://review.opendev.org/q/project:openstack%252Fcinder-specs+status:open Second, Simon put a discussion of allowing `black` to be used as an auto-linter on the agenda. The question is whether this should be allowed as an optional tool for developers. There is an example patch posted: https://review.opendev.org/c/openstack/cinder/+/792462 and here is some general info about black: https://black.readthedocs.io/en/stable/the_black_code_style/current_style.h… The choice of a linter can be quite contentious, so the discussion will be timeboxed so that we'll have sufficient time to talk about specs. So I thought I'd sent out notice in advance so that we'll be able to make good use of meeting time. cheers, brian

1 0

[glance] nominating Cyril Roelandt for glance core
by Abhishek Kekane 22 Jun '21

22 Jun '21

Hi All, I am nominating Cyril Roelandt (cyril-roelandt LP and Steap on IRC) to be a Glance core. Cyril has been around the Glance community for a long time and is familiar with the architecture and design patterns used in Glance and its related projects. He's contributed code, triaged bugs, provided bug fixes, and did quality reviews for Glance. He is also helping me in reducing our bug backlogs. Considering the current situation with the project, however, it would be an enormous help to have someone as knowledgeable about Glance as Cyril to have +2 abilities. I discussed this with cyril, he's agreed to be a core reviewer. In any case, I'd like to put Cyril to work as soon as possible! So please reply to this message with comments or concerns before 23:59 UTC on Monday 21 June. I'd like to confirm Cyril as a core on Tuesday 22 June. Thanks and Regards, Abhishek

6 6

[Wallaby][kolla][masakari] hacluser issues
by Ignazio Cassano 22 Jun '21

22 Jun '21

Hello everyone, I wonder if this is a good place for discussing about some issues I am facing with instance HA with masakari hacluster kolla wallaby. Thanks Ignazio

2 8

[ops][victoria][nova] Add hardware to guest (was: [ops][nova][spice][victoria] Switch from VNC to SPICE)
by DHilsbos＠performair.com 22 Jun '21

22 Jun '21

Just realized that I sent this to Sean, but not the list... Sean; Thank you for that pointer to hw_video_model=virtio, that addressed the resolution issue! Any chance you could point me at a metadata option that would tell libvirt to provide 2 monitor devices? It looks like I need to send the max_outputs=2 to qemu, or libvirt or directly to virtio-vga (I'm not sure which) [1], though I don't see a way to pass that through in nova.virt.libvirt.driver [2]. As to how GoToMyPC works... I don't know, but I believe it captures the framebuffer. [1] https://www.kraxel.org/blog/2019/09/display-devices-in-qemu/ [2] https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py Thank you, Dominic L. Hilsbos, MBA Vice President – Information Technology Perform Air International Inc. DHilsbos(a)PerformAir.com www.PerformAir.com -----Original Message----- From: Sean Mooney [mailto:smooney@redhat.com] Sent: Monday, June 21, 2021 4:57 AM To: Dominic Hilsbos; laurentfdumont(a)gmail.com; openstack-discuss(a)lists.openstack.org Subject: Re: [ops][nova][spice][victoria] Switch from VNC to SPICE On Fri, 2021-06-18 at 20:44 +0000, DHilsbos(a)performair.com wrote: > We're trying to virtualize desktops for remote workers. Guests will > be Windows. Remote connection method will be GoToMyPC. As such, I > need the OS to believe either 1) it has 2 1920 x 1080 monitors, or 2) > it has a single 3840 x 1080 monitor. Neither of which have I found a > way to do in VNC. i am not sure the resoltution that rdp or whatever GoToMyPC uses will be affected by the use of vnc or spcice on the host. I think this is related to the video model used in the guets unless GoToMyPC is running on the host and connecting the the qemu process. thats not normally something we would recommend but if its directly conecting to the qemu process then the use of vnc or spice might be a factor have you tried changing the video model to virtio for example, that should enabel more resolutions in the guest. i know that usign RDP in a windows guest with hw_video_model=virtio in the image does allow higher resolutions and i think it enables multi monitor support too. > > Thank you, > > Dominic L. Hilsbos, MBA > Vice President – Information Technology > Perform Air International Inc. > DHilsbos(a)PerformAir.com > www.PerformAir.com > > From: Laurent Dumont [mailto:laurentfdumont@gmail.com] > Sent: Friday, June 18, 2021 12:39 PM > To: Dominic Hilsbos > Cc: stephenfin(a)redhat.com; openstack-discuss > Subject: Re: [ops][nova][spice][victoria] Switch from VNC to SPICE > > Are you using the Openstack console itself? You might have more > flexibility with a dedicated VNC server inside the VM and connect > directly to it. So you would not be tied to the Openstack VNC support > which I dont think was ever designed for graphical usage. More of a > "it's 2AM, server is crashed and I need a way in!". > > On Fri, Jun 18, 2021 at 1:58 PM <DHilsbos(a)performair.com> wrote: > Stephen; > > Thank you for the information. > > What's the replacement? Is VNC getting improvements to allow higher > resolutions, and multi-monitor, in the guest? > > We've already decided to transition our OpenStack cluster away from > CentOS, as RDO doesn't package some of the OpenStack projects we'd > like to use, and RedHat has lost our trust. > > Thank you, > > Dominic L. Hilsbos, MBA > Vice President – Information Technology > Perform Air International Inc. > DHilsbos(a)PerformAir.com > www.PerformAir.com > > > -----Original Message----- > From: Stephen Finucane [mailto:stephenfin@redhat.com] > Sent: Friday, June 18, 2021 10:33 AM > To: Dominic Hilsbos; openstack-discuss(a)lists.openstack.org > Subject: Re: [ops][nova][spice][victoria] Switch from VNC to SPICE > > On Fri, 2021-06-18 at 16:53 +0000, DHilsbos(a)performair.com wrote: > > All; > > > > We have a Victoria cluster, and I'd like to switch from VNC to > > SPICE. Cluster is installed with packages (RDO), and configured > > manually. > > > > I have located > > https://docs.openstack.org/nova/victoria/admin/remote-console-access.html > > , but this doesn't tell me which services need to be installed on > > which servers. > > > > Looking at packages, I'm fairly certain nova-spicehtml5proxy > > (openstack-nova-spicehtml5proxy on CentOS 8) needs to be installed > > where the nova-novncproxy is currently. > > > > I also suspect that qemu-kvm-ui-spice needs to be installed on the > > nova-compute nodes. Is spice-server needed on the nova-compute > > nodes? > > Not an answer, but I'd be very careful about building solutions based > on SPICE. > It has been deprecated in RHEL 8.3 and recent versions of Fedora and > is slated > for removal in RHEL 9, as this bug [1] points out. It is also > receives very > little attention in nova as some deployments tooling (such as Red Hat > OSP) has > not supported it for some time. There's a non-zero chance support for > this > console type will be dropped entirely in some future release. > > Stephen > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1946938 > > > Thank you, > > > > Dominic L. Hilsbos, MBA > > Vice President - Information Technology > > Perform Air International Inc. > > DHilsbos(a)PerformAir.com > > www.PerformAir.com > > > > > > > >

2 2

Reply to: [lists.openstack.org代发][Wallaby][kolla][masakari] hacluser issues
by Sam Su (苏正伟) 22 Jun '21

22 Jun '21

Hi, Ignazio You can discuss about instance HA issue with others on the channel ‘openstack-masakari’in OFTC. They will have a weekly meeting this Tuesday, 4:00-5:00 UTC on the IRC channel. Welcomed. 发件人: Ignazio Cassano [mailto:ignaziocassano@gmail.com] 发送时间: 2021年6月22日 3:06 收件人: openstack-discuss <openstack-discuss(a)lists.openstack.org> 主题: [lists.openstack.org代发][Wallaby][kolla][masakari] hacluser issues Hello everyone, I wonder if this is a good place for discussing about some issues I am facing with instance HA with masakari hacluster kolla wallaby. Thanks Ignazio

3 2

[openstack-helm] No meeting tomorrow
by Gage Hugo 22 Jun '21

22 Jun '21

Hey team, Since there are no agenda items [0] for the IRC meeting tomorrow, the meeting is cancelled. Our next meeting will be June 29th. Thanks [0] https://etherpad.opendev.org/p/openstack-helm-weekly-meeting

1 0

cyborg-tempest-plugin test failed due to the zuul server has no accelerators
by Alex Song (宋文平) 22 Jun '21

22 Jun '21

Hello Everyone, Is the Zuul server env changed recently? There are no accelerators and our cyborg-tempest-plugin test failed. Please help. Thanks. Best Regards.

4 5

[cinder] Stepping down from cinder core
by Lucio Seki 21 Jun '21

21 Jun '21

Hi, I've been totally absent from the community in the last cycle, and unfortunately I'm not able to review Cinder patches in the next few cycles either. For this reason, I'm stepping down from the core team. Thank you all for the patience and attention to teach me so many things. It was a great opportunity for me to learn and grow professionally and personally. Hopefully sometime in the future I'll come back to the community again. Kind regards and stay safe, Lucio Seki

3 2

[interop] Preping up for June Board meeting
by Arkady Kanevsky 21 Jun '21

21 Jun '21

Team, as I prepare for the June OIF board meeting we need to do 3 things: 1. Need review and land https://review.opendev.org/c/osf/interop/+/796312 to remove requirement that one of Interop WG co-chair is from the board and nominated by the board. 2. Need to review and land https://review.opendev.org/c/osf/interop/+/784622 that has been discussed several times and is needed to match https://opendev.org/osf/interop/src/branch/master/doc/source/process/2021A.… . 3. Final comments on presentation slides for the board - https://docs.google.com/presentation/d/1-9H1cTXZxW0vCSTzfBe0aMKbd7nggd8SOHQ… We need to complete it by Monday June 21 so I can send it to the board 1 week before the meeting. Thanks, -- Arkady Kanevsky, Ph.D. Phone: 972 707-6456 Corporate Phone: 919 729-5744 ext. 8176456

3 4

[neutron] Bug deputy report for week of June 14th
by Lajos Katona 21 Jun '21

21 Jun '21

Hi, I was last week's bug deputy for Neutron, Below is a short summary of last week's bugs: Critical --------- - https://bugs.launchpad.net/neutron/+bug/1932093 - "oslo_config.cfg.DuplicateOptError: duplicate option: host" using OVN Octavia provider on stable/train - https://review.opendev.org/c/openstack/networking-ovn/+/796517 - - https://bugs.launchpad.net/neutron/+bug/1932483 - CI neutron.tests.functional.services.l3_router.test_l3_dvr get failed frequently - *Unassigned* High ------- - https://bugs.launchpad.net/neutron/+bug/1932421 - ovn-neutron-db-sync deletes legitimate metadata ports - https://review.opendev.org/q/I78673b6a85f1c872e70026da82124d1ba2326562 - https://bugs.launchpad.net/neutron/+bug/1933026 - stack.sh fail with ovs_source: No such file or directory - CI of some project fails with: "/opt/stack/neutron/devstack/plugin.sh: line 23: /opt/stack/devstack/lib/neutron_plugins/ovs_source: No such file or directory" after https://review.opendev.org/c/openstack/neutron/+/793470 is merged. - *Unassigned* Medium ----------- - Low ------ - https://bugs.launchpad.net/neutron/+bug/1932016 - Quality of Service (QoS) in Neutron, error in permissions - Doc fix: https://review.opendev.org/c/openstack/neutron/+/796457 - https://bugs.launchpad.net/neutron/+bug/1932373 - DB migration is interrupted and next execution will fail - Upgrade from Rocky to Victoria fails on db migration, and traceback points to binding index ( https://review.opendev.org/c/openstack/neutron/+/692285 ) but I can't reproduce the issue RFE ------- - https://bugs.launchpad.net/neutron/+bug/1931953 - [RFE] Openflow-based DVR L3 - Agreement on Drivers meeting was that the final goal should be to replace current DVR solution to have only one driver maintained. - https://bugs.launchpad.net/neutron/+bug/1932154 - [rfe] Off-path SmartNIC Port Binding - spec: https://review.opendev.org/c/openstack/neutron-specs/+/788821 Won't fix ------------ - https://bugs.launchpad.net/neutron/+bug/1931844 - Can't ping router with packet size greater than 1476 when ovs datapath_type set to netdev - "ovs datapath_type netdev" should only be used for VM, neutron router related virtual network devices are not compatible with it

2 1

[oslo] TaCT SIG volunteer
by Herve Beraud 21 Jun '21

21 Jun '21

Hi everyone, We are looking for volunteers to endorse the TaCT SIG liaison role for Oslo. Our previous volunteers are no longer active. Indeed, Moisés officially announced his retirement from Oslo two weeks ago, and Sébastien did not attend our meetings for some time. Here are the details about this role: https://governance.openstack.org/sigs/tact-sig.html Let us know if you're interested in this role, by replying to this thread or by joining us during our meetings (next meeting: July 05). Thanks for your attention. -- 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

[tc][all] Test support for TLS default
by Rico Lin 21 Jun '21

21 Jun '21

Dear all In short, can you help to enable tls-proxy for your test jobs and fix/report the issue in [4]? Or it makes no sense for you? Here's all repositories contains jobs with tls-proxy disabled: - neutron - neutron-tempest-plugin - cinder-tempest-plugin - cyborg-tempest-plugin - ec2api-tempest-plugin - freezer-tempest-plugin - grenade - heat - js-openstack-lib - keystone - kuryr-kubernetes - masakari - murano - networking-odl - networking-sfc - python-brick-cinderclient-ext - python-neutronclient - python-zaqarclient - sahara - sahara-dashboard - sahara-tests - solum - tacker - telemetry-tempest-plugin - trove - trove-tempest-plugin - vitrage-tempest-plugin - watcher As I'm looking for y-cycle potential goals, I found the tls-proxy support is not actually ready OpenStack wide (you can find some discussion in [3]). We have multiple projects that disable tls-proxy in test jobs [1] (and stay that way for a long time). For security concerns, I'm currently collecting the missing part for this. And try to figure out if there is any infra issue for current jobs. After I attempt to enable tls-proxy for some projects to check the status. And from the test result shows ([2]), We might have bugs/test infra issues in projects. So I invite projects who still have not switched to TLS default. Please do, and help to fix/report the issue you're facing. As we definitely need some more help on figuring out the actual situation on each project. So I created an etherpad [4] to track actions or related information. Meanwhile, I will attempt to enable tls-proxy on more test jobs (and you will be able to find it in [2]). Which gives us a good chance to review the logs and see how we might get chances to fix it and enable TLS by default. [1] https://codesearch.opendev.org/?q=tls-proxy%3A%20false&i=nope&files=&exclud… [2] https://review.opendev.org/q/topic:%22exame-tls-proxy%22+(status:open%20OR%… [3] https://etherpad.opendev.org/p/community-goals [4] https://etherpad.opendev.org/p/support-tls-default *Rico Lin* OIF Board director, OpenStack TC, Multi-arch SIG chair, Heat PTL, Senior Software Engineer@EasyStack

3 2

[ops][nova][spice][victoria] Switch from VNC to SPICE
by DHilsbos＠performair.com 21 Jun '21

21 Jun '21

All; We have a Victoria cluster, and I'd like to switch from VNC to SPICE. Cluster is installed with packages (RDO), and configured manually. I have located https://docs.openstack.org/nova/victoria/admin/remote-console-access.html, but this doesn't tell me which services need to be installed on which servers. Looking at packages, I'm fairly certain nova-spicehtml5proxy (openstack-nova-spicehtml5proxy on CentOS 8) needs to be installed where the nova-novncproxy is currently. I also suspect that qemu-kvm-ui-spice needs to be installed on the nova-compute nodes. Is spice-server needed on the nova-compute nodes? Thank you, Dominic L. Hilsbos, MBA Vice President - Information Technology Perform Air International Inc. DHilsbos(a)PerformAir.com www.PerformAir.com

4 6

[cinder][kolla][OpenstackAnsible] Wallaby Cycle-Trailing Release Deadline
by Herve Beraud 21 Jun '21

21 Jun '21

Hello teams with trailing projects, Next week is the Wallaby cycle-trailing release deadline [1], and all projects following the cycle-trailing release model must release their Wallaby deliverables by 02 July, 2021. The following trailing projects haven't been released yet for Wallaby (aside the release candidates versions). Cinder team's deliverables: - cinderlib OSA team's deliverables: - openstack-ansible-roles - openstack-ansible Kolla team's deliverables: - kayobe - kolla - kolla-ansible This is just a friendly reminder to allow you to release these projects in time. Do not hesitate to ping us if you have any questions or concerns. [1] https://releases.openstack.org/xena/schedule.html#x-cycle-trail -- 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

Ceph RADOSGW Keystone integration - S3 bucket policies targeting not just whole projects but particular users?
by Christian Rohmann 21 Jun '21

21 Jun '21

Hallo Openstack-Users, (this is somewhat of a cross-port with the ceph-users ML, I just did not know where to ask about this best) I've been wondering about the state of OpenStack Keystone Auth in RADOSGW, especially in regards to the abilities to utilize bucket policies restricting access to only those users and only those objects which are required. 1) Even though the general documentation on RADOSGW S3 bucket policies is a little "misleading" https://docs.ceph.com/en/latest/radosgw/bucketpolicy/#creation-and-removal in showing users being referred as Principal, the documentation about Keystone integration at https://docs.ceph.com/en/latest/radosgw/keystone/#integrating-with-openstac… clearly states, that "A Ceph Object Gateway user is mapped into a Keystone <tenant>"||. In the keystone authentication code it strictly only takes the project from the authenticating user: * https://github.com/ceph/ceph/blob/6ce6874bae8fbac8921f0bdfc3931371fc61d4ff/… * https://github.com/ceph/ceph/blob/6ce6874bae8fbac8921f0bdfc3931371fc61d4ff/… This is rather unfortunate as this renders the usually powerful S3 bucket policies to be rather basic with granting access to all users (with a certain role) of a project or more importantly all users of another project / tenant, as in using arn:aws:iam::$OS_REMOTE_PROJECT_ID:root as principal. Or am I just misreading anything here or is this really all that can be done if using native keystone auth? Apparently I was not the only one wondering ... https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/7MXUZ63DEH7… 2) There is a PR open implementing generic external authentication https://github.com/ceph/ceph/pull/34093 Apparently this seems to also address the lack of support for subusers for Keystone - if I understand this correctly I could then grant access to users arn:aws:iam::$OS_REMOTE_PROJECT_ID:$user * Are there any plans on the roadmap to extend the functionality in regards to keystone as authentication backend? * Is anybody using another (custom) solution to allow a more fine-grained user and access management when utilizing Ceph for their object storage? Are you potentially not using Keystone directly and use a central database such as an LDAP and have Ceph and Keystone use that independently? Regards Christian

1 0

Wallaby install via kayobe onto ubuntu 20 all in one host
by Tony Pearce 21 Jun '21

21 Jun '21

I'm trying to run "kayobe overcloud host configure" against an ubuntu 20 machine to deploy Wallaby. I'm getting an error that python is not found during the host configure part. PLAY [Verify that the Kayobe Ansible user account is accessible] TASK [Verify that a command can be executed] fatal: [juc-ucsb-5-p]: FAILED! => {"changed": false, "module_stderr": "/bin/sh: 1: /usr/libexec/platform-python: not found\n", "module_stdout": "", "msg": "The module failed to execute correctly, you probably need to set the interpreter.\nSee stdout/stderr for the exact error", "rc": 127} Python3 is installed on the host. When searching where this platform-python is coming from it returns the kolla-ansible virtual envs: $ grep -rni -e "platform-python" venvs/kolla-ansible/lib/python3.8/site-packages/ansible/config/base.yml:1450: '8': /usr/libexec/platform-python venvs/kolla-ansible/lib/python3.8/site-packages/ansible/config/base.yml:1470: - /usr/libexec/platform-python I had a look through the deployment guide for Kayobe Wallaby and didnt see a note about changing this. Do I need to do further steps to support the ubuntu overcloud host? I have already set (as per the doc): os_distribution: ubuntu os_release: focal Regards, Tony Pearce

3 14

[kayobe][train] kolla_copy_ca_into_containers variable
by Tony Pearce 21 Jun '21

21 Jun '21

I have deployed Train with Kayobe. I'd like to enable SSL using a cert which is signed but NOT by a public CA. This means I need to add the CA cert to the containers. I came across this doc [1] and I wanted to ask / discover when this variable comes into play "kolla_copy_ca_into_containers"? Does this variable work only from Victoria onwards or will it work in Train? Do I require to have a "seed" to build containers, to enable this cert copy into containers? (kayobe overcloud container image build). OR if I do "kayobe overcloud container image pull" will the cert be copied at that point? [1] OpenStack Docs: TLS <https://docs.openstack.org/kolla-ansible/victoria/admin/tls.html> Thanks and regards, Tony Pearce

2 2

Nova shows incorrect VM status when compute is down.
by Ramesh Ramanathan B 21 Jun '21

21 Jun '21

Dear All, One observation we have while using Open Stack Rocky is, when a compute node goes down, the VM status still shows active (the servers running in the compute node that went down). Is this the expected behavior? Any configurations required to get the right status. In the attached image the compute is down, but the VM status still shows active. We are running a data center so it is not practical to run nova reset-state for all the servers. Is there an API to force update Nova to show the correct status? Or any configurations missing that is causing this? Thanks Regards, Ramesh ________________________________ Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient of this message , or if this message has been addressed to you in error, please immediately alert the sender by reply email and then delete this message and any attachments. If you are not the intended recipient, you are hereby notified that any use, dissemination, copying, or storage of this message or its attachments is strictly prohibited. Email transmission cannot be guaranteed to be secure or error-free, as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender, therefore, does not accept liability for any errors, omissions or contaminations in the contents of this message which might have occurred as a result of email transmission. If verification is required, please request for a hard-copy version. ________________________________

3 3

[nova] SCS standardized flavor naming
by Kurt Garloff 19 Jun '21

19 Jun '21

Hi, we (SCS) are working on defining a fully open source cloud and container stack as part of the Gaia-X[1] project. The intention is to provide a common well-standardized way to deploy, manage, configure, and operate the needed software. The vision is to have a network of federated clouds that can be used as one, which requires IAM federation and a high level of compatibility and uniformity. Our project is called Sovereign Cloud Stack (SCS)[2]. Obviously, we are using existing open source projects from the OIF, the CNCF and others and are seeking alignment with these communities. Some experts well-known in the OpenStack universe are participating in our effort. On the OpenStack side, we are using OSISM[3] which leverages kolla-ansible. We would like to seek your input and feedback into our attempt of defining a standardized naming scheme for flavors and a list of standard flavors available in all clouds that deliver SCS-compliant IaaS. Find the draft proposal at https://github.com/SovereignCloudStack/Operational-Docs/blob/main/flavor-na… We prefer feedback as github issues and/or PRs. Knowing that the OpenStack community prefers gerrit, we'll of course also incorporate any comment we get via this mailing list into our thinking. We hope you can accept us pasting content from mails into github issues, so we create a track record of the taken decisions. (Please indicate if this is not OK for you and we'll refrain from doing so.) Before you ask why we believe the proposal is useful: We are perfectly aware that it is possible to discover flavor properties; however, in many automation recipes (playbooks, terraform vars etc) we find flavor names encoded and it is one pain point having to adapt them on every cloud that you use. So we want to have some uniformity on this across SCS clouds. (With similar reasoning, expect a image naming and image metadata proposal next.) We are looking for feedback in two directions: (1) If you are aware of similar efforts to standardize flavor naming, please point us to it, so we can seek contact and align. (2) Please look at the proposal itself. When looking into the details how we specify how to optionally(!) encode a number of details into flavor names, please keep in mind that this is indeed optional. We expect most flavor names to be as simple as SCS-4V:8:20 or even SCS-4V:8, even though complicated SCS-8C:32:2x200S-bms-i2-GNa:64-ib [4] is possible for clouds that provide that level of differentiation and want/need to expose this via the flavor name. Of course, input from existing providers of OpenStack infrastructure is particularly valuable. Feedback welcome! [1] https://gaia-x.eu/ [2] https://scs.community/ [3] https://osism.de/ [4] In case you wonder: 8 dedicated cores, 32GiB RAM, 2x200GB SSD disks on bare metal sys, intel Cascade Lake, nVidia GPU with 64 Ampere SMs and InfiniBand. PS: Cc'ing some folks who have contributed to this. -- Kurt Garloff CTO Sovereign Cloud Stack OSB Alliance e.V.

2 3

[all][tc] What's happening in Technical Committee: summary 18th June, 21: Reading: 5 min
by Ghanshyam Mann 19 Jun '21

19 Jun '21

Hello Everyone, Here is last week's summary of the Technical Committee activities. 1. What we completed this week: ========================= * Deprecated devstack-gate project[1] * Updated project-team-guide for the meeting channel preference[2] * TC voted the Y release proposed names and forwarded it for the next step of trademark checks. 2. TC Meetings: ============ * TC held this week meeting on Thursday; you can find the full meeting logs in the below link: - https://meetings.opendev.org/meetings/tc/2021/tc.2021-06-17-15.00.log.html * We will have next week's meeting on June 24th, Thursday 15:00 UTC[3]. 3. Activities In progress: ================== TC Tracker for Xena cycle ------------------------------ TC is using the etherpad[4] for Xena cycle working item. We will be checking and updating the status biweekly in the same etherpad. Open Reviews ----------------- * One open review for ongoing activities[5]. Migration from Freenode to OFTC ----------------------------------------- * We are in 'Communicate with community' work where all projects need to update all contributor doc etc. Please finish this in your project and mark the progress in etherpad[6]. * I wrote a small blog in OpenStack blog[7]. * All the required work for this migration is tracked in this etherpad[6] 'Y' release naming process ------------------------------- * Y release naming election is closed now. As a last step, the foundation is doing trademark checks on elected ranking. Retiring panko ----------------- * panko project is in process of retirement[8] Test support for TLS default: ---------------------------------- Rico has started a separate email thread over testing with tls-proxy enabled[9], we encourage projects to participate in that testing and help to enable the tls-proxy in gate testing. Retiring governance's in-active repos ------------------------------------------- The Technical Committee retiring the governance's in-active repos which are not required in current structure[10]. 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[11]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [12] 3. Office hours: The Technical Committee offers a weekly office hour every Tuesday at 0100 UTC [13] 4. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://review.opendev.org/c/openstack/governance/+/795385 [2] https://docs.openstack.org/project-team-guide/open-community.html#public-me… [3] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [4] https://etherpad.opendev.org/p/tc-xena-tracker [5] https://review.opendev.org/q/project:openstack/governance+status:open [6] https://etherpad.opendev.org/p/openstack-irc-migration-to-oftc [7] https://www.openstack.org/blog/the-openstack-community-irc-network-moved-to… [8] https://review.opendev.org/c/openstack/governance/+/796408 [9] http://lists.openstack.org/pipermail/openstack-discuss/2021-June/023000.html [10] https://etherpad.opendev.org/p/governance-repos-cleanup [11] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [12] http://eavesdrop.openstack.org/#Technical_Committee_Meeting [13] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours -gmann

1 0

Allowing custom role to add users
by Derek O keeffe 18 Jun '21

18 Jun '21

Hi all, I have created a role (project_admin) and have given access to anyone with that role to be allowed delete VM's in their group/project. I am trying to allow that user to now add or remove users in the domain but I can't seem to figure it out. I have edited the /etc/keystone/policy.yaml and added role:project_admin to the create user rule. Is this the way I should be doing it? Or does anyone have any advice? Thanks in advance and happy Friday :) Regards,Derek

1 1

packstack stuck at Testing if puppet apply is finished: x.x.x.x_compute.pp
by cloud learner 18 Jun '21

18 Jun '21

Dear Experts, I have installed the single node all in one using victoria, i have to add the new node in current setup, as documented at RDO site, we have to made changes in EXCLUDE_SERVER=controllerip CONFIG_COMPUTE_HOST=newcompute ip, i edited the answer file and run on the controller node but it stuck at Testing if puppet apply is finished: X.X.X.X_compute.pp And it does not show any error, kindly suggest. Thanks

1 0

ImportError: cannot import name greenpool
by Pete Zhang 18 Jun '21

18 Jun '21

Not sure if my previous email went through or not. Just resend it. We hit this error during "glance-manage db_sync": *ImportError: cannot import name greenpool.* Any idea what the root cause is and how to fix it? We have the following rpms installed (thought related). python2-greenlet-0.4.9-1.el7.x86_64.rpm python2-eventlet-0.18.4-2.el7.noarch.rpm python2-gevent-1.1.2-2.el7.x86_64.rpm Debug: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: Sleeping for 5 seconds between tries Debug: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: Exec try 10/10 Debug: Exec[neutron-db-sync](provider=posix): Executing 'neutron-db-manage upgrade heads' Debug: Executing: 'neutron-db-manage upgrade heads' Debug: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: Sleeping for 5 seconds between tries Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: Traceback (most recent call last): Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/bin/neutron-db-manage", line 10, in <module> Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: sys.exit(main()) Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/neutron/db/migration/cli.py", line 657, in main Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: return_val |= bool(CONF.command.func(config, CONF.command.name <http://conf.command.name/>)) Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/neutron/db/migration/cli.py", line 179, in do_upgrade Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: run_sanity_checks(config, revision) Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/neutron/db/migration/cli.py", line 641, in run_sanity_checks Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: script_dir.run_env() Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/alembic/script/base.py", line 425, in run_env Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: util.load_python_file(self.dir, 'env.py') Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/alembic/util/pyfiles.py", line 81, in load_python_file Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: module = load_module_py(module_id, path) Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/alembic/util/compat.py", line 141, in load_module_py Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: mod = imp.load_source(module_id, path, fp) Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/neutron/db/migration/alembic_migrations/env.py", line 24, in <module> Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: from neutron.db.migration.models import head # noqa Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/neutron/db/migration/models/head.py", line 28, in <module> Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: from neutron.common import utils Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/neutron/common/utils.py", line 35, in <module> Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: import eventlet Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/eventlet/__init__.py", line 10, in <module> Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: from eventlet import convenience Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/eventlet/convenience.py", line 4, in <module> Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: from eventlet import greenpool Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: ImportError: cannot import name greenpool Error: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]: Failed to call refresh: 'neutron-db-manage upgrade heads' returned 1 instead of one of [0] Error: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]: 'neutron-db-manage upgrade heads' returned 1 instead of one of [0] Notice: /Stage[main]/Neutron::Deps/Anchor[neutron::dbsync::end]: Dependency Exec[neutron-db-sync] has failures: true -- <https://smart.salesforce.com/sig/peiyong.zhang//us_mb/default/link.html>

3 5

[neutron] Drivers meeting agenda for 18.06.2021
by Slawek Kaplonski 18 Jun '21

18 Jun '21

Hi, Agenda for tomorrow's drivers meeting is at [1]. We have one new RFE to discuss [2] - It's another approach to do OpenFlow based DVR :) We have also one new RFE [3] which I would like You to check and help triaging before we will discuss it in the drivers meeting. [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers#Agenda [2] https://bugs.launchpad.net/neutron/+bug/1931953 [3] https://bugs.launchpad.net/neutron/+bug/1932154 -- Slawek Kaplonski Principal Software Engineer Red Hat

4 7

[victoria][cinder ?] Dell Unity + Iscsi
by Albert Shih 17 Jun '21

17 Jun '21

Hi everyone I've a small openstack configuration with 4 computes nodes, a Dell Unity 480F for the storage. I'm using cinder with iscsi. Everything work when I create a instance. But some instance after few time are not reponsive. When I check on the hypervisor I can see [888240.310461] sd 14:0:0:2: [sdb] tag#120 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [888240.310493] sd 14:0:0:2: [sdb] tag#120 Sense Key : Illegal Request [current] [888240.310502] sd 14:0:0:2: [sdb] tag#120 Add. Sense: Logical unit not supported [888240.310510] sd 14:0:0:2: [sdb] tag#120 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00 [888240.310519] blk_update_request: I/O error, dev sdb, sector 0 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0 [888240.311045] sd 14:0:0:2: [sdb] tag#121 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [888240.311050] sd 14:0:0:2: [sdb] tag#121 Sense Key : Illegal Request [current] [888240.311065] sd 14:0:0:2: [sdb] tag#121 Add. Sense: Logical unit not supported [888240.311070] sd 14:0:0:2: [sdb] tag#121 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00 [888240.311074] blk_update_request: I/O error, dev sdb, sector 0 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0 [888240.342482] sd 14:0:0:2: [sdb] tag#70 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [888240.342490] sd 14:0:0:2: [sdb] tag#70 Sense Key : Illegal Request [current] [888240.342496] sd 14:0:0:2: [sdb] tag#70 Add. Sense: Logical unit not supported I check on the hypervisor, no error at all on the ethernet interface. I check on the switch, no error at all on the interface on the switch. No sure but it's seem the problem appear more often when the instance are doing nothing during some time. Every firmware, software on the Unity are uptodate. The 4 computes are exactly same, they run the same version of the nova-compute & OS & firmware on the hardware. Any clue ? Or place to search the problem ? Regards -- Albert SHIH Observatoire de Paris xmpp: jas(a)obspm.fr Heure local/Local time: Tue Jun 1 08:27:42 PM CEST 2021

3 3

[dev] Mass patch filing for skipdist->skipsdist in tox.ini
by Jeremy Stanley 17 Jun '21

17 Jun '21

I just pushed changes for the master branches of 26 projects under topic:tox-skipsdist to correct a frequent typographical error found in many projects' tox.ini files, which seems to get copied around a lot. I'm hoping by getting rid of the mistake everywhere we can stamp out future cargo-cult copies. The skipsdist option is set by many projects to avoid unilaterally building an sdist of the local tree every time tox is invoked, which can sometimes be quite time-consuming. Unfortunately it's all too easy to miss that 's' in the middle of the option name, and since tox ignores options it doesn't recognize, this ends up not having the intended effect. If you would rather keep the current behavior in your project, feel free to amend the change to one which removes the invalid "skipdist" line from your tox.ini instead. If you want to backport this to your stable branches, you can do that as well (it may even save some seconds on average tox-based job runtime); my main concern was more for people copying the mistake around, and it's far more likely they'll be copying from master branches so I didn't bother proposing any backports. -- Jeremy Stanley

1 0