May 2019 - openstack-discuss - lists.openstack.org

[nova] Spec review sprint Tuesday June 04
by Eric Fried 04 Jun '19

04 Jun '19

Hi all. We would like to do a nova-specs review push next Tuesday, June 4th. If you own one or more specs, please try to polish them and address any outstanding downvotes before Tuesday; and on Tuesday, please try to be available in #openstack-nova (or paying close attention to gerrit) to discuss them if needed. If you are a nova reviewer, contributor, or stakeholder, please try to spend a good chunk of your upstream time on Tuesday reviewing open Train specs [1]. Thanks, efried [1] Approximately: https://review.opendev.org/#/q/project:openstack/nova-specs+status:open+pat…

1 2

[infra] Elections for Airship
by MCEUEN, MATT 04 Jun '19

04 Jun '19

OpenStack Infra team, As the Airship project works to finalize our governance and elected positions [1], we need to be ready to hold our first elections. I wanted to reach out and ask for any experience, guidance, materials, or tooling you can share that would help this run correctly and smoothly? This is an area where the Airship team doesn't have much experience so we may not know the right questions to ask. Aside from a member of the Airship community creating a poll in CIVS [2], is there anything else you would recommend? Is there any additional tooling in place in the OpenStack world? Any potential pitfalls, or other hard-won advice for us? [1] https://review.opendev.org/#/c/653865/ [2] https://civs.cs.cornell.edu/ Thank you for your help! Matt

4 4

RE: [tc][all] Github mirroring (or lack thereof) for unofficial projects
by Roman Gorshunov 04 Jun '19

04 Jun '19

Hello Jim, team, I'm from Airship project. I agree with archival of Github mirrors of repositories. One small suggestion: could we have project descriptions adjusted to point to the new location of the source code repository, please? E.g. "The repo now lives at opendev.org/x/y". Thanks to AJaeger & clarkb. Thank you. Best regards, -- Roman Gorshunov

7 17

[openstack-ansible] Installing Third-Party drivers into the Cinder-Volume container during playbook execution
by Henry Bonath 04 Jun '19

04 Jun '19

Hello, I asked this into IRC but I thought this might be a more appropriate place to ask considering the IRC channel usage over the weekend. If I wanted to deploy a third party driver along with my Cinder-Volume container, is there a built-in mechanism for doing so? (I am specifically wanting to use: https://github.com/iXsystems/cinder) I am able to configure a cinder-backend in the "openstack_user_config.yml" file which works perfectly if I let it fail during the first run, then copy the driver into the containers and run "os-cinder-install.yml" a second time. I've found that you guys have built similar stuff into the system (e.g. Horizon custom Theme installation via .tgz) and was curious if there is a similar mechanism for Cinder Drivers that may be undocumented. http://paste.openstack.org/show/752132/ This is an example of my working config, which relies on the driver being copied into the /openstack/venvs/cinder-19.x.x.x/lib/python2.7/site-packages/cinder/volume/drivers/ixsystems/ folder. Thanks in advance!

3 5

[placement] Office Hours
by Ed Leafe 03 Jun '19

03 Jun '19

A recent poll of our members resulted in the decision to no longer hold our regular weekly meetings, but to instead switch to an Office Hour format. Now the question is when to hold them, and how often. A time between 1400—2200 UTC would work well for US-based people, while times between 0900—1700 UTC would be best for Europe people, and 0100—0900 UTC for Asia-Pacific. It would seem that holding it at 1600 UTC would be a good compromise for both US and Europe, but that leaves out the other half of the world. So perhaps our members in that side of the globe might be interested in holding their own Office Hour? So I'd like your input. Respond with your preference, and after a week if there is an overwhelming favorite, we'll go with that. If there is a range of preferences, we can hold another poll to settle on one. I'll start: my preference would be to hold weekly office hours every Wednesday at 1600 UTC. -- Ed Leafe

4 4

[neutron][networking-ovn] Core team updates
by Lucas Alvares Gomes 02 Jun '19

02 Jun '19

Hi all, I'd like to welcome Jakub Libosvar to the networking-ovn core team. The team was in need for more reviewers with +2/+A power and Jakub's reviews have been super high quality [0][1]. He's also helping the project out in many other different efforts such as bringing in the full stack test suit and bug fixes. Also, Miguel Ajo has changed focus from OVN/networking-ovn and is been dropped from the core team. Of course, we will welcome him back when his activity picks back up again. Thank you Jakub and Miguel! [0] https://www.stackalytics.com/report/contribution/networking-ovn/30 [1] https://www.stackalytics.com/report/contribution/networking-ovn/90 Cheers, Lucas

4 3

[neutron] [OVN] ML2+OVS+DVR convergence with OVN spec
by Ryan Tidwell 01 Jun '19

01 Jun '19

Hello neutrinos, As discussed recently at the Denver PTG [1] and in the neutron drivers meeting last Friday May 24th [2], I have started on a spec for ML2+OVS and OVN convergence [3]. It is in very rough shape at the moment, but I have pushed a rough outline so this can be developed as collaboratively as possible starting now. I personally don't have all the information to fill out the spec right at the moment but I'm sure it can be found across the community of folks working on neutron and OVN, so please feel free to comment and add relevant information to the spec. -Ryan Tidwell [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006408.html [2] http://eavesdrop.openstack.org/meetings/neutron_drivers/2019/neutron_driver… [3] https://review.opendev.org/#/c/658414

2 2

[docs][kolla] Project deploy guide
by Mark Goddard 01 Jun '19

01 Jun '19

Hi, It was recently noticed that the kolla project deploy guide [1] was out of sync with the kolla-ansible docs [2]. This turned out to be because we broke the deploy-guide build. We're working on fixing this. This made me question why we have a separate deploy guide, which duplicates some but not all of the kolla-ansible docs. Tripleo links to their own install guide. Is there any reason why we (kolla) should not do the same? Honestly, I was not even aware of the deploy guide before this episode, perhaps I have missed the history behind it. Cheers, Mark [1] https://docs.openstack.org/project-deploy-guide/kolla-ansible/stein/ [2] https://docs.openstack.org/kolla-ansible/stein/user/quickstart.html

1 0

[kolla] Virtual PTG summary
by Mark Goddard 01 Jun '19

01 Jun '19

Hi, This week we held a virtual PTG. The etherpad [1] includes the agenda and notes. Here is my summary of what was discussed, decisions and actions. # Cross-project We started the sessions with a visitor from Tripleo - Tengu - who is working on validations [2]. Validations are a way of checking a control plane at various points in its life cycle, usually to check that some operation was completed successfully. Tengu described the project and explained how there was interest in making it a more generic framework that could be used by kolla ansible and other deployment projects. On our side there was no objection but it would require an owner. I offered to help Tengu with a PoC to see how it would work. # General Next we moved onto general project matters. ## Sustainability We've seen a slow decline in contribution over the past few cycles, as have many other projects. Part of this is natural for a more mature project that now mostly does what is required of it. Still, its good to reflect on sustainability, and plan ahead for leaner times. As a project we have a huge support matrix, with hundreds of container images, multiple OS distributions, different CPU architectures and a plethora of configuration options. We decided that a good starting point would be to define some categories of support: * images we maintain * images we more or less care about * the rest (once broken we may or may not work on fixing) The wording may need some work :) We can extend this also to OS distros, CPU arches, service deployment, and features. A key factor here will be the level of test coverage. We would document this on the wiki or docs.o.o. Ultimately this is all best effort, given that we're an open source project with a community of volunteers. A way to improve sustainability we discussed is through trimming the feature matrix. * OracleLinux - this is small but non-zero maintenance overhead. It's a candidate because we don't see people using it and Oracle maintainers left the project. * Debian binary images - not seeing many users of these. * Ceph - this is well used but does require maintenance. We support integration with external ceph clusters, and have discussed switching to recommending ceph-ansible, with a documented, automated and tested migration path. * kolla-cli - this project was added a few cycles ago, then the maintainers left the community. We haven't released it, CI is broken and have heard no complaints. For features which do not require much code we could disable testing, and move them to an explicit 'unmaintained' status. Alternatively, we could deprecate then remove them. I will follow up with emails asking for community feedback on the impact of removal. ## Core team We're looking out for potential core reviewers. If you'd like to join the team, speak to one of us and we can help you on the path. The main factor here is quality, thoughtful reviews. ## Meetings Recently attendance at IRC meetings has been low. We decided to move the meetings to #openstack-kolla to try to get more people involved. ## Kayobe Kayobe seeks to become an official project. This could be under kolla project governance, or as a separate project - the main deciding factor will be the kolla team. I will send an email about this separately. ## Priorities I would like us to agree as a team on some priorities for the Train cycle. I will send out a separate mail about this. # Kolla (images) ## Python 3 images In the Train cycle all projects should be moving to support python 3 only. We therefore need to build images based on python 3. hrw has been working on this [3] for Ubuntu and Debian source images. We will also need to switch to python 3 for CentOS/RHEL source images. This work needs an owner. A related issue is that of CentOS 8, which will support only python 3. I will follow up with a mail about this. Binary images (RPM/deb) depend on the distros and their plans for python 3. There is some python 3 work in kolla-ansible, to ensure we can execute ansible via python both locally and on remote hosts. ## Health checks Tripleo builds some healthchecks [4] into their docker images. This allows Docker to restart a service if it is deemed to be unhealthy. We agreed it would be nice to see support for this in kolla but did not discuss in depth. ## Ansible version upgrade Ansible moves on, and so must we. The version of ansible in kolla_toolbox is now rather old (2.2), and our minimum ansible version for kolla-ansible (2.5) is also getting old. It is likely we will need to update some of the custom ansible modules in order to do this. We may be able to replace others with modules from Ansible (e.g. kolla_keystone_user, kolla_keystone_service). mnasiadka offered to pick this up after the Ceph Nautilus upgrade. ## Fluentd upgrade The fluentd service needs an update - we are using 0.12.something. Needs an owner. ## Machine readable image config The issues this would solve have now mostly been fixed in tools/version-check.py, so we'll probably leave it. ## Buildah support At the Denver summit there was some interest in support for buildah as an alternative to docker for building images. I am led to believe tripleo already does this, so will ask how they do it. # Kolla Ansible ## Test coverage We made some good progress on improving CI test coverage during the Stein cycle, adding these jobs: * Cinder LVM * Scenario NFV * Major version upgrades * Zun During the Train cycle we aim to add these: * MariaDB: https://review.opendev.org/655663 * Monasca: https://review.opendev.org/649893 (WIP) * Ironic: https://review.opendev.org/568829 * Ceph upgrade: https://review.opendev.org/658132 * Tempest: https://review.opendev.org/402122 (WIP) Other candidates include magnum, octavia and prometheus. ## Nova cells v2 We had a long discussion about nova cells v2 [5]. Thanks to jroll and johnthetubaguy for getting involved. We generally agreed that this should be part of a wider assessment of scalability in kolla-ansible, although I was keen to treat different aspects of this separately during development. There are a number of ways to approach a multi-cell deployment, particularly in relation to how the per-cell infrastructure (DB, MQ, nova-conductor) are deployed. We discussed building a flexible mechanism for stamping out this infrastructure to arbitrary locations, then being able to point services in each cell at a given infrastructure location. In an effort to make this as simple to use for deployers as possible, we discussed defining a reference large scale cloud architecture. Our first pass at this is as follows: * API controllers x3+: APIs, super conductors, Galera, RabbitMQ, Keystone, etc * Cell controller clusters x3+: cell conductors, Galera, RabbitMQ, Glance, maybe neutron? (or one per "failure domain / AZ") * Cell computes: nova compute, neutron agents We would aim to add a CI job based on a two cell cloud using this architecture. We moved on to operations in a multi-cell world. It should be easy to add API controllers, cell controllers and compute nodes. We would want the ability to operate on the cloud as a whole, or individual cells using --limit. Upgrades seem likely to introduce challenges, particularly if we want to upgrade cells individually. It's likely CERN and others have some good experience we could benefit from here. The spec [6] needs an update based on this discussion, but comments there are welcome. ## Others We ran out of time before discussing the other kolla-ansible issues. Please update the etherpad [1] if you have thoughts on any of these. # Thanks Thanks to everyone who attended the kolla PTG. A conference call is certainly more challenging than a face to face dIscussion, but it was also nice to not have to fly people around the world for a few design discussions. I feel we did make progress on a number of important issues. If anyone has feedback on how we could improve next time, please get in touch. Cheers, Mark [1] https://etherpad.openstack.org/p/kolla-train-ptg [2] https://docs.openstack.org/tripleo-validations/latest/readme.html [3] https://review.opendev.org/642375 [4] https://github.com/openstack/tripleo-common/tree/master/healthcheck [5] https://blueprints.launchpad.net/kolla-ansible/+spec/support-nova-cells [6] https://review.openstack.org/616645

1 0

[cyborg][nova][sdk]Cyborgclient integration
by Ikuo Otani 01 Jun '19

01 Jun '19

Hi, I am a Cyborg member and take the role of integrating openstacksdk and replacing use of python-*client. Related bluespec: https://blueprints.launchpad.net/nova/+spec/openstacksdk-in-nova My question is: When the first code should be uploaded to gerrit? >From my understanding, we should update cyborg client library referring to openstacksdk rule, and make it reviewed in gerrit by Eric Fried. I'm sorry if I misunderstand. Thanks in advance, Ikuo NTT Network Service Systems Laboratories Server Network Innovation Project Ikuo Otani TEL: +81-422-59-4140 Email: ikuo.otani.rw(a)hco.ntt.co.jp

5 12