July 2020 - openstack-discuss - lists.openstack.org

[tripleo] updating the language we use in our code base
by Wesley Hayutin 08 Jul '20

08 Jul '20

Greetings, At this moment in time we have an opportunity to be a more open and inclusive project by eliminating outdated naming conventions from our code base [1]. We should take the opportunity and do our best to replace outdated terms with their more inclusive alternatives. Chris Wright wrote a nice blog post on the subject [2], please take a second to review Bogdan's spec and Chris's blog post. Also a thank you to Emilien, Alex and Bogdan for already getting started. In other news Arx Cruz will be starting a similar thread for the tempest project. Thanks Arx! [1] https://review.opendev.org/#/c/740013/1/specs/victoria/renaming_rules.rst [2] https://www.redhat.com/en/blog/making-open-source-more-inclusive-eradicatin… Patches to be aware of: https://review.opendev.org/#/c/738858/ https://review.opendev.org/#/c/738894/ <https://review.opendev.org/#/c/738894/1> https://review.opendev.org/#/c/740013 Thanks for your time!

1 0

[Neutron] GRE network MTU
by Budai Laszlo 08 Jul '20

08 Jul '20

Dear all, what is the maximum MTU value for a GRE network? How is that related to the physical interfaces' MTU? Thank you, Laszlo

1 0

[largescale-sig] Next meeting: July 8, 8utc
by Thierry Carrez 08 Jul '20

08 Jul '20

Hi everyone, Hot on the heels of the OpenDev event on Large scale deployments, the Large Scale SIG will have a meeting this week on Wednesday, July 8 at 8 UTC[1] in the #openstack-meeting-3 channel on IRC: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200708T08 Feel free to add topics to our agenda at: https://etherpad.openstack.org/p/large-scale-sig-meeting A reminder of the TODOs we had from last meeting, in case you have time to make progress on them: - amorin to add some meat to the wiki page before we push the Nova doc patch further - all to describe briefly how you solved metrics/billing in your deployment in https://etherpad.openstack.org/p/large-scale-sig-documentation - ttx to produce a draft of the 10th birthday slide for the SIG Talk to you all on Wednesday, -- Thierry Carrez

1 1

[ironic] 2nd Victoria meetup
by Dmitry Tantsur 07 Jul '20

07 Jul '20

Hi all, Since we're switching to 6 releases per year cadence, I think it makes sense to have short virtual meetups after every release. The goal will be to sync on priorities, exchange ideas and define plans for the upcoming 2 months of development. Fooling around is also welcome! Please vote for the best 2 hours slot next week: https://doodle.com/poll/3r9tbhmniattkty8. I tried to include more potential time zones, so apologies for so many options. Please cast your vote until Friday, 12pm UTC, so that I can announce the final time slot this week. Dmitry

2 4

[keystone][zun] Choice between 'ca_file' and 'cafile'
by Hongbin Lu 07 Jul '20

07 Jul '20

Hi all, A short question. I saw a few projects are using the name 'ca_file' [1] as config option, while others are using 'cafile' [2]. I wonder what is the flavorite name convention? I asked this question because Kolla developer suggested Zun to rename from 'ca_file' to 'cafile' to avoid the confusion [3]. I want to confirm if this is a good idea from Keystone's perspective. Thanks. Best regards, Hongbin [1] http://codesearch.openstack.org/?q=cfg.StrOpt%5C(%27ca_file%27&i=nope&files… [2] http://codesearch.openstack.org/?q=cfg.StrOpt%5C(%27cafile%27&i=nope&files=… [3] https://review.opendev.org/#/c/738329/

4 3

[openstack-helm] Proposing Andrii Ostapenko for core of OpenStack-Helm
by Gage Hugo 07 Jul '20

07 Jul '20

Hello everyone, Andrii Ostapenko (andrii_ostapenko) has been very active lately in the openstack-helm community, notably his efforts in driving loci forward as well as him maintaining a lot of our images and providing great in-depth reviews. Due to these reasons, I am proposing Andrii as a core reviewer for OpenStack-Helm. If anyone has any feedback, please feel free to reply here by the end of the week!

1 0

[nova] Changes for out-of-tree drivers
by Stephen Finucane 07 Jul '20

07 Jul '20

I have a change proposed [1] as part of the work to add vTPM support to nova that will modify the arguments for the 'unrescue' function. As noted in the commit message, this is expected to gain a 'context' argument and lose the currently unused 'network_info' argument. If you maintain an out-of-tree driver, you will need to account for this change. Cheers, Stephen [1] https://review.opendev.org/#/c/730382/

1 0

[glance] Global Request ID issues in Glance
by Markus Hentsch 07 Jul '20

07 Jul '20

Hello everyone, while I was experimenting with the Global Request ID functionality of OpenStack [1], I identified two issues in Glance related to this topic. I have written my findings below and would appreciate it if you could take a look and confirm whether those are intended behaviors or indeed issues with the implementation. In case of the latter please advice me which bug tracker to report them to. 1. The Glance client does not correctly forward the global ID When the SessionClient class is used, the global_request_id is removed from kwargs in the constructor using pop() [2]. Directly after this, the parent constructor is called using super(), which in this case is Adapter from the keystoneauth1 library. Therein the global_request_id is set again [3] but since it has been removed from the kwargs, it defaults to None as specified in the Adapter's __init__() header. Thus, the global_request_id passed to the SessionClient constructor never actually makes it to the Glance API. This is in contrast to the HTTPClient class, where get() is used instead of pop() [4]. This can be reproduced simply by creating a server in Nova from an image in Glance, which will attempt to create the Glance client instance using the global_request_id [5]. Passing the "X-Openstack-Request-Id" header during the initial API call for the server creation, makes it visible in Nova (using a suitable "logging_context_format_string" setting) but it's not visible in Glance. Using a Python debugger shows Glance generating a new local ID instead. 2. Glance interprets global ID as local one for Oslo Context objects While observing the Glance log file, I observed Glance always logging the global_request_id instead of a local one if it is available. Using "%(global_request_id)s" within "logging_context_format_string"[6] in the glance-api.conf will always print "None" in the logs whereas "%(request_id)s" will either be an ID generated by Glance if no global ID is available or the received global ID. Culprit seems to be the context middleware of Glance where the global ID in form of the "X-Openstack-Request-Id" header is parsed from the request and passed as "request_id" instead of "global_request_id" to the "glance.context.RequestContext.from_environ()" call [7]. This is in contrast to other services such as Nova or Neutron where the two variables actually print the values according to their name (request_id always being the local one, whereas global_request_id is the global one or None). [1] https://specs.openstack.org/openstack/oslo-specs/specs/pike/global-req-id.h… [2] https://github.com/openstack/python-glanceclient/blob/de178ac4382716cc93022… [3] https://github.com/openstack/keystoneauth/blob/dab8e1057ae8bb9a0e778fb8d314… [4] https://github.com/openstack/python-glanceclient/blob/de178ac4382716cc93022… [5] https://github.com/openstack/nova/blob/1cae0cd7229207478b70275509aecd778ca6… [6] https://docs.openstack.org/oslo.context/2.17.0/user/usage.html#context-vari… [7] https://github.com/openstack/glance/blob/e6db0b10a703037f754007bef6f5645108… Thanks! Markus -- Markus Hentsch Team Leader secustack GmbH - Digital Sovereignty in the Cloud https://www.secustack.com Königsbrücker Straße 96 (Gebäude 30) | 01099 Dresden District Court Dresden, Register Number: HRB 38890

2 2

[nova][stable] The openstack/nova stable/pike branch is currently unmaintained
by Lee Yarwood 06 Jul '20

06 Jul '20

Hello all, Following on from my recent mail about the stable/ocata branch of the openstack/nova project now being unmaintained [1] I'd also like to move the stable/pike [2] branch formally into this phase of maintenance [3]. Volunteers are welcome to step forward and attempt to move the branch back to the ``Extended Maintenance`` phase by proposing changes and fixing CI in the next 3 months, otherwise the branch will be marked as ``EOL`` [4]. Again hopefully this isn't taking anyone by surprise but please let me know if this is going to be an issue! Regards, [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-July/015747.html [2] https://review.opendev.org/#/q/project:openstack/nova+branch:stable/pike [3] https://docs.openstack.org/project-team-guide/stable-branches.html#unmainta… [4] https://docs.openstack.org/project-team-guide/stable-branches.html#end-of-l… -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76

2 2

removing use of pkg_resources to improve command line app performance
by Doug Hellmann 06 Jul '20

06 Jul '20

We have had a long-standing issue with the performance of the openstack command line tool. At least part of the startup cost is the time taken in scanning for all of the plugins that are installed, which is a side-effect of importing pkg_resources. To fix that, we need to eliminate all use of pkg_resources in code that would be used by a command line application (long-running services are candidates, too, but the benefit is bigger in short-lived command line apps). Python 3.8 added a new library importlib.metadata, which also has an entry points API. It is more efficient, and produces data in a format that can be cached to make it even faster. I have started adding support for that caching to stevedore [0], which is the Oslo library for managing application plugins. For version of python earlier than 3.8, the same library is available on PyPI as “importlib_metadata”. A big part of the implementation work will actually be removing the use of pkg_resources in places other than stevedore. We have a couple of different use patterns to consider and replace in different ways. First, anything using iter_entry_points() should use a stevedore extension manager instead. There are a few of them to choose from, based on how the plugins will be used. The stevedore docs [1] include a tutorial and documentation for all of the classes and their uses. Most calls to iter_entry_points() can be replaced with a stevedore.ExtensionManager directly, but the other managers are meant to implement common access patterns like selecting a subset (or just one) of the available plugins by name. Second, we have a few places where pkg_resources.get_distribution(name).version is used to discover a package’s installed version. Those can be changed to use importlib.metadata.version() instead, as in [2]. This is *much* faster because importlib goes directly to the metadata file for the named package instead of looking through all of the installed packages. Finally, any code using any properties of the EntryPoint returned by stevedore other than “name” and “load()” may need to be updated. The new EntryPoint class in importlib.metadata is not 100% compatible with the one from pkg_resources. The same data is there, but sometimes it is named differently. If we need a compatibility layer we could put that in stevedore, but it is unusual to need access to any of the internals of EntryPoint and it’s typically better to use the manager abstractions in stevedore instead of manipulating EntryPoint instances directly. I have started making some of the changes [3], but I’m doing this in my quarantine-induced spare time so it’s likely to take a while. If you want to pitch in, I would appreciate it. I am using the topic “osc-performance”, since the work is related to making python-openstackclient faster. Feel free to tag me for reviews on your patches. Doug [0] https://review.opendev.org/#/c/739306/ [1] https://docs.openstack.org/stevedore/latest/ [2] https://review.opendev.org/#/c/739379/2 [3] https://review.opendev.org/#/q/topic:osc-performance

4 8