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 24 Jun '20

24 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 23 Jun '20

23 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

[tc][uc] Status update: Uniting TC and UC
by Thierry Carrez 23 Jun '20

23 Jun '20

Hi everyone, A quick status update on that effort. The TC just merged a change[1] that will result in the TC and UC acting as a single body, starting on August 1st, 2020. The date was chosen so that the remaining UC members (Mohamed Elsakhawy and Jaesuk Anh) can finish their term. After that date, the UC mission will be taken over by the elected TC members, and from there on we'll have a single elected body, including developers, operators and end users of the OpenStack software, and inclusive of all types of contributions to the project. In August I'll work to merge the content on the UC governance site and the TC governance site. This will include adding a new file on openstack/governance to add and track voters corresponding to the AUC criteria. Those will be added to the electorate in time for the next round of elections in September. This simplification will make the OpenStack community more easily navigable, and further remove barriers between contributors with an operations background and contributors with a development background. For more information on the motivations behind that change, please read the original thread[2] proposing it. I'd like to personally thank the User Committee members for their support in that transition, and for all the work they accomplished for OpenStack in the past. [1] https://review.opendev.org/#/c/734074/ [3] http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012806… -- Thierry Carrez (ttx)

2 1

[all][qa][gate] Gate Status: week 20-25
by Ghanshyam Mann 23 Jun '20

23 Jun '20

Hello Everyone, I am highlighting the few of the gate issues we fixed or in-progress last week 1. uwsgi bug: https://bugs.launchpad.net/devstack/+bug/1883468: Fixed till stable/stein Updates - http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015558.html 2. neutron-greande-multinode failure: In-progress greande base zuulv3 jobs are backported till train[1] which will be required to backport neutron-greande-multinode zuulv3 version. Ussuri backports are not yet merged which need more fixes on neutron CI[2]. Please wait for that backport to merge before recheck. 3. 'tox not found': https://bugs.launchpad.net/devstack/+bug/1884256: Fixed for known failure. This also started happening in many jobs. neutron and python-temepstconf jobs. devstack base integration jobs do not install tox (devstack functional base jobs does). If your job is derived from devstack integration base jobs and run test via tox env then you may need this to fix. NOTE: tempest jobs are all good as devstack's install_tempest() method do install tox for tempest tests run. Fix- https://review.opendev.org/#/c/737016/1 4. 'virtualenv not found': If this is happening on zuulv3 jobs then please refer the Ian's email[3]. if that is happening on legacy jobs then the recommendation is to migrate the jobs to zuulv3 like done for neutron-greande-multinode job. We are facing this issue on nova grenade as well as nova live migration jobs(legacy multinode jobs), there are multiple updates happened on devstack, grenade and image side, so I have reached the nova stable branch patches let's see what all still failing. 5. tempest sanity job failure for 'virualenv not found': Fixed The fix is merged and you can recheck your Tempest patches. Fixed: https://review.opendev.org/#/c/736952/5 6. To fixes all the all failure happening on EM stables, first step we are trying is to move the process-stackviz role from tempest to devstack so that we can apply the fixes for those stable in that role. If it stays in Tempest then fixes cannot be applied to old Tempest used for EM stable testing. More details in these patches[4] [1] https://review.opendev.org/#/q/topic:fix-grenade-multinode-train+(status:op… [2] https://review.opendev.org/#/c/735948/ [3] http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015425.html [4] https://review.opendev.org/#/q/topic:move-stackviz-role+(status:open+OR+sta… -gmann

1 2

[nova][db][haproxy] Question
by Amjad Kotobi 23 Jun '20

23 Jun '20

Hi, In our control plane cluster which HA setup by - Pacemaker/Corosync - HAProxy When I’m moving virtual IP (VIP) to another node services - nova[api-scheduler-conductor] - cinder - etc… In all logs show ERROR nova.servicegroup.drivers.db DBConnectionError: (pymysql.err.OperationalError) (2003, "Can't connect to MySQL server on '10.60.1.220' ([Errno 111] ECONNREFUSED)") [SQL: u'SELECT 1’] And here is haproxy.cfg ########## global chroot /var/lib/haproxy daemon group haproxy maxconn 16000 pidfile /var/run/haproxy.pid user haproxy defaults log 127.0.0.1 local0 maxconn 16000 option redispatch retries 3 timeout http-request 10s timeout queue 1m timeout connect 10s timeout client 3600s timeout server 3600s timeout check 10s listen galera_cluster bind 10.60.1.220:3306 balance source server controller5 10.60.1.15:3306 check inter 2000 rise 2 fall 5 server controller6 10.60.1.16:3306 backup check inter 2000 rise 2 fall 5 server controller7 10.60.1.17:3306 backup check inter 2000 rise 2 fall 5 ########### I know it’s not service level problem or bug and causing by haproxy and mysql connection. I’m wondering if any experience or idea how to deal with it will be great

1 0

[dragonflow] Finish retiring project
by Sean McGinnis 23 Jun '20

23 Jun '20

This is a notice to make sure folks are aware. I plan on completing the retirement process for the dragonflow project. Dragonflow was removed from official governance in late 2018 with: https://review.opendev.org/#/c/613856/ While removed from governance, the project still had a few occasional contributors. Actual development had already tapered off, but really since removal from governance, activity has dwindled to the occasional gate or requirement related update, or random typo corrections. The last patches that have merged for this repo were in August 2019, and gate jobs have been broken for some time now with no one working on fixing them. This is to serve as an announcement of my intent to follow the retirement process to officially mark the project as retired and clean things up. Please respond here if there are an concerns about this plan. Sean

1 0

[neutron][neutron-dynamic-routing] Call for maintainers
by Slawek Kaplonski 23 Jun '20

23 Jun '20

Hi, During last, virtual PTG we discussed about health of neutron stadium projects (again). And it seems that neutron-dynamic-routing project is slowly going to be in similar state as neutron-fwaas in Ussuri. So there is basically no active maintainers of this project in our community. In Ussuri cycle there was Ryan Tidwell from SUSE who was taking care of this project but AFAIK he is not able to do that anymore in Victoria cycle. So, if You are using this project or are interested in it, please contact me by email or on IRC that You want to take care of it. Usually this don't means like a lot of work every day. But we need someone who we can ask for help e.g. when gate is broken or when there is some new bug reported and there is need to triage it. -- Slawek Kaplonski Senior software engineer Red Hat

6 10

[openstack-helm] Meeting Canceled - June 23rd 2020
by Gage Hugo 23 Jun '20

23 Jun '20

Hello, Today's meeting for OpenStack-Helm is cancelled. We will meet at the regular time next week.

1 0

[kuryr][kuryr-libnetwork]
by Michał Dulko 23 Jun '20

23 Jun '20

Hi, Due to shortage of kuryr-libnetwork core reviewers Hongbin proposed that we should soften the rules a bit and allow merging patches with just one +2. I'm totally fine with that, especially as the volume of changes showing up in the project is pretty small. If nobody will have anything against the idea, I'll just go on and update the docs later this week. Thanks, Michał

2 2

[tripleo] Stop using host's /run|/var/run inside containers
by Cédric Jeanneret 23 Jun '20

23 Jun '20

Hello all! While working on podman integration, especially the SELinux part of it, I was wondering why we kept using the host's /run (or its replicated /var/run) location inside containers. And I'm still wondering, 2 years later ;). Reasons: - from time to time, there are patches adding a ":z" flag to the run bind-mount. This breaks the system, since the host systemd can't write/access container_file_t SELinux context. Doing a relabeling might therefore prevent a service restart. - in order to keep things in a clean, understandable tree, getting a dedicated shared directory for the container's sockets makes sense, as it might make things easier to check (for instance, "is this or that service running in a container?") - if an operator runs a restorecon during runtime, it will break container services - mounting /run directly in the containers might expose unwanted sockets, such as DBus (this creates SELinux denials, and we're monkey-patching things and doing really ugly changes to prevent it). It's more than probable other unwanted shared sockets end in the containers, and it might expose the host at some point. Here again, from time to time we see new SELinux policies being added in order to solve the denials, and it creates big holes in the host security AFAIK, no *host* service is accessed by any container services, right? If so, could we imagine moving the shared /run to some other location on the host, such as /run/containers, or /container-run, or any other *dedicated* location we can manage as we want on a SELinux context? I would therefore get some feedback about this proposed change. For the containers, nothing should change: - they will get their /run populated with other containers sockets - they will NOT be able to access the host services at all. Thank you for your feedback, ideas and thoughts! Cheers, C. -- Cédric Jeanneret (He/Him/His) Sr. Software Engineer - OpenStack Platform Deployment Framework TC Red Hat EMEA https://www.redhat.com/

2 3

[tc][election] campaign discussion: how TC can solve the less contributor issue?
by Ghanshyam Mann 22 Jun '20

22 Jun '20

This topic is a very important and critical area to solve in the OpenStack community. I personally feel and keep raising this issue wherever I get the opportunity. To develop or maintain any software, the very first thing we need is to have enough developer resources. Without enough developers (either open or closed source), none of the software can survive. OpenStack current situation on contributors is not the same as it was few years back. Almost every project is facing the less contributor issue as compare to requirements and incoming requests. Few projects already dead or going to be if we do not solve the less contributors issue now. I know, TC is not directly responsible to solve this issue but we should do something or at least find the way who can solve this. What do you think about what role TC can play to solve this? What platform or entity can be used by TC to raise this issue? or any new crazy Idea? -gmann

14 26

[Image-Encryption] current state
by Josephine Seifert 22 Jun '20

22 Jun '20

Hi from the image-encryption-popupteam, we would like to provide a summary of what happened during the last year: 1. Secret Consumers in Barbican [1] As a foundation for the image encryption - and to not accidentally delete a secret, which is still in use - the Barbican team implemented the secret consumers. Their is still some work ongoing for the API part. We will use this feature whenever a image will be encrypted. 2. Specs We wrote Specs to describe, what we Image Encryption is and how it would affect Glance, Cinder and Nova. The Cinder spec got merged [2] . The Glance spec is still being reviewed [3]. And the nova spec is abandoned [4]. Nova is currently not part anymore, because of a missing ephemeral storage encryption needed for a coherent security mode. 3. WIP-patches We implemented two WIP-patches to let Glance devs get a better idea of how image encryption is affecting Glance. We provided a patch for Glance [5] and one for os-brick [6], which handles the encryption and decryption of images. [1] https://review.opendev.org/#/q/project:openstack/barbican+secret-consumer [2] https://review.opendev.org/#/c/608663/ [3] https://review.opendev.org/#/c/609667/11 [4] https://review.opendev.org/#/c/608696/ [5] https://review.opendev.org/#/c/705445/ [6] https://review.opendev.org/#/c/709432/ We appreciate reviews on the spec and the WIP-patches. greetings Josephine (Luzi) & Markus (mhen)

2 1

Q2 Open Infrastructure Community Meetings - June 25th
by Sunny Cai 22 Jun '20

22 Jun '20

Hello everyone, The Q2 OSF Community meetings are only three days away! The project teams are holding two community meetings: one on Thursday, June 25th at 8am PT and another one on the same day at 7pm PT (June 26th at 10am Beijing Time). Here I have attached the calendar invites for the two community meetings. Join us: • Thursday, June 25 at 8am PT (1500 UTC) • Moderator • Jimmy McArthur, OSF • Presenters / Open for Questions • Airship: Alex Hughes • Kata Containers: Eric Ernst • OpenInfra Labs: Michael Daitzman • OpenStack: Ghanshyam Mann • OpenStack 10th birthday: Sunny Cai • StarlingX: Bruce Jones • Zuul: Monty Taylor • OpenInfra / OpenStack Days: Allison Price • Open Infrastructure Summit: Erin Disney • PTG: Kendall Waters • OpenDev: Ashlee Ferguson • Thursday, June 25 at 7pm PT (June 26th at at 0200 UTC/10am China Standard Time) • Moderator: • Sunny Cai, OSF • Presenters / Open for Questions • Airship: Alex Hughes • Kata Containers: Xu Wang • OpenInfra Labs: Michael Daitzman • OpenStack: Rico Lin • OpenStack 10th birthday: Sunny Cai • StarlingX: Yong Hu • Zuul: Clark Boylan • OpenInfra / OpenStack Days: Horace Li • Open Infrastructure Summit: Erin Disney • PTG: Kendall Waters • OpenDev: Ashlee Ferguson Zoom links for each meeting can be found in the calendar hold or here: https://etherpad.opendev.org/p/OSF_Community_Meeting_Q2 <https://etherpad.opendev.org/p/OSF_Community_Meeting_Q2> See you there! Sunny Cai OpenStack Foundation sunny(a)openstack.org <mailto:sunny@openstack.org>

1 0

[tc] weekly update
by Mohammed Naser 22 Jun '20

22 Jun '20

Hi everyone, Here’s an update for what happened in the OpenStack TC this week. You can get more information by checking for changes in openstack/governance repository. Kristi’s change has been open for quite sometime without much response, I’d like to ask for our TC members to please have a look at it. # OPEN REVIEW - [draft] Add assert:supports-standalone https://review.opendev.org/#/c/722399/ [open for 47 days] - Create starter-kit:kubernetes-in-virt tag https://review.opendev.org/#/c/736369/ # PROJECT UPDATES - Record deprecated cycle for deprecated project https://review.opendev.org/#/c/736084/ - Remove mox3 from governance https://review.opendev.org/#/c/736754/ - Deprecate neutron-fwaas and neutron-fwaas-dashboard master branch https://review.opendev.org/#/c/735828/ - Add openstack-ansible-os_adjutant repo https://review.opendev.org/#/c/736140/ - Retire Paunch https://review.opendev.org/#/c/734855/ - Retire swift-specs https://review.opendev.org/#/c/733901/ - Retire puppet-congress https://review.opendev.org/#/c/737145/ # PROJECTS RETIRED - Remove tricircle project team https://review.opendev.org/#/c/731566/ # GENERAL CHANGES - Remove grace period on resolutions https://review.opendev.org/#/c/735361/ - Tools: update check-review-status to drop grace period https://review.opendev.org/#/c/735361/ - Tools: fix check_review_status for new project-update https://review.opendev.org/#/c/735660/ - Update joining-tc.rst to be general tc-guide.rst https://review.opendev.org/#/c/735660/ - Assign TC Liasons for the Victoria Cycle https://review.opendev.org/#/c/735667/ - Add evrardjp liaison preferences https://review.opendev.org/#/c/735499/ - Add ricolin liaison preference https://review.opendev.org/#/c/735506/ - Add more clarification on project retirement process https://review.opendev.org/#/c/734648/ - Merging TC and UC into a single body https://review.opendev.org/#/c/734074/ # ABANDONED CHANGES - Document project removal and deprecation process https://review.opendev.org/#/c/734930/ Overall, I’m also pretty happy with our bandwidth at landing things with our relaxing governance rules. I'm going to look at more ways we can land more things quicker soon again Thanks, Mohammed -- Mohammed Naser VEXXHOST, Inc.

1 0

[neutron] netflow exports from open vswitch
by James Denton 22 Jun '20

22 Jun '20

Hello all, Has anyone here configured their Neutron-managed Open vSwitch to export netflow data to a collector? I’ve seen plenty of documentation on how to configure the export, but little-to-nothing regarding this configuration within the scope of an OpenStack cloud. Seems pretty straightforward, but we’re curious as to what the performance impacts might be and whether or not the configuration gets wiped or persists in the OVSDB. Thanks! James Denton

1 0

[neutron] subnet policy for ip allocation
by Ruslanas Gžibovskis 22 Jun '20

22 Jun '20

Hi team, I need that my IP addresses in subnet would not be allocated from the beginning, but it would go to the next IP compared to previous used: instance1 created: 1.1.1.1 Instance2 created: 1.1.1.2 instance1 deleted. instance2 deleted. Instance3 created: 1.1.1.3 (not 1.1.1.1 again) I remember have read about such, do not remember how to google it... -- Ruslanas Gžibovskis +370 6030 7030

2 2

[neutron] Bug deputy report (week starting on 2020-06-15)
by Bernard Cafarelli 22 Jun '20

22 Jun '20

Hello neutrinos, time for a new bug deputy rotation again, here is the list for week 25. Aside from the week highlights (aka multiple gate issues, see Ghanshyam's gate status recap mail), most reported bugs are underway except 1884067 <https://bugs.launchpad.net/neutron/+bug/1884067> (high, filtering issue) and 1884254 <https://bugs.launchpad.net/neutron/+bug/1884254> (low, potential dataplane issues) Critical * ovn based neutron gate jobs failing 100% of times - https://bugs.launchpad.net/neutron/+bug/1883601 OVS compilation failure with latest kernel, fixed in master https://review.opendev.org/735799 * 'tox' not present on devstack based jobs - https://bugs.launchpad.net/devstack/+bug/1884256 Fixed in master: https://review.opendev.org/737016/ High * [API] Filtering by fields not allowed to see is possible for regular users - https://bugs.launchpad.net/neutron/+bug/1884067 Unassigned * Adding a third DHCP agent to the network fails due to binding index error - https://bugs.launchpad.net/neutron/+bug/1883513 Probably introduced by https://review.opendev.org/288271/, fix in progress: https://review.opendev.org/735872 * [ovn] Agent liveness checks create too many writes into OVN db - https://bugs.launchpad.net/neutron/+bug/1883554 OVN Performance hit, fix merged: https://review.opendev.org/735618 * [SRIOV] SR-IOV agent need to have privsep configured - https://bugs.launchpad.net/neutron/+bug/1883757 Fix for SRIOV with macvtap, merged: https://review.opendev.org/735982 * [DHCP] IPv6 "addr6_list" change the "host" file format - https://bugs.launchpad.net/neutron/+bug/1884105 Fix merged: https://review.opendev.org/736778 Medium * [OVN] enable_distributed_floating_ip changes are not applied for existing NAT entries - https://bugs.launchpad.net/neutron/+bug/1883559 Fix in progress: https://review.opendev.org/735613 * Failed to create a duplicate DefaultSecurityGroup (with Calico plugin) - https://bugs.launchpad.net/neutron/+bug/1883730 Fix in progress: https://review.opendev.org/736842 Low * Restart of neutron-ovs-agent may cause data plane breakage - https://bugs.launchpad.net/neutron/+bug/1884254 Unassigned, can happen with rabbitmq connectivity issue * tc_lib (QoS; tc qdisc tbf) uses wrong value for byte/s conversion - https://bugs.launchpad.net/bugs/1884273 kbit/kibit issue, fix in progress: https://review.opendev.org/737044 Wishlist * Neutron should retry http connections when notifying e.g. nova - https://bugs.launchpad.net/neutron/+bug/1883712 Similar to a patch in nova (adding retries parameter to neutron client calls), fix in progress: https://review.opendev.org/736026 Invalid/incomplete * Subnet creation with gateway outside of CIDR is allowed - https://bugs.launchpad.net/neutron/+bug/1884009 As reminded by amotoki, this is intentional, discussed in https://bugs.launchpad.net/neutron/+bug/1335023 * Got unknown error when creating subnet without subnetpool - https://bugs.launchpad.net/python-neutronclient/+bug/1884334 Error missing in openstack CLI command, this was fixed some time ago -- Bernard Cafarelli

1 0