May 2020 - openstack-discuss - lists.openstack.org

Ussuri RDO Release Announcement
by Amy Marrich 28 May '20

28 May '20

If you're having trouble with the formatting, this release announcement is available online https://blogs.rdoproject.org/2020/05/rdo-ussuri-released/ --- *RDO Ussuri Released* The RDO community is pleased to announce the general availability of the RDO build for OpenStack Ussuri for RPM-based distributions, CentOS Linux and Red Hat Enterprise Linux. RDO is suitable for building private, public, and hybrid clouds. Ussuri is the 21st release from the OpenStack project, which is the work of more than 1,000 contributors from around the world. The release is already available on the CentOS mirror network at http://mirror.centos.org/centos/8/cloud/x86_64/openstack-ussuri/. The RDO community project curates, packages, builds, tests and maintains a complete OpenStack component set for RHEL and CentOS Linux and is a member of the CentOS Cloud Infrastructure SIG. The Cloud Infrastructure SIG focuses on delivering a great user experience for CentOS Linux users looking to build and maintain their own on-premise, public or hybrid clouds. All work on RDO and on the downstream release, Red Hat OpenStack Platform, is 100% open source, with all code changes going upstream first. PLEASE NOTE: At this time, RDO Ussuri provides packages for CentOS8 only. Please use the previous release, Train, for CentOS7 and python 2.7. *Interesting things in the Ussuri release include:* - Within the Ironic project, a bare metal service that is capable of managing and provisioning physical machines in a security-aware and fault-tolerant manner, UEFI and device selection is now available for Software RAID. - The Kolla project, the containerised deployment of OpenStack used to provide production-ready containers and deployment tools for operating OpenStack clouds, streamlined the configuration of external [Ceph]( https://ceph.io/) integration, making it easy to go from Ceph-Ansible-deployed Ceph cluster to enabling it in OpenStack. *Other improvements include:* - Support for IPv6 is available within the Kuryr project, the bridge between container framework networking models and OpenStack networking abstractions. - Other highlights of the broader upstream OpenStack project may be read via https://releases.openstack.org/ussuri/highlights.html. - A new Neutron driver networking-omnipath has been included in RDO distribution which enables the Omni-Path switching fabric in OpenStack cloud. - OVN Neutron driver has been merged in main neutron repositon from networking-ovn. *Contributors* During the Ussuri cycle, we saw the following new RDO contributors: - Amol Kahat - Artom Lifshitz - Bhagyashri Shewale - Brian Haley - Dan Pawlik - Dmitry Tantsur - Dougal Matthews - Eyal - Harald Jensås - Kevin Carter - Lance Albertson - Martin Schuppert - Mathieu Bultel - Matthias Runge - Miguel Garcia - Riccardo Pittau - Sagi Shnaidman - Sandeep Yadav - SurajP - Toure Dunnon Welcome to all of you and Thank You So Much for participating! But we wouldn’t want to overlook anyone. A super massive Thank You to all 54 contributors who participated in producing this release. This list includes commits to rdo-packages and rdo-infra repositories: - Adam Kimball - Alan Bishop - Alan Pevec - Alex Schultz - Alfredo Moralejo - Amol Kahat - Artom Lifshitz - Arx Cruz - Bhagyashri Shewale - Brian Haley - Cédric Jeanneret - Chandan Kumar - Dan Pawlik - David Moreau Simard - Dmitry Tantsur - Dougal Matthews - Emilien Macchi - Eric Harney - Eyal - Fabien Boucher - Gabriele Cerami - Gael Chamoulaud - Giulio Fidente - Harald Jensås - Jakub Libosvar - Javier Peña - Joel Capitao - Jon Schlueter - Kevin Carter - Lance Albertson - Lee Yarwood - Marc Dequènes (Duck) - Marios Andreou - Martin Mágr - Martin Schuppert - Mathieu Bultel - Matthias Runge - Miguel Garcia - Mike Turek - Nicolas Hicher - Rafael Folco - Riccardo Pittau - Ronelle Landy - Sagi Shnaidman - Sandeep Yadav - Soniya Vyas - Sorin Sbarnea - SurajP - Toure Dunnon - Tristan de Cacqueray - Victoria Martinez de la Cruz - Wes Hayutin - Yatin Karel - Zoltan Caplovic *The Next Release Cycle* At the end of one release, focus shifts immediately to the next, Victoria, which has an estimated GA the week of 12-16 October 2020. The full schedule is available at https://releases.openstack.org/victoria/schedule.html. Twice during each release cycle, RDO hosts official Test Days shortly after the first and third milestones; therefore, the upcoming test days are 25-26 June 2020 for Milestone One and 17-18 September 2020 for Milestone Three. *Get Started* There are three ways to get started with RDO. To spin up a proof of concept cloud, quickly, and on limited hardware, try an All-In-One Packstack installation. You can run RDO on a single node to get a feel for how it works. For a production deployment of RDO, use the TripleO Quickstart and you’ll be running a production cloud in short order. Finally, for those that don’t have any hardware or physical resources, there’s the OpenStack Global Passport Program. This is a collaborative effort between OpenStack public cloud providers to let you experience the freedom, performance and interoperability of open source infrastructure. You can quickly and easily gain access to OpenStack infrastructure via trial programs from participating OpenStack public cloud providers around the world. *Get Help* The RDO Project participates in a Q&A service at https://ask.openstack.org. We also have our users(a)lists.rdoproject.org for RDO-specific users and operrators. For more developer-oriented content we recommend joining the dev(a)lists.rdoproject.org mailing list. Remember to post a brief introduction about yourself and your RDO story. The mailing lists archives are all available athttps://mail.rdoproject.org. You can also find extensive documentation on RDOproject.org. The #rdo channel on Freenode IRC is also an excellent place to find and give help. We also welcome comments and requests on the CentOS devel mailing list and the CentOS and TripleO IRC channels (#centos, #centos-devel, and #tripleo on irc.freenode.net) however we have a more focused audience within the RDO venues. *Get Involved* To get involved in the OpenStack RPM packaging effort, check out the RDO contribute pages, peruse the CentOS Cloud SIG page, and inhale the RDO packaging documentation. Join us in #rdo and #tripleo on the Freenode IRC network and follow us on Twitter @RDOCommunity. You can also find us on Facebook and YouTube. Amy Marrich (spotz) https://www.rdoproject.org http://community.redhat.com

1 0

[tc] Monthly update (to become Weekly)
by Mohammed Naser 28 May '20

28 May '20

Hello everyone, Here’s an update of what’s happened in the OpenStack TC during the last month. Moving forward, I’ll be sending an update on a weekly basis. You can get more information by checking for changes in openstack/governance repository. # CHANGES PENDING - Rename ansible-role-lunasa-hsm deliverable: https://review.opendev.org/#/c/731313/ - Add whitebox-tempest-plugin under QA: https://review.opendev.org/#/c/714480/ - Select migrate-to-focal goal for Victoria cycle: https://review.opendev.org/#/c/731213/ - Clarify the support for linux distro: https://review.opendev.org/#/c/727238/ - Add QA branchless projects also in py3.5 support list: https://review.opendev.org/#/c/729325/ - Remove congress and tricircle project teams: https://review.opendev.org/#/c/728818/ - [draft] Add assert:supports-standalone: https://review.opendev.org/#/c/722399/ # PROJECT UPDATES - Adding Storlets in the list of keeping py2: https://review.opendev.org/#/c/720714/ - Transfer Policy team co-lead role: https://review.opendev.org/#/c/722101/ - Add keystoneauth to the python3.5 list: https://review.opendev.org/#/c/721093/ - Add note that OpenStackSDK kept 3.5 support: https://review.opendev.org/#/c/721083/ - Retire i18n-specs: https://review.opendev.org/#/c/721723/ - Migrate from mock to built in unittest.mock: https://review.opendev.org/#/c/722924/ - Migrate from olso.rootwrap to oslo.privsep: https://review.opendev.org/#/c/718177/ - Appoint Yasufumi Ogawa as Tacker PTL: https://review.opendev.org/#/c/719091/ # GOAL UPDATES - Infrastructure project team is now the TaCT SIG: https://review.opendev.org/#/c/721621/ - Add ansible role for managing Luna SA HSM: https://review.opendev.org/#/c/721348/ - Drop deprecated release-management flag for xstatic repos: https://review.opendev.org/#/c/721046/ # ABANDONED CHANGES - Remove CentOS 8 from tested runtimes for Ussuri: https://review.opendev.org/#/c/720005/ - Goals: add container-images: https://review.opendev.org/#/c/720107/ # GENERAL UPDATES - Add goal to migrate CI/CD jobs to Ubuntu Focal: https://review.opendev.org/#/c/728158/ - Fix hacking min version to 3.0.1: https://review.opendev.org/#/c/730161/ - Appoint Javier Peña as rpm-packaging PTL: https://review.opendev.org/#/c/728088/ - Add repository for oslo.metrics: https://review.opendev.org/#/c/725848/ - Require PTL signoff for project-update changes: https://review.opendev.org/#/c/727704/ - Allow for faster addition of projects: https://review.opendev.org/#/c/726932/ - Retire syntribos: https://review.opendev.org/#/c/726507/ - Loosen voting for community goal proposals: https://review.opendev.org/#/c/724142/ - Add TrilioVault Charms to OpenStack Charms: https://review.opendev.org/#/c/720533/ - Cleanup retired repositories: https://review.opendev.org/#/c/724334/ - Move i18n into a SIG: https://review.opendev.org/#/c/721605/ # OTHER - Cap jsonschema 3.2.0 as the minimal version: https://review.opendev.org/#/c/730948/ - Fix bullet list formatting for drop-py2 goal: https://review.opendev.org/#/c/729314/ Thanks and sorry for the delay in getting those out. -- Mohammed Naser VEXXHOST, Inc.

1 0

Re: Uniting TC and UC
by Mohamed Elsakhawy 28 May '20

28 May '20

Hi All, As you may know already, there has been an ongoing discussion to merge UC and TC under a single body. Three options were presented, along with their impact on the bylaws. http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012806… We had several discussions in the UC on the three options as well as the UC items that need to be well-represented under the common committee, and here’s what we propose for the merger: 1- There’s consensus on utilizing option 1, thus requiring no bylaws change and merging AUC and ATC : 1- No bylaws change As bylaws changes take a lot of time and energy, the simplest approach would be to merge the TC and UC without changing the bylaws at all. The single body (called TC) would incorporate the AUC criteria by adding all AUC members as extra-ATC. It would tackle all aspects of our community. To respect the letter of the bylaws, the TC would formally designate 5 of its members to be the 'UC' and those would select a 'UC chair'. But all tasks would be handled together. 2- Two main core UC responsibilities need to continue to be represented under TC - Representing the user community to the broader community (Board of directors, TC...) - Working with user groups worldwide to keep the community vibrant and informed. 3- The current active workgroups under UC’s governance will be moved to be under TC’s governance. 4- AUC and ATC to be merged into a single list, potentially called AC (Active Contributor) 5- We hope to have the merger finalized before the upcoming UC elections in September 2020. In addition to discussions over the mailing list, we also have the opportunity of "face-to-face" discussions at the upcoming PTG. Thanks Mohamed --melsakhawy

8 11

[blazar][ptg] IRC meetings cancelled due to PTG
by Pierre Riteau 28 May '20

28 May '20

Hello, The Blazar community will meet several times through the PTG event next week. Let's cancel the IRC meetings originally scheduled on June 2 and June 4. Talk to you soon, Pierre Riteau (priteau)

1 0

[glance] "true is not of type boolean" when creating protected image
by Bernd Bausch 28 May '20

28 May '20

This problem occurs on a stable Ussuri Devstack. I issue this command to create a protected image: $ openstack image create myimage2 --file ~/myvm1.qcow2 --disk-format qcow2 --protected and get this error message back: BadRequestException: 400: Client Error for url: http://192.168.1.200/image/v2/images, 400 Bad Request: On instance['protected']:: 'type': 'boolean'}: {'description': 'If true, image will not be deletable.',: 'True': Provided object does not match schema 'image': 'True' is not of type 'boolean': Failed validating 'type' in schema['properties']['protected']: It seems that image creation fails because 'True' is not of type 'boolean' Am I looking at a bug or am I doing something wrong? I do have a great workaround: First, create the image without the protected flag. Then: $ openstack image set --protected myimage2 This works.

2 1

[all] [kolla] Kolla Builder - next generation
by Radosław Piliszek 28 May '20

28 May '20

Hello fellow OpenStackers and Kollars (or Koalas) in particular, today is the day when I finally sit down to write up my thoughts on Kolla, and I mean *Kolla*, the container image building project for OpenStack and friends, nothing more (nor less). *** Some background on Kolla to get everyone on the same page (or close enough): Kolla builds images for production use. Kolla is upstream for TripleO containers and Kolla-Ansible deployment. These are container images, think OCI and Docker in particular since Kolla actually relies on Dockerfile format to specify build recipes and Docker runs building (TripleO runs buildah on the same recipes). Kolla supports three distributions as bases: CentOS (TripleO does override this for RHEL as well), Debian and Ubuntu. In the interim periods Kolla supports two distribution releases to ease/smooth the transition process for operators (like currently CentOS 7 and 8 in Train, while Ussuri is 8 only). What is more, each distro has two flavours (or 'types' as they are called for now): binary and source. This 'type' applies only to OpenStack software. Binary means that Kolla uses downstream packages (rpm/deb) while source means to use pip and install from official tarballs (or repos if it is master) and PyPI for deps, utilising venv to keep it separate from distro stuff. Finally, there is particular target architecture: x86_64, aarch64 and ppc64le. All of above affect the support matrix which is based on 3 or 4 dimensions (distro, flavour, arch and sometimes distro version). [1] Kolla offers a high level of customisability via various overrides levels. See docs for details [2] Kolla engine offers hierarchical approach to image building, under the assumption that more than one image is often deployed on the same machine so layer sharing is beneficial. Kolla helps collect sources for OpenStack projects to build desired versions of them. All recipes are templated using Jinja2 syntax. Images contain both run-time and, mostly in the case of 'source' flavour, build-time tools and libraries. *** That's it for the background. :-) So where is the problem you might ask? Oh, there are plenty. The general is that Kolla has lots of logic in templates. Thankfully, Kolla has macros for most stuff but still Jinja2 limitations make it hard to document exceptions (no inline comments in arrays anyone?). We lose visibility into real dependency graphs and may be easily reinstalling same stuff, any optimisations are limited and would require parsing of both Jinja2 and Dockerfile syntax. In general the current approach is ugly and becomes unwieldy (e.g. getting warnings about empty continuation lines). There is layering hell: dependency on long &&ed commands which are templated out to avoid useless layers. Support matrix is great for an overview. There is a hidden layer to it though, different combinations may support different features. This is not documented so far and not so easy to follow from sources. This stems from the fact that different extra components have different availability in distros, but this is not easily apparent from sources. Also, there is no way to turn feature on/off. You might do an override, but then again, which to keep, which not to? Which is which? Oh! Finally, the images tend to be heavy due to inclusion of build-time deps. *** That's it for issues (hopefully!) My idea is to reuse Kolla engine where it shines: sources collection, system of plugins, hierarchical building; but replace the part that smells - Jinja2 templating. Giving up on Jinja2 might encompass giving up on Dockerfile syntax, but that is optional and depends on what makes it more amenable to avoid further pitfalls. With giving up on Jinja2, the idea is to generate building recipes fully programmatically from Python. It would be possible to introduce "Features" - sets of packages to install based on the (distro, arch) tuple. This would result in more flexibility - turning them on/off (some could be optional, some not). There could be more than one optimization strategy regarding when packages get installed: you want only standalone blah-blah? Then Kolla won't be installing XYZ and ABC just because ugma-ugma and tickle-tickle require them and you "could save some space" (TM). In the same vein, features could declare which components are build-time and which are run-time and this would make it straightforward to separate the sides. The above effort could well be coordinated with different projects to reuse bindep contents. So far Kolla does not use bindep because it often installs too much and not enough at the same time. Do note it would still be bindep-less for external services. There would still need to exist a general mechanism for providing custom command executions required by some images. For contributors and cores this new approach would bring more sanity as to the scope of proposed changes. Also, it would be possible to get quick insight into feature support and autogenerate docs for that as well. Similarly, current concept of unbuildable images would no longer be required because unbuildability would be dictated by lack of support for a required feature. *** Looking forward to your opinions/thoughts. *** [1] https://docs.openstack.org/kolla/train/support_matrix.html [2] https://docs.openstack.org/kolla/train/admin/image-building.html -yoctozepto

5 9

Re:[Cyborg]Edge sync up at the PTG
by yumeng bao 28 May '20

28 May '20

Hi Ildikó, Thanks for the post! Cyborg team would be glad to join ! I have added this edge group meeting session to our PTG schedule : https://etherpad.opendev.org/p/cyborg-victoria-goals Please help to add links for the discussion if there is any. Regards， Yumeng

2 2

[kolla] Virtual PTG
by Mark Goddard 28 May '20

28 May '20

Hi, Just a reminder that it's the virtual PTG next week. We have an Etherpad [1] which has lots of information, and remember to register (free) [2] if you haven't already. Kendall sent some useful information [3] recently also. If you plan to attend, please add your name to the Etherpad so we know who to expect for each session (although you are welcome to turn up if you have not). The Etherpad is currently quite light on proposed discussion topics. Please do spend some time to consider what we should be using this time to discuss. It doesn't have to be a shiny new feature, it could be a long standing bug that we should agree on how to address, or a discussion on how to improve our processes. If we are left with time to spare however, I think it will be well spent on some reflection, maintenance, and planning. Cheers, Mark [1] https://etherpad.opendev.org/p/kolla-victoria-ptg [2] https://virtualptgjune2020.eventbrite.com/ [3] http://lists.openstack.org/pipermail/openstack-discuss/2020-May/015054.html

1 0

[sdk][osc][cli][ptg][project_cleanup] PTG Week planning
by Artem Goncharov 28 May '20

28 May '20

Hi everyone interested :) The PTG planning for the OpenStackSDK and the CLI is there: https://etherpad.opendev.org/p/SDK-VictoriaPTG-Planning <https://etherpad.opendev.org/p/SDK-VictoriaPTG-Planning> Please enter yourself there if interested and add topics you want to discuss. We have currently 2 slots: 01 June: 15:00 - 17:00 UTC Juno 03 June: 15:00 - 17:00 UTC Bexar And we plan to be using meetpad (fingers crossed). Interesting topics: - June 01 15:00-16:00 project cleanup - long standing topic across the projects - June 01 16:00-17:00 openstackclient-first - a one time failed community goal, and now maybe multi-release goal for joining all individual service clients into OSC to give users seamless UX Hear from you soon, Artem

2 1

[glance][ptg] Victoria Virtual PTG updates
by Abhishek Kekane 27 May '20

27 May '20

Hello All, Greetings!!! First virtual PTG is around the corner and if you haven't already registered, please do so as soon as possible [1]. I have created a Virtual PTG planning etherpad [2] and also added day wise topics along with timings we are going to discuss. Kindly let me know if you have any concerns with allotted time slots. As a reminder, these are the time slots for our discussion. Monday 01 June 2020 1400 UTC to 1700 UTC Folsom Tuesday 02 June 2020 2100 UTC to 00 UTC Austin Wednesday 03 June 2020 2100 UTC to 00 UTC Austin Thursday 04 June 2020 2100 UTC to 00 UTC Folsom Friday 05 June 2020 1400 UTC to 1700 UTC Folsom We will be using meetpad [3] for our discussion, kindly try to use it once before the actual discussion. I will publish the meeting URL before the PTG and which will be the same throughout the PTG. [1] https://virtualptgjune2020.eventbrite.com/ [2] https://etherpad.opendev.org/p/Glance-Victoria-PTG-planning [3] https://meetpad.opendev.org Thank you, Abhishek

1 0