June 2021 - openstack-discuss - lists.openstack.org

[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