June 2020 - openstack-discuss - lists.openstack.org

[all][tc][stable][qa] Grenade testing for Extended Maintenance stable
by Ghanshyam Mann 25 Jun '20

25 Jun '20

Hello Everyone, As you know devstack (so does grenade) got broken due to uwsgi new release, the master branch is fixed and stable branches are in progress[1]. But It is hard to maintain or fix the EM stable for those issues. Especially the greande job which depends on the source branch (previous branch of one where the job is running). For example, for stein grenade job, we need to keep rocky branch working and fix if failure. Till now, we have not removed the grenade testing from any of the EM stable branches because they were running fine till now but with uwsgi issues, those are failing and need more work to fix. This triggers the discussion of grenade testing on EM stable branches. Usual policy for grenade testing is to keep the job running from the 'oldest supported stable +1' branch. For example, if stein is the oldest supported stable (in the old stable definition) then run grenade from train onwards. But with the Extended Maintainance model, defining 'oldest supported stable' is not clear whether it is the oldest non-EM(stein) or oldest EM stable(ocata). To make it clear, we discussed this in the QA channel and come up with the below proposal. * 'oldest' is the oldest non-EM. In current time, it is stein. * With the above 'oldest' definition, we will: ** Make grenade jobs as n-v on all EM stable branches (which is till stable/rocky as of today) + on stable/stein also because that is 'oldest' as of today. ** Keep supporting and running grenade job on 'oldest+1' which is stable/train onwards as of today. NOTE: we will make n-v when they start failing and anyone can volunteer to fix them and change back to voting. elod expressed interest to work on current failure. If no objection to the above proposal, I will document it on the grenade documents to follow it whenever we see EM failing and need more work. In Tempest, we already have the EM stable testing policy documented which is to support those till they run fine[2]. [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015496.html [2] https://docs.openstack.org/tempest/latest/stable_branch_support_policy.html [3] http://eavesdrop.openstack.org/irclogs/%23openstack-qa/%23openstack-qa.2020… -gmann

5 5

[tripleo] Proposing Francesco Pantano as core on TripleO/Ceph
by Giulio Fidente 25 Jun '20

25 Jun '20

Hi all, Francesco (fmount on freenode) started working on the Ceph integration bits in TripleO more than a year ago now [1], contributing over time to all components, heat templates, validations, puppet and ansible repos. He understood the tight relationship in between TripleO and ceph-ansible and contributed directly to ceph-ansible as well, when necessary [2]. I think he'd be a great addition to the TripleO cores group and I hope for him to work more in the future even outside the Ceph integration efforts. I would like to propose Francesco core for the TripleO group on the Ceph bits. Please vote here or leave any feedback for him. Thanks, Giulio 1. https://review.opendev.org/#/q/owner:fpantano%2540redhat.com+status:merged 2. https://github.com/ceph/ceph-ansible/commits?author=fmount -- Giulio Fidente GPG KEY: 08D733BA

9 8

[neutron][tc][solum] Properly retire networking-onos, solum-infra-guestagent, openstack-ux
by Andreas Jaeger 25 Jun '20

25 Jun '20

These three repositories have been retired by their projects some time ago [1]: - openstack-ux: 2017-02-24 - networking-onos: 2016-11-01 - solum-infra-guestagent: 2016-11-24 They have no contribution and are still setup in Zuul, I'll retire them now following our retirement process [2] and thus remove them from Zuul. See [3] for changes, Andreas Links: [1] https://opendev.org/openstack/governance/src/branch/master/reference/legacy… [2] https://docs.openstack.org/project-team-guide/repository.html#retiring-a-re… [3] https://review.opendev.org/#/q/topic:finish-retire -- Andreas Jaeger aj(a)suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg (HRB 36809, AG Nürnberg) GF: Felix Imendörffer GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB

1 0

[neutron][dynamic-routing] Adding Jens Harbott and Tobias Urdin to neutron-dynamic-routing core team
by Slawek Kaplonski 25 Jun '20

25 Jun '20

Hi, Recently I asked for new maintainers for the neutron-dynamic-routing project. Tobias Urdin and Jens Harbott stepped in for that. So now I added them both to be core reviewers in the neutron-dynamic-routing project also. -- Slawek Kaplonski Senior software engineer Red Hat

1 0

[cinder] volume list query ("managing" statuses) spec
by Brian Rosmaita 25 Jun '20

25 Jun '20

The spec is https://review.opendev.org/#/c/726070/ I took the action item at today's virtual mid-cycle meeting to summarize the discussion on the review so that the spec can be revised. While doing that, I looked through the code carefully, and I think that the spec is actually on the right track, though there seem to be several bugs associated with this issue. In any case, I just left an enormous comment on the review. I need other reviewers to read through and comment/respond so that haixin and zhangbailin can get some consensus on how to revise the spec. thanks, brian

1 0

[cyborg] Cyborg IRC meeting cancelled this week
by yumeng bao 24 Jun '20

24 Jun '20

Hi all, Cyborg weekly meeting will be cancelled this week since most of the team members will be having the Dragon Boat Festival on Thursday. We will see you next week! Regards， Yumeng

1 0

[kolla] Victoria priorities
by Mark Goddard 24 Jun '20

24 Jun '20

Hi, Hot on the heels of the Ussuri release, we have the results of the votes for Victoria priorities. We voted in etherpad [1], and the results have been added to the whiteboard (L181). Feel free to add your name as an owner on the whiteboard if you would like to be involved. [1] https://etherpad.opendev.org/p/kolla-victoria-priorities Thanks, Mark = Kolla = Infra images (8 votes) https://blueprints.launchpad.net/kolla/+spec/infra-images Owners: Image tiering (6 votes) Avoid breakage of non-core images blocking publishing of all others Owners: Ubuntu focal 20.04 (6 votes) (likely must-have anyway unless we are dropping ubuntu) Owners: Stable branch life-cycle (6 votes) Use stable/<release> rather than versions Owners: Integrate support for pull-retag-push (4 votes) https://storyboard.openstack.org/#!/story/2007731 (original kayobe story) Owners: Kolla depends-on upstream projects to behave as it should (2 votes) Owners: Build, test, promote CI pipeline (2 votes) Build images, test them, promote for general availability Owners: = Kolla Ansible = Let's Encrypt integration - container running certbot, triggers certificate distribution (10 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/letsencrypt-https this would be useful to have for tls everywhere deployment too. Owners: headphoneJames Document, automate and test Octavia resource registration (10 votes) Owners: Document, automate and test Designate resource registration (8 votes) Also designate sink set up for instance dns Owners: yoctozepto Documentation review & refresh (8 votes) Owners: everyone Federated keystone (7 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/add-openid-support Owners: Container health checks (7 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/container-health-check mix with sanity checks? https://blueprints.launchpad.net/kolla-ansible/+spec/sanity-check-container Owners: mnasiadka Fix the "Ansible may run more handlers than originally planned" with all the extras around config (6 votes) https://bugs.launchpad.net/kolla-ansible/+bug/1863510 Owners: Improve test coverage (the never-ending story) (6 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/kolla-deployment-scena… Multiple regions Owners: Performance & scalability improvements (5 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/performance-improvemen… Owners: mgoddard Implement TLS Backend for all core services with externally exposed API (nova for example) (4 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/add-ssl-internal-netwo… Owners: headphoneJames TLS in other services: (4 votes) MariaDB https://blueprints.launchpad.net/kolla-ansible/+spec/mariadb-ssl-support RabbitMQ https://blueprints.launchpad.net/kolla-ansible/+spec/message-queue-ssl-supp… Memcached https://blueprints.launchpad.net/kolla-ansible/+spec/memcached-ssl-support Owners: Upgrade checkers (4 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/upgrade-checkers Owners: Node removal (decommission) (4 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/remove-node Mark has already done related work for CentOS 8 migration do more than destroy - clean them up! from databases etc. aligns with day-2 ops Owners: Support for reload (e.g. for TLS), also graceful shutdown (4 votes) Owners: Mechanism for distributing certificates to services after deployment (2 votes) Owners: Day 2 ops tools (restart containers, upgrade Docker, prune DBs…) (2 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/docker-upgrade-reconfi… Owners: Capture docker logs (2 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/capture-docker-logs Owners: Nova cells v2 - shared cell controllers, multiple DBs and MQs (0 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/nova-cells-shared-cont… https://blueprints.launchpad.net/kolla-ansible/+spec/cellsv2-rabbitmq-suppo… Owners: = Kayobe = Document configuration walk through (7 votes) https://storyboard.openstack.org/#!/story/2004360 Owners: Support multiple environments from a single kayobe configuration (3 votes) https://storyboard.openstack.org/#!/story/2002009 Owners: priteau Support for multiple deploy image types on overcloud nodes (2 votes) https://storyboard.openstack.org/#!/story/2002098 Owners: Next generation discovery & network configuration (2 votes) https://storyboard.openstack.org/#!/story/2004295 https://github.com/markgoddard/kayobe-switch-config-poc Owners: Replace bifrost with kolla-ansible for seed services (2 votes) https://storyboard.openstack.org/#!/story/2004293 Owners: Easier customization of Kayobe commands (0 votes) https://storyboard.openstack.org/#!/story/2001663 Owners: jovial Command plan that tells you which playbooks will run / Fix dry run (0 votes) Pierre pointed out that -lt provides similar functionality, e.g kayobe overcloud host configure -lt Owners: Inventory exporter (0 votes) Owners:

1 0

[kolla] Ussuri releases available
by Mark Goddard 24 Jun '20

24 Jun '20

Hi, I'm pleased to announce the availability of the first Ussuri releases for all Kolla deliverables: * kolla 10.0.0 (https://docs.openstack.org/releasenotes/kolla/ussuri.html#relnotes-10-0-0-s…) * kolla-ansible 10.0.0 (https://docs.openstack.org/releasenotes/kolla-ansible/ussuri.html#relnotes-…) * kolla-cli 10.0.0 * kayobe 8.0.0 (https://docs.openstack.org/releasenotes/kayobe/ussuri.html#relnotes-8-0-0-s…) Thanks to everyone who contributed to these releases. Some things to note: * Support for CentOS 7 has been dropped. Train provides a migration path from CentOS 7 to 8 * Ceph deployment support and images have been dropped. External Ceph cluster integration should be used instead. * Support for Python 2 has been dropped. * This is the last planned release of kolla-cli. As usual with deprecations, please get in touch if you are able to help support this project. And now onto Victoria! Thanks, Mark

1 0

[largescale-sig] Next meeting: June 24, 8utc
by Thierry Carrez 24 Jun '20

24 Jun '20

Hi everyone, The Large Scale SIG will have a meeting this week on Wednesday, June 24 at 8 UTC[1] in the #openstack-meeting-3 channel on IRC: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200624T08 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: - all to describe briefly how you solved metrics/billing in your deployment on https://etherpad.opendev.org/p/large-scale-sig-documentation - amorin to add some meat to the wiki page before we push the Nova doc patch further - ttx to solve merge conflict and push initial oslo.metrics code in from https://review.opendev.org/#/c/730753/ Talk to you all on Wednesday, -- Thierry Carrez

1 1

[Octavia] multi-arch Amphora
by Tony Breeds 24 Jun '20

24 Jun '20

Hello Octavia team! I have a somewhat obscure question for y'all about the "best way" to run an Amphora in an multi-arch OpenStack. I'm going to start with some level-setting assumptions, the describe my understanding so that if I'm wrong we can correct that before we get to the crux of my question(s) Assumptions ----------- - The build of all objects, amphora guest images etc etc is fine - The deployment of OpenStack is reasonably simple and defined. - An OpenStack that runs entirely on on CPU Architecture (aarch64, ppc64le, x86_64, etc) "works" Bottom line we don't need to care about how the 'bits' are built or installed just that they are :) My Understanding ---------------- When asked to create a loadbalancer. Octavia will spawn an instance (via Nova) running the image tagged in glance with $amp_image_tag[1,2]. This instances shoudl be scheduled closer to the ingress/egress of the network then the workload it's balancing. All communication between the Amphora and Octavia API is via REST (as opposed to RPC) and therefore we won't have any 'endianness/binary bugs' [3] The question(s) --------------- We have an OpenStack that has compute nodes running mixed architectures (aarch64, ppc64le, x86_64, etc) we can ensure that images run on the correct system (either with hw_architecture or aggregates). To make that work today we load an appropriately tagged image into glance and then the amphora just runs on type of system and it's all pretty easy. Can, should, we do better? - Does OVN/DVR alter the perfomance such that there *is* merit in scheduling the amphora closer to the workloads - Should we support multiple Amphora (one per architecture)? - If so should this be exposed to the user? openstack loadbalancer create \ --name lb1 --vip-subnet-id public-subnet \ --run-on aarch64 Yours Tony. [1] https://docs.openstack.org/octavia/latest/configuration/configref.html#cont… [2] There should be only one image tagged as such: https://opendev.org/openstack/octavia/src/branch/master/octavia/compute/dri… [3] https://www.youtube.com/watch?v=oBSuXP-1Tc0

2 1