- openstack-discuss - lists.openstack.org

[neutron] Drivers team meeting 07.05.2021 cancelled
by Slawek Kaplonski 06 May '21

06 May '21

Hi, Due to lack of new RFEs and any other topics, let's cancel tomorrow's meeting. Please use that time to review some of the already proposed specs: https:// review.opendev.org/q/project:openstack/neutron-specs+status:open[1] See You online :) -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] https://review.opendev.org/q/project:openstack/neutron-specs+status:open

1 0

[Octavia] 2021-05-12 weekly meeting cancelled
by Gregory Thiemonge 05 May '21

05 May '21

Hi, I'll be on PTO next Wednesday, I won't be able to run the meeting. We decided during yesterday's meeting that next week meeting is cancelled, Thanks, Greg

1 0

[wallaby][magnum] magnum-conductor Service down
by Ammad Syed 05 May '21

05 May '21

Hi, I am experiencing a problem in magnum 12.0.0 that conductor service randomly goes down. I am using ubuntu 20.04. root@controller ~(keystone_ubuntu20_new)# openstack coe service list +----+------+------------------+-------+----------+-----------------+---------------------------+---------------------------+ | id | host | binary | state | disabled | disabled_reason | created_at | updated_at | +----+------+------------------+-------+----------+-----------------+---------------------------+---------------------------+ | 1 | None | magnum-conductor | down | False | None | 2021-05-03T10:33:16+00:00 | 2021-05-05T21:48:39+00:00 | +----+------+------------------+-------+----------+-----------------+---------------------------+---------------------------+ checking the logs of last updated timestamp in /var/log/syslog. I have found below error. May 5 21:49:29 orchestration magnum-conductor[10827]: /usr/lib/python3/dist-packages/magnum/drivers/common/driver.py:38: PkgResourcesDeprecationWarning: Parameters to load are deprecated. Call .resolve and .require separately. May 5 21:49:29 orchestration magnum-conductor[10827]: yield entry_point, entry_point.load(require=False) May 5 21:49:29 orchestration magnum-conductor[10827]: /usr/lib/python3/dist-packages/kubernetes/client/apis/__init__.py:10: DeprecationWarning: The package kubernetes.client.apis is renamed and deprecated, use kubernetes.client.api instead (please note that the trailing s was removed). May 5 21:49:29 orchestration magnum-conductor[10827]: warnings.warn( May 5 21:49:29 orchestration magnum-conductor[10827]: /usr/lib/python3/dist-packages/magnum/drivers/common/driver.py:38: PkgResourcesDeprecationWarning: Parameters to load are deprecated. Call .resolve and .require separately. May 5 21:49:29 orchestration magnum-conductor[10827]: yield entry_point, entry_point.load(require=False) May 5 21:49:29 orchestration magnum-conductor[10827]: Traceback (most recent call last): May 5 21:49:29 orchestration magnum-conductor[10827]: File "/usr/lib/python3/dist-packages/eventlet/hubs/hub.py", line 476, in fire_timers May 5 21:49:29 orchestration magnum-conductor[10827]: timer() May 5 21:49:29 orchestration magnum-conductor[10827]: File "/usr/lib/python3/dist-packages/eventlet/hubs/timer.py", line 59, in __call__ May 5 21:49:29 orchestration magnum-conductor[10827]: cb(*args, **kw) May 5 21:49:29 orchestration magnum-conductor[10827]: File "/usr/lib/python3/dist-packages/eventlet/semaphore.py", line 152, in _do_acquire May 5 21:49:29 orchestration magnum-conductor[10827]: waiter.switch() May 5 21:49:29 orchestration magnum-conductor[10827]: greenlet.error: cannot switch to a different thread There is no logs in magnum-conductor.log after the last updated timestamp of conductor service. The service looks running if I see in ps -ef | grep magnum-conductor. - Ammad

1 0

[wallaby][neutron][ovn] Distributed FIP
by Malik Obaid 05 May '21

05 May '21

Hi, I am using Openstack Wallaby release on Ubuntu 20.04. I have enabled DVR and Distributed FIP on 1 controller node and 2 compute nodes, we have mapped an interface(ens224) with the physical network(br-eth1) using below command: ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth1 The issue I am facing here is that when I analyze the traffic on interface (ens224) while initializing ping from a VM on my compute node 1, it shows the traffic flowing through my controller as well as both the compute nodes rather than only flowing through compute node 1. I would really appreciate any input in this regard. Thank you. Regards, Malik Obaid

1 0

[all][tc] Technical Committee next weekly meeting on May 6th at 1500 UTC
by Ghanshyam Mann 05 May '21

05 May '21

Hello Everyone, Technical Committee's next weekly meeting is scheduled for May 6th at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, May 5th, at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann

1 1

[ptl][release][stable][EM] Extended Maintenance - Train
by Előd Illés 05 May '21

05 May '21

Hi, As Wallaby was released the day before yesterday and we are in a less busy period, it is a good opportunity to call your attention to the following: In less than a month Train is planned to transition to Extended Maintenance phase [1] (planned date: 2021-05-12). I have generated the list of the current *open* and *unreleased* changes in stable/train for the follows-policy tagged repositories [2] (where there are such patches). These lists could help the teams who are planning to do a *final* release on Train before moving stable/train branches to Extended Maintenance. Feel free to edit and extend these lists to track your progress! * At the transition date the Release Team will tag the*latest* (Train) *releases* of repositories with *train-em* tag. * After the transition stable/train will be still open for bug fixes, but there won't be any official releases. NOTE: teams, please focus on wrapping up your libraries first if there is any concern about the changes, in order to avoid broken releases! Thanks, Előd [1] https://releases.openstack.org/ [2] https://etherpad.opendev.org/p/train-final-release-before-em

1 1

[TripleO] stable/wallaby branch for tripleo repos \o/ ping if problems :)
by Marios Andreou 05 May '21

05 May '21

Hello tripleo o/ now that https://review.opendev.org/c/openstack/releases/+/789558 merged (thanks elod & hberaud for reviews) we have a stable/wallaby branch for all tripleo repos (list at [1]). Note that for python-tripleoclient & tripleo-common the branch was previously created with [2] as part of our testing and preparation. Special thank you to all those involved from the tripleo-ci team - rlandy, baghyashris, ysandeep, ananya (frenzy_friday), pojadav and apologies to those I missed. Preparations started at least six weeks ago (i.e. the previous 2 sprints). If you are interested in our prep work there are some notes and pointers at [3]. So: * stable/wallaby for tripleo repos is now a thing \o/ * go ahead and post patches to stable/wallaby (you'll need those .gitreview things to merge first like [4]) * If there are issues with CI please reach out to tripleo-ci in freenode #tripleo or #oooq - especially ping the persons with |ruck or |rover in the irc nickname [5] I'll deal with the launchpad side of things next (moving ongoing bugs over from wallaby-rc1 to xena-1 etc), regards, marios [1] https://releases.openstack.org/teams/tripleo.html#wallaby [2] http://lists.openstack.org/pipermail/openstack-discuss/2021-April/021741.ht… [3] https://hackmd.io/2sxlx1XzTa-Te47_zLv42Q?view [4] https://review.opendev.org/c/openstack/tripleo-heat-templates/+/789889 [5] https://docs.openstack.org/tripleo-docs/latest/ci/ruck_rover_primer.html

2 2

[TripleO] stable/wallaby branching
by Marios Andreou 05 May '21

05 May '21

Hello TripleO, quick update on the plan for stable/wallaby branching. The goal is to release tripleo stable/wallaby just after PTG i.e. last week of April. The tripleo-ci team have spent the previous sprint preparing and we now have the integration and component pipelines in place [1][2]. As of today we should also have the upstream check/gate multinode branchful jobs. We are planning to use this current sprint to resolve issues and ensure we have the CI coverage in place so we can safely release all the tripleo things. As we usually do, we are going to first branch python-tripleoclient and tripleo-common so we can exercise and sanity check the CI jobs. The stable/wallaby for client and common will appear after we merge [3]. *** PLEASE AVOID *** posting patches to stable/wallaby python-tripleoclient or tripleo-common until the CI team has completed our testing. Basically until we are ready to create a stable/wallaby for all the tripleo things (which will be announced in due course). Obviously as always please speak up if you disagree with any of the above or if something doesn't make sense or if you have any concerns about the proposed timings regards, marios [1] https://review.rdoproject.org/zuul/builds?pipeline=openstack-periodic-integ… [2] https://review.rdoproject.org/zuul/builds?pipeline=openstack-component-trip… [3] https://review.opendev.org/c/openstack/releases/+/785670

1 1

[infra] Retiring the LimeSurvey instance at survey.openstack.org
by Jeremy Stanley 05 May '21

05 May '21

We are retiring our beta-test LimeSurvey service that was running on survey.openstack.org, as well as decommissioning the server itself, some time later today. Our survey service never saw production use. It was a compelling idea, but the prevalence of free surveys-as-a-service options (a number of which are built with open source software) meant that the only real benefit to running our own was that we didn't need to entrust the response data to third party organizations. As a result, there's been very limited use of the offering and in order to redirect our limited time and resources to services where we can provide the most benefit to our communities, we're ending this one. -- Jeremy Stanley

1 0

[cinder] Bug deputy report for week of 2021-05-05
by Sofia Enriquez 05 May '21

05 May '21

Hello, This is a bug report from 2021-04-21 to 2021-05-05. You're welcome to join the next Cinder Bug Meeting later today. Weekly on Wednesday at 1500 UTC on #openstack-cinder Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ------------------------------------------------------------------------------------------------------------ Critical:- High: - https://bugs.launchpad.net/cinder/+bug/1925818 "Retype of non-encrypted root volume to encrypted fails". Unassigned. - https://bugs.launchpad.net/python-cinderclient/+bug/1926331 "Allow cinderclient to handle system-scoped tokens". Unassigned. Medium: - https://bugs.launchpad.net/cinder/+bug/1926630 " Creating an encrypted volume type without a cipher accepted but will fail to create an encrypted volume". Assigned to Eric Harney. - https://bugs.launchpad.net/cinder/+bug/1925809 "[RBD] Cinder backup python3 encoding issue". Unassigned. - https://bugs.launchpad.net/cinder/+bug/1924264 "volume creation with `--hint local_to_instance=UUID` is failing, because deprecated novaclient attribute `list_extensions` is used". Assigned to Pavlo Shchelokovskyy. - https://bugs.launchpad.net/cinder/+bug/1923866 "Netapp dataontap NFS manage operation fails with ipv6 reference". Unassigned. Low: - https://bugs.launchpad.net/cinder/+bug/1926408 "quota-show should raise exception when non-existent tenant id was given". Unassigned. - https://bugs.launchpad.net/cinder/+bug/1926336 " The cinder API should fail early if a system-scoped token is provided without a project ID". Unassigned. - https://bugs.launchpad.net/cinder/+bug/1924574 " [Storwize]: Configure to manage GMCV changed volumes on a separate child pool". Unassigned. - https://bugs.launchpad.net/python-cinderclient/+bug/1925737: "List volumes can not be filtered by bootable". Unassigned. Incomplete: - https://bugs.launchpad.net/cinder/+bug/1927186 "The value of allocated_capacity_gb is incorrect when the number of replicas of cinder-volume is more than one and all of them configured on the same backend". Unassigned. Cheers, Sofi -- L. Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

[docs] bug tracker for individual projects' search pages
by Erik Panter 05 May '21

05 May '21

Hi, I'm having issues with the individual projects' doc search pages (e.g. https://docs.openstack.org/neutron/victoria/search.html?q=test) since ussuri: When searching Ussuri and Victoria docs, malformed links are returned, and for Wallaby it doesn't return any results. It seems to affect multiple projects that provide the search page, so I am not sure where to report it. Can someone point me to the correct project/bug tracker? Thanks, Erik _____ Erik Panter Systementwickler | Infrastruktur Mittwald CM Service GmbH & Co. KG Königsberger Straße 4-6 32339 Espelkamp Tel.: 05772 / 293-900 Fax: 05772 / 293-333 Mobil: 0151 / 12345678 e.panter(a)mittwald.de https://www.mittwald.de Geschäftsführer: Robert Meyer, Florian Jürgens St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen Informationen zur Datenverarbeitung im Rahmen unserer Geschäftstätigkeit gemäß Art. 13-14 DSGVO sind unter www.mittwald.de/ds abrufbar.

3 4

[TC][Interop] process change proposal for interoperability
by Kanevsky, Arkady 05 May '21

05 May '21

Team, Based on guidance from the Board of Directors, Interop WG is changing its process. Please, review https://review.opendev.org/c/osf/interop/+/787646 Guidelines will no longer need to be approved by the board. It is approved by "committee" consisting of representatives from Interop WG, refstack, TC and Foundation marketplace administrator. Will be happy to discuss and provide more details. Looking for TC review and approval of the proposal before I present it to the board. Thanks, Arkady Kanevsky, Ph.D. SP Chief Technologist & DE Dell Technologies office of CTO Dell Inc. One Dell Way, MS PS2-91 Round Rock, TX 78682, USA Phone: 512 7204955

4 7

[all][tc] Nodejs version change in Xena cycle testing runtime
by Ghanshyam Mann 04 May '21

04 May '21

Hello Everyone, We have done a change in Xena cycle testing runtime on bumping the Nodejs version from Nodejs10 to Nodejs14[1]. Nodejs10 is going to EOL by April 2021 [2]. If you have any jobs running on Nodejs10, please upgrade it to Nodejs14. Vishal from the Horizon team will drive this effort and looking forward to coordination on code/review. [1] https://review.opendev.org/c/openstack/governance/+/788306 [21] https://nodejs.org/en/about/releases/ -gmann

1 0

[release][ironic] ironic-python-agent-builder release model change
by Riccardo Pittau 04 May '21

04 May '21

Hello fellow openstackers! During the recent xena ptg, the ironic community had a discussion about the need to move the ironic-python-agent-builder project from an independent model to the standard release model. When we initially split the builder from ironic-python-agent, we decided against it, but considering some problems we encountered during the road, the ironic community seems to be in favor of the change. The reasons for this are mainly to strictly align the image building project to ironic-python-agent releases, and ease dealing with the occasional upgrade of tinycore linux, the base image used to build the "tinyipa" ironic-python-agent ramdisk. We'd like to involve the release team to ask for advice, not only on the process, but also considering that we need to ask to cut the first branch for the wallaby stable release, and we know we're a bit late for that! :) Thank you in advance for your help! Riccardo

5 8

[glance][ptg] Glance Xena PTG summary
by Abhishek Kekane 04 May '21

04 May '21

Hello Everyone, Apologies for delay in sending the PTG summary and Thank you to everyone who attended the Glance Xena PTG. We had extremely eventful discussions around Secure RBAC and some new ideas for improvement in Glance. Here is a short summary of the discussions. See the Etherpad [1] for full notes. Tuesday, April 20 # Wallaby Retrospective On the positive note, we merged a number of useful features this cycle. We managed to implement a project scope of secure RBAC for images API and Distributed image import stuff. On the other side we had usual problems of review bandwidth and we were not able to keep our focus on reducing/managing the glance bugs backlog. We really need more people in the community helping out with reviews, and ideally moving to become members of the core team. We are happy to onboard new members with appropriate help. # Bug squashing per milestone Unfortunately (due to lack of contributors) glance community was unable to keep track of its bug backlog for the past couple of cycles. This cycle our main focus is to revisit old bugs and reduce the bug backlogs for glance, glance_store and python-glanceclient. We agreed to discuss existing bugs in our weekly meeting after every two weeks for 15-20 minutes. # Interop WG interlock During this session we discussed the state of existing glance tempest coverage and what action needs to be taken if there are any API changes or new API is introduced. Wednesday, April 21 # Secure RBAC - OSSN-0088 This entire day we discussed implementing Secure RBAC in glance. We also decided to discuss with Lance/Gmann whether it is fine to add deprecation warnings for OSSN-0088 on master branch or we should add those directly to stable/wallaby branch where we have defaulted some metaded APIs to admin only. # Glance policy - revisit, restructure We also discussed to revisit and restructure our policy layer. At the moment glance is injecting policies at different layers and most of the policies are injected closed to the database layer. This approach is causing problems in implementing the secure RBAC for location/tasks APIs. During this cycle we are going to experiment on restructuring the policy layer of glance (approach will be to work on restructuring modiffy_image policy and then submit the spec on the basis of that finding before moving forward). # Secure RBAC - Hardening project scope, Implementing System scope/personas During discussion on this topic we identified that to implement system scope in glance we first need to restructure the glance policy layer. Which means we need to keep our focus on restructuring the glance policy layer in this cycle. Also at the moment only publicize_image policy is an appropriate candidate for system scope. So we need to identify whether there are any other APIs which can also use system scope. Thursday, April 22 # Native Image Encryption As this work has dependency on Barbican which is yet to be completed, we decided to revisit the progress of the same around Milestone 2 and decide whether we are ready to implement this feature in Xena cycle or postpone it to next cycle. # Multi-format images We need to identify regression on Nova if we decide to implement the same. I need to connect with dansmith to understand more about it. If there are no side effects then we will be working on design/specification for this feature in this cycle and implement the same in the next cycle. Erno also suggested that we should improve the image conversion plugin based on multiple stores support. # Cinder - Glance cross project discussion During this discussion Rajat (cinder driver maintainer for glance) walked us through the current state of cinder driver of glance and how we could add support for the new attachment API for cinder driver. Friday, April 23 # Cache-API We already agreed on implementation design about the same, the only reason it is pending is we shifted our focus on RBAC in the last cycle. So it is decided to wait for a couple of weeks in this cycle if we get any new contributor to work on it or else implement the same during milestone 1. # Glance Quotas This topic was raised on the fly by belmoreira during the PTG so we discussed the same. We decided to assess the use of keystone's unified limits and put up a design/specification in glance to add quotas for images. Apart from above topics during Open discussion we also discussed some of the swift related bugs which we will be addressing during this cycle. You will find the detailed information about the same in the PTG etherpad [1] along with the recordings of the sessions. I would once again like to thank everyone for joining us in the PTG. [1] https://etherpad.opendev.org/p/xena-glance-ptg Thanks and Regards, Abhishek

1 0

[CLOUDKITTY] Missed CloudKitty meeting today
by Rafael Weingärtner 04 May '21

04 May '21

Hello guys, I would like to apologize for missing the CloudKitty meeting today. I was concentrating on some work, and my alarm for the meeting did not ring. I still have to summarize the PTL meeting. I will do so today. Again, sorry for the inconvenience; see you guys at our next meeting. -- Rafael Weingärtner

3 5

[kolla][ptg] Kolla PTG summary
by Mark Goddard 04 May '21

04 May '21

Hi, Thank you to everyone who attended the Kolla Xena PTG. Thank you also to those who helped out with chairing and driving discussions, since I had a cold and my brain was far from 100%. Here is a short summary of the discussions. See the Etherpad [1] for full notes. # Wallaby Retrospective On the positive side, we merged a number of useful features this cycle, and eventually mitigated the Dockerhub pull limit issues in CI by switching to quay.io. On the negative side, we feel that we have lost some review bandwidth recently. We really need more people in the community helping out with reviews, and ideally moving to become members of the core team. The barrier for entry is probably lower than you think, and the workload does not have to be too heavy - every little helps. PLEASE get in touch if you are interested in helping out. # Review Wallaby PTG actions Many of these are incomplete and still relevant. As usual, it's easier to think of things to do than find time to do them. I've added them at the end of the actions section of the etherpad, and we can revisit them throughout the Xena cycle. # General topics ## Deprecations In the continuing drive to reduce the maintenance overhead of the project, we discussed which components or features might need to be deprecated next. With Tripleo out of the picture, RHEL support is not tested, so it will be deprecated in Wallaby for removal in Xena. We discussed standardising on source image type and dropping support for binary images, but agreed (once again) that it would be too disruptive for users, and the repository model may be easier for users to mirror. ## Release process We agreed to document some more of our release process. We also agreed to try a new approach in Xena, where we begin the cycle deploying the previous release of OpenStack (Wallaby) on our master branches, to avoid firefighting caused by breakage in OpenStack projects. This should provide us with more stability while we add our own features. The downside is that we may build up some technical debt to converge with the new release. Some details are still to be decided. ## Elasticsearch -> OpenSearch The recent Elasticsearch licence change may be a blocker in some organisations, and Amazon's OpenSearch appears to provide an alternative. The final OSS release of Elastic (7.10) EOL is 2022-05-10, so we have time to consider our options. Christian offered to investigate a possible migration. ## Reflection The team reflected a little on how things are going. We agreed that the 4 most active core team members form quite a tight unit that effectively makes decisions and keeps the project moving forward, with the help of other core team members and other community members. We also agreed that we are quite vulnerable to the loss of any of those 4, especially when we consider how many patches are authored and approved by any 3 of those 4, and their areas of expertise. ## Future leadership I have decided that this will be my last cycle as Kolla PTL. I still enjoy the role, but I think it is healthy to rotate the leadership from time to time. We have at least one person lined up for nomination, so watch this space! # Kolla (images) topics ## CentOS Stream 8 We have added support for CentOS Stream 8 (and dropped CentOS Linux 8) in the Wallaby release. Since CentOS Linux 8 will be EOL at the end of this year (THANK YOU VERY MUCH FOR THAT BY THE WAY), we need to consider which stable releases may need to have CentOS Stream 8 support backported. RDO will not support Train on stream. Ussuri will move to Extended Maintenance before the end of 2021, however we know that many users are still a few releases behind upstream. In the end, we agreed to start with backporting support to Victoria, then consider Ussuri once that is done. We agreed to keep CentOS Linux 8 as the default base image due to backwards compatibility promises. Stream images will have a victoria-centos8s tag to differentiate them, similarly to how we handled CentOS 8. ## Official plugins We agreed to remove non-official plugins from our images. Often these projects branch late and break our release processes. We agreed to provide example config snippets and documentation to help adding these plugins back into images. # Kolla Ansible ## Glance metadef APIs (OSSN-0088) Glance team discussed this issue at the PTG, we have an action to follow up on their decision. ## Opinionated, hardened configuration Should we provide an opinionated, hardened configuration? For example TLS by default, conform to OpenStack security checklist, etc. Some nods of approval, but no one offering to implement it. ## Running kolla-ansible bootstrap-servers without stress Currently, running kolla-ansible bootstrap-servers on an existing system can restart docker on all nodes concurrently. This can take out clustered services such as MariaDB and RabbitMQ. There are various options to improve this, including a serial restart, or an intelligent parallel restart (including waiting for services to be up). We decided on an action to investigate enabling Docker live restore by default, and what its shortcomings may be. ## Removal/cleanup of services We again discussed how to do a more fine grained cleanup of services. Ideally this would be per-service, and could include things like dropping DBs and Keystone endpoints. yoctozepto may have time to look into this. ## Cinder active/active bug We are still affected by [2]. We have a fairly good plan to resolve it, but some details around migration of existing clusters need ironing out. yoctozepto and mnasiadka to continue looking at it. ## More fine grained skipping of tasks, e.g. allow to skip service registration We agreed to abandon the tag based approach in favour of pushing an existing effort [3] to make a split genconfig, deploy-containers command pair work. This achieves one of the main gains of skipping the bootstrap and registration steps, and is useful for other reasons. ## Letsencrypt We agreed to split the existing patches [4] into the contentious and non-contentious parts. Namely, separate HAProxy automatic certificate reload from certbot support. The HAProxy reload is currently implemented via supervisord and cron in the container, which does not fit well with our single process container model. We will look into an HAProxy upgrade for automatic certificate rotation detection as a possible solution. ## ProxySQL kevko outlined the proposed ProxySQL patch chain [5], as well as some more details on the nature of the problem being solved. In Wallaby we added initial support for multiple MariaDB clusters. ProxySQL builds on this, providing sharding at the database schema level between different OpenStack projects (nova, neutron, etc.). # Kayobe ## Running host configure during upgrades Pierre proposed a change [6] to our documented upgrade procedure to include a 'host configure' step. Sometimes this is necessary to upgrade or reconfigure Docker, or other parts of the host setup. We agreed that this should be done, but that we should also improve the 'kayobe <seed|seed-hypervisor|overcloud> host upgrade' commands to avoid a full host configure run. ## Support provisioning infrastructure VMs We walked through the proposed feature [7], including the various milestones proposed. An MVP if simply provisioning infra VMs on the seed hypervisor was agreed. ## Ubuntu We discussed what has been achieved [8] in Wallaby so far, what still needs to be done before the release, and what we have left to look at in Xena and beyond. We are on track to have most features available in Wallaby. We discussed whether to backport this work to Victoria. It will depend on how cleanly the code applies. ## Multiple environments Pierre implemented the majority of this long-awaited feature [9] in Wallaby. We still require CI testing, and the ability to share common Kolla configuration between environments. These will be looked at in Xena. ## Multiple host images Pierre started work [10] on this feature. The aim is to describe multiple root disk images with different properties, then map these images to different overcloud hosts. # Priorities We usually vote for community priorities, however this cycle it was felt that they only have a minimal effect on activity. Let's see how it goes without them. Thanks, Mark [1] https://etherpad.opendev.org/p/kolla-xena-ptg [2] https://bugs.launchpad.net/kolla-ansible/+bug/1904062 [3] https://review.opendev.org/c/openstack/kolla-ansible/+/773246 [4] https://review.opendev.org/q/topic:%22bp%252Fletsencrypt-https%22+(status:o… [5] https://review.opendev.org/q/hashtag:%22proxysql%22+(status:open%20OR%20sta… [6] https://review.opendev.org/c/openstack/kayobe/+/783053 [7] https://storyboard.openstack.org/#!/story/2008741 [8] https://storyboard.openstack.org/#!/story/2004960 [9] https://storyboard.openstack.org/#!/story/2002009 [10] https://storyboard.openstack.org/#!/story/2002098

1 0

Openstack Stack issues
by Premkumar Subramaniyan 04 May '21

04 May '21

Hi, I am using the Openstack *USURI *version in *Centos7*. Due to some issues my disk size is full,I freed up the space. Afte that some service went down. After that I have issues in creating the stack and list stack. Attached the Screenshot for your reference [opnfv@aio1 ~]$ openstack stack list --debug START with options: stack list --debug options: Namespace(access_token='***', access_token_endpoint='', access_token_type='', application_credential_id='', application_credential_name='', application_credential_secret='***', auth_methods='', auth_type='', auth_url='http://10.200.134.218:5000/v3', cacert=None, cert='', client_id='', client_secret='***', cloud='', code='', debug=True, default_domain='default', default_domain_id='', default_domain_name='', deferred_help=False, discovery_endpoint='', domain_id='', domain_name='', endpoint='', identity_provider='', insecure=None, interface='public', key='', log_file=None, openid_scope='', os_beta_command=False, os_compute_api_version='', os_identity_api_version='3', os_image_api_version='', os_network_api_version='', os_object_api_version='', os_orchestration_api_version='1', os_project_id=None, os_project_name=None, os_volume_api_version='', passcode='', password='***', project_domain_id='default', project_domain_name='', project_id='0e75229392c54a398ab302a8e43aebe6', project_name='admin', protocol='', redirect_uri='', region_name='RegionOne', remote_project_domain_id='', remote_project_domain_name='', remote_project_id='', remote_project_name='', service_provider='', system_scope='', timing=False, token='***', trust_id='', user_domain_id='', user_domain_name='Default', user_id='', username='admin', verbose_level=3, verify=None) Auth plugin password selected auth_config_hook(): {'api_timeout': None, 'verify': True, 'cacert': None, 'cert': None, 'key': None, 'baremetal_status_code_retries': '5', 'baremetal_introspection_status_code_retries': '5', 'image_status_code_retries': '5', 'disable_vendor_agent': {}, 'interface': 'public', 'floating_ip_source': 'neutron', 'image_api_use_tasks': False, 'image_format': 'qcow2', 'message': '', 'network_api_version': '2', 'object_store_api_version': '1', 'secgroup_source': 'neutron', 'status': 'active', 'auth': {'user_domain_name': 'Default', 'project_domain_id': 'default', 'project_id': '0e75229392c54a398ab302a8e43aebe6', 'project_name': 'admin'}, 'verbose_level': 3, 'deferred_help': False, 'debug': True, 'region_name': 'RegionOne', 'default_domain': 'default', 'timing': False, 'username': 'admin', 'password': '***', 'auth_url': ' http://10.200.134.218:5000/v3', 'beta_command': False, 'identity_api_version': '3', 'orchestration_api_version': '1', 'auth_type': 'password', 'networks': []} defaults: {'api_timeout': None, 'verify': True, 'cacert': None, 'cert': None, 'key': None, 'auth_type': 'password', 'baremetal_status_code_retries': 5, 'baremetal_introspection_status_code_retries': 5, 'image_status_code_retries': 5, 'disable_vendor_agent': {}, 'interface': None, 'floating_ip_source': 'neutron', 'image_api_use_tasks': False, 'image_format': 'qcow2', 'message': '', 'network_api_version': '2', 'object_store_api_version': '1', 'secgroup_source': 'neutron', 'status': 'active'} cloud cfg: {'api_timeout': None, 'verify': True, 'cacert': None, 'cert': None, 'key': None, 'baremetal_status_code_retries': '5', 'baremetal_introspection_status_code_retries': '5', 'image_status_code_retries': '5', 'disable_vendor_agent': {}, 'interface': 'public', 'floating_ip_source': 'neutron', 'image_api_use_tasks': False, 'image_format': 'qcow2', 'message': '', 'network_api_version': '2', 'object_store_api_version': '1', 'secgroup_source': 'neutron', 'status': 'active', 'auth': {'user_domain_name': 'Default', 'project_domain_id': 'default', 'project_id': '0e75229392c54a398ab302a8e43aebe6', 'project_name': 'admin'}, 'verbose_level': 3, 'deferred_help': False, 'debug': True, 'region_name': 'RegionOne', 'default_domain': 'default', 'timing': False, 'username': 'admin', 'password': '***', 'auth_url': ' http://10.200.134.218:5000/v3', 'beta_command': False, 'identity_api_version': '3', 'orchestration_api_version': '1', 'auth_type': 'password', 'networks': []} compute API version 2.1, cmd group openstack.compute.v2 identity API version 3, cmd group openstack.identity.v3 image API version 2, cmd group openstack.image.v2 network API version 2, cmd group openstack.network.v2 object_store API version 1, cmd group openstack.object_store.v1 volume API version 3, cmd group openstack.volume.v3 orchestration API version 1, cmd group openstack.orchestration.v1 command: stack list -> heatclient.osc.v1.stack.ListStack (auth=True) Auth plugin password selected auth_config_hook(): {'api_timeout': None, 'verify': True, 'cacert': None, 'cert': None, 'key': None, 'baremetal_status_code_retries': '5', 'baremetal_introspection_status_code_retries': '5', 'image_status_code_retries': '5', 'disable_vendor_agent': {}, 'interface': 'public', 'floating_ip_source': 'neutron', 'image_api_use_tasks': False, 'image_format': 'qcow2', 'message': '', 'network_api_version': '2', 'object_store_api_version': '1', 'secgroup_source': 'neutron', 'status': 'active', 'auth': {'user_domain_name': 'Default', 'project_domain_id': 'default', 'project_id': '0e75229392c54a398ab302a8e43aebe6', 'project_name': 'admin'}, 'additional_user_agent': [('osc-lib', '2.3.1')], 'verbose_level': 3, 'deferred_help': False, 'debug': True, 'region_name': 'RegionOne', 'default_domain': 'default', 'timing': False, 'username': 'admin', 'password': '***', 'auth_url': 'http://10.200.134.218:5000/v3', 'beta_command': False, 'identity_api_version': '3', 'orchestration_api_version': '1', 'auth_type': 'password', 'networks': []} Using auth plugin: password Using parameters {'auth_url': 'http://10.200.134.218:5000/v3', 'project_id': '0e75229392c54a398ab302a8e43aebe6', 'project_name': 'admin', 'project_domain_id': 'default', 'username': 'admin', 'user_domain_name': 'Default', 'password': '***'} Get auth_ref REQ: curl -g -i -X GET http://10.200.134.218:5000/v3 -H "Accept: application/json" -H "User-Agent: openstacksdk/0.55.0 keystoneauth1/4.3.1 python-requests/2.25.1 CPython/3.6.8" Starting new HTTP connection (1): 10.200.134.218:5000 http://10.200.134.218:5000 "GET /v3 HTTP/1.1" 200 254 RESP: [200] Connection: close Content-Length: 254 Content-Security-Policy: default-src 'self' https: wss:; Content-Type: application/json Date: Thu, 29 Apr 2021 05:26:21 GMT Server: nginx/1.18.0 Vary: X-Auth-Token X-Content-Type-Options: nosniff X-Frame-Options: DENY X-XSS-Protection: 1; mode=block x-openstack-request-id: req-5e95ffe0-5fde-4234-9e7c-f79287e539a0 RESP BODY: {"version": {"id": "v3.14", "status": "stable", "updated": "2020-04-07T00:00:00Z", "links": [{"rel": "self", "href": " http://10.200.134.218:5000/v3/"}], "media-types": [{"base": "application/json", "type": "application/vnd.openstack.identity-v3+json"}]}} GET call to http://10.200.134.218:5000/v3 used request id req-5e95ffe0-5fde-4234-9e7c-f79287e539a0 Making authentication request to http://10.200.134.218:5000/v3/auth/tokens Resetting dropped connection: 10.200.134.218 http://10.200.134.218:5000 "POST /v3/auth/tokens HTTP/1.1" 201 6037 {"token": {"methods": ["password"], "user": {"domain": {"id": "default", "name": "Default"}, "id": "b3c6351eb7d841678297401969eb01c7", "name": "admin", "password_expires_at": null}, "audit_ids": ["-pXpoN1cRyS5ioGPNOEdkg"], "expires_at": "2021-04-29T17:26:22.000000Z", "issued_at": "2021-04-29T05:26:22.000000Z", "project": {"domain": {"id": "default", "name": "Default"}, "id": "0e75229392c54a398ab302a8e43aebe6", "name": "admin"}, "is_domain": false, "roles": [{"id": "5123dc78efec436dad719099e4979536", "name": "admin"}, {"id": "6ddb974942354b53a6cc1dfe10cc58a9", "name": "member"}, {"id": "24de7013b1124fcd99c31482ede6a855", "name": "reader"}], "catalog": [{"endpoints": [{"id": "9ef24c86cb5e49f6aecb882adfe8b8be", "interface": "admin", "region_id": "RegionOne", "url": "http://172.29.236.100:5000", "region": "RegionOne"}, {"id": "c43060c06da940ab9c9de47d96efca5f", "interface": "internal", "region_id": "RegionOne", "url": " http://172.29.236.100:5000", "region": "RegionOne"}, {"id": "ff7a8af4a859400584fc2f4025f8110a", "interface": "public", "region_id": "RegionOne", "url": "http://10.200.134.218:5000", "region": "RegionOne"}], "id": "0177ada716b8496390b53f88de002762", "type": "identity", "name": "keystone"}, {"endpoints": [{"id": "01dcd05263a5499a9222459614c19099", "interface": "admin", "region_id": "RegionOne", "url": " http://172.29.236.100:8776/v2/0e75229392c54a398ab302a8e43aebe6", "region": "RegionOne"}, {"id": "8f8d9172c7b94baf8971d6fce50c3c22", "interface": "public", "region_id": "RegionOne", "url": " http://10.200.134.218:8776/v2/0e75229392c54a398ab302a8e43aebe6", "region": "RegionOne"}, {"id": "abe2895da1fc47e2a795136a0f154dad", "interface": "internal", "region_id": "RegionOne", "url": " http://172.29.236.100:8776/v2/0e75229392c54a398ab302a8e43aebe6", "region": "RegionOne"}], "id": "2a8111a2e7224baaa928ba19545754cd", "type": "volumev2", "name": "cinderv2"}, {"endpoints": [{"id": "027033523daf4adc8d1a180e41f57c00", "interface": "admin", "region_id": "RegionOne", "url": " http://172.29.236.100:8004/v1/0e75229392c54a398ab302a8e43aebe6", "region": "RegionOne"}, {"id": "765c7ea8a9c4456bb23ba5d519ffa033", "interface": "internal", "region_id": "RegionOne", "url": " http://172.29.236.100:8004/v1/0e75229392c54a398ab302a8e43aebe6", "region": "RegionOne"}, {"id": "f3a264f72c0a4960b9740e466eb52d83", "interface": "public", "region_id": "RegionOne", "url": " http://10.200.134.218:8004/v1/0e75229392c54a398ab302a8e43aebe6", "region": "RegionOne"}], "id": "31803d9d7a3e4d4e92d9522459526a68", "type": "orchestration", "name": "heat"}, {"endpoints": [{"id": "1183338890744524b28c274ca61e93ff", "interface": "admin", "region_id": "RegionOne", "url": "http://172.29.236.100:8780", "region": "RegionOne"}, {"id": "21bcc1ebb4de44d2931f0220d6fa1576", "interface": "internal", "region_id": "RegionOne", "url": "http://172.29.236.100:8780", "region": "RegionOne"}, {"id": "70f912ca1dc44c3a826e987d1ea9f5b4", "interface": "public", "region_id": "RegionOne", "url": "http://10.200.134.218:8780", "region": "RegionOne"}], "id": "5c4974e041d34241bc7edf17f8ce07ae", "type": "placement", "name": "placement"}, {"endpoints": [{"id": "3c105203c90845d0a523f34cf6bc037b", "interface": "public", "region_id": "RegionOne", "url": "http://10.200.134.218:8000/v1", "region": "RegionOne"}, {"id": "cf77bee702da43d68aee3863d4fa68f0", "interface": "internal", "region_id": "RegionOne", "url": "http://172.29.236.100:8000/v1", "region": "RegionOne"}, {"id": "deda0fe9872d472e8ad04bf9cf65caab", "interface": "admin", "region_id": "RegionOne", "url": " http://172.29.236.100:8000/v1", "region": "RegionOne"}], "id": "675d604be05245e38156198a2e0c955c", "type": "cloudformation", "name": "heat-cfn"}, {"endpoints": [{"id": "0f358e9c8a9e4d4aa87ba5827c5612a7", "interface": "public", "region_id": "RegionOne", "url": " http://10.200.134.218:9696", "region": "RegionOne"}, {"id": "e0fda98441e442ad84ad9638b97fb5a9", "interface": "admin", "region_id": "RegionOne", "url": "http://172.29.236.100:9696", "region": "RegionOne"}, {"id": "f63223fe921a44e48fffaa90a22619b2", "interface": "internal", "region_id": "RegionOne", "url": "http://172.29.236.100:9696", "region": "RegionOne"}], "id": "679d6c52473b4b87867b0839238a2533", "type": "network", "name": "neutron"}, {"endpoints": [{"id": "04618143b8764565bd1f292c481ec9fc", "interface": "internal", "region_id": "RegionOne", "url": "http://172.29.236.100:9292", "region": "RegionOne"}, {"id": "131339c1c9564d0d9f0cfdf6311c2893", "interface": "admin", "region_id": "RegionOne", "url": "http://172.29.236.100:9292", "region": "RegionOne"}, {"id": "f0725b46e74549d1b3d58efaa46dbf02", "interface": "public", "region_id": "RegionOne", "url": "http://10.200.134.218:9292", "region": "RegionOne"}], "id": "df050da4381c4209968693e4aca92da5", "type": "image", "name": "glance"}, {"endpoints": [{"id": "7cb5429849d741238e31f929132b224d", "interface": "admin", "region_id": "RegionOne", "url": "http://172.29.236.100:8774/v2.1", "region": "RegionOne"}, {"id": "ab640e3d4ccf4d66832b0d2d38f30be9", "interface": "internal", "region_id": "RegionOne", "url": " http://172.29.236.100:8774/v2.1", "region": "RegionOne"}, {"id": "d707d5092628423397cb02a46cb1deca", "interface": "public", "region_id": "RegionOne", "url": "http://10.200.134.218:8774/v2.1", "region": "RegionOne"}], "id": "e807659ac4f74b78805b0f9e605081f0", "type": "compute", "name": "nova"}, {"endpoints": [{"id": "152f11cd02de47069bb7fee11954395d", "interface": "public", "region_id": "RegionOne", "url": " http://10.200.134.218:8776/v3/0e75229392c54a398ab302a8e43aebe6", "region": "RegionOne"}, {"id": "71b96d9f9b994d72bf21c10810a532f9", "interface": "admin", "region_id": "RegionOne", "url": " http://172.29.236.100:8776/v3/0e75229392c54a398ab302a8e43aebe6", "region": "RegionOne"}, {"id": "935b1c8e4da547ca891334fe476291b6", "interface": "internal", "region_id": "RegionOne", "url": " http://172.29.236.100:8776/v3/0e75229392c54a398ab302a8e43aebe6", "region": "RegionOne"}], "id": "ff62f9bcded14444bbb4f1e1cdcaf60b", "type": "volumev3", "name": "cinderv3"}]}} run(Namespace(all_projects=False, columns=[], deleted=False, fit_width=False, formatter='table', hidden=False, limit=None, long=False, marker=None, max_width=0, nested=False, noindent=False, print_empty=False, properties=None, quote_mode='nonnumeric', short=False, sort=None, sort_columns=[], sort_direction=None, tag_mode=None, tags=None)) take_action(Namespace(all_projects=False, columns=[], deleted=False, fit_width=False, formatter='table', hidden=False, limit=None, long=False, marker=None, max_width=0, nested=False, noindent=False, print_empty=False, properties=None, quote_mode='nonnumeric', short=False, sort=None, sort_columns=[], sort_direction=None, tag_mode=None, tags=None)) Instantiating orchestration client: <class 'heatclient.v1.client.Client'> REQ: curl -g -i -X GET http://10.200.134.218:8004/v1/0e75229392c54a398ab302a8e43aebe6/stacks? -H "Accept: application/json" -H "Content-Type: application/json" -H "User-Agent: python-heatclient" -H "X-Auth-Token: {SHA256}a0ae405fe8fdb29acbcc65b1ce4feb9a304448592d6a8ae982955e903f45f3c0" -H "X-Region-Name: RegionOne" Starting new HTTP connection (1): 10.200.134.218:8004 http://10.200.134.218:8004 "GET /v1/0e75229392c54a398ab302a8e43aebe6/stacks HTTP/1.1" 503 None RESP: [503] Cache-Control: no-cache Connection: close Content-Type: text/html RESP BODY: Omitted, Content-Type is set to text/html. Only application/json responses have their bodies logged. ERROR: b'<html><body><h1>503 Service Unavailable</h1>\nNo server is available to handle this request.\n</body></html>\n' Traceback (most recent call last): File "/usr/local/lib/python3.6/site-packages/cliff/app.py", line 401, in run_subcommand result = cmd.run(parsed_args) File "/usr/local/lib/python3.6/site-packages/osc_lib/command/command.py", line 39, in run return super(Command, self).run(parsed_args) File "/usr/local/lib/python3.6/site-packages/cliff/display.py", line 115, in run column_names, data = self.take_action(parsed_args) File "/usr/local/lib/python3.6/site-packages/heatclient/osc/v1/stack.py", line 577, in take_action return _list(client, args=parsed_args) File "/usr/local/lib/python3.6/site-packages/heatclient/osc/v1/stack.py", line 691, in _list data = list(data) File "/usr/local/lib/python3.6/site-packages/heatclient/v1/stacks.py", line 136, in paginate stacks = self._list(url, 'stacks') File "/usr/local/lib/python3.6/site-packages/heatclient/common/base.py", line 114, in _list body = self.client.get(url).json() File "/usr/local/lib/python3.6/site-packages/keystoneauth1/adapter.py", line 395, in get return self.request(url, 'GET', **kwargs) File "/usr/local/lib/python3.6/site-packages/heatclient/common/http.py", line 323, in request raise exc.from_response(resp) heatclient.exc.HTTPServiceUnavailable: ERROR: b'<html><body><h1>503 Service Unavailable</h1>\nNo server is available to handle this request.\n</body></html>\n' clean_up ListStack: ERROR: b'<html><body><h1>503 Service Unavailable</h1>\nNo server is available to handle this request.\n</body></html>\n' END return value: 1 Warm Regards, Premkumar Subramaniyan Technical staff M: +91 9940743669 *CRN Top 10 Coolest Edge Computing Startups of 2020 <https://www.crn.com/slide-shows/networking/the-10-coolest-edge-computing-st…>*

5 11

[Ussuri][neutron] How to accomplish what allow_same_net_traffic did
by Eugen Block 04 May '21

04 May '21

Hi *, I was wondering how other operators deal with this. Our cloud started somewhere in Kilo or Liberty version and in older versions the option allow_same_net_traffic allowed to control whether instances in our shared network could connect to each other between different projects. That option worked for us but is now deprecated and the Pike release notes [1] state: > Given that there are other better documented and better tested ways > to approach this, such as through use of neutron’s native port > filtering or security groups, this functionality has been removed. > > Users should instead rely on one of these alternatives. Does that mean all security groups need to be changed in a way that this specific shared network is not reachable? That would be a lot of work if you have many projects. Is there any easier way? Regards, Eugen [1] https://docs.openstack.org/releasenotes/nova/pike.html

2 2

[ironic] Announcing deprecation of the iSCSI deploy interface
by Dmitry Tantsur 04 May '21

04 May '21

Hi all, Following up to the previous mailing list [1] and virtual meetup [2] discussions, I would like to announce the plans to deprecate the 'iscsi' deploy interface. This is the updated plan discussed on the virtual meetup: 1) In the Victoria cycle (i.e. right now): - Fill in the detected feature gaps [3]. - Switch off the iscsi deploy interface by default. - Change [agent]image_dowload_source to HTTP by default. - Give the direct deploy a higher priority, so that it's used by default unless disabled. - Mark it as deprecated in the code (causing warnings when enabled). - Release a major version of ironic to highlight the defaults changes. 2) In the W cycle: - Keep the iscsi deploy deprecated. - Listen to operators' feedback. 3) In the X cycle - Remove the iscsi deploy completely from ironic and IPA. - Remove support code from ironic-lib with a major version bump. Please let us know if you have any questions or concerns. Dmitry [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016681.h… [2] https://etherpad.opendev.org/p/Ironic-Victoria-midcycle [3] https://storyboard.openstack.org/#!/story/2008075 -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

1 1

[ptg] Summaries blogpost
by helena＠openstack.org 03 May '21

03 May '21

Hello everyone! Congrats to everyone on an awesome PTG week and thank you to everyone who submitted project recaps via the mailing list. I have collected all the posts and linked them to this blog post [1]. If you would still like to add a project summary feel free to reach out and I can get that added. Cheers, Helena [1] [ https://www.openstack.org/blog/xena-vptg-summaries/ ]( https://www.openstack.org/blog/xena-vptg-summaries/ )

2 1

[neutron] CI meeting 4.05.2021 cancelled
by Slawek Kaplonski 03 May '21

03 May '21

Hi, Sorry for the late notice but I'm on PTO today and I will not be able to chair our team meeting so let's cancel it this week. -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[neutron] Team meeting 4.05.2021 cancelled
by Slawek Kaplonski 03 May '21

03 May '21

Hi, Sorry for the late notice but I'm on PTO today and I will not be able to chair our team meeting so let's cancel it this week. -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[all][tc] What's happening in Technical Committee: summary 30th April, 21: Reading: 5 min
by Ghanshyam Mann 03 May '21

03 May '21

Hello Everyone, Here is last week's summary of the Technical Committee activities, Sorry for missing to send this on Friday 30th April. 1. What we completed this week: ========================= Project updates: ------------------- ** None Other updates: ------------------ ** Updated TC onboarding guide for correcting the meeting times etc[1]. 2. TC Meetings: ============ * TC held this week meeting on Thursday; you can find the full meeting logs in the below link: - http://eavesdrop.openstack.org/meetings/tc/2021/tc.2021-04-29-15.00.log.html * We will have next week's meeting on May 6th, Thursday 15:00 UTC[2]. 3. Activities In progress: ================== TC Tracker for Xena cycle ------------------------------ TC is using the below etherpad for Xena cycle working item. We will be checking and updating the status biweekly in same etherpad. - https://etherpad.opendev.org/p/tc-xena-tracker Open Reviews ----------------- * Four open reviews for ongoing activities[3]. Starting the 'Y' release naming process --------------------------------------------- * Governance patch is up to finalize the dates for Y release naming process[4] * https://wiki.openstack.org/wiki/Release_Naming/Y_Proposals Others --------- * Swift and Ironic applying for "assert:supports-standalone" tag * Reduce office hours to one per week[5] * Update Nodejs Runtime to Nodejs14 From Nodejs10 for Xena Cycle[6] PTG ----- TC had discussions on various topics in virtual PTG. I have summarized the PTG discussion on ML[7]. 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[8]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [9] 3. Office hours: The Technical Committee offers a weekly office hour every Tuesday at 0100 UTC [10] 4. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://governance.openstack.org/tc/reference/tc-guide.html [2] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [3] https://review.opendev.org/q/project:openstack/governance+status:open [4] https://review.opendev.org/c/openstack/governance/+/789385 [5] https://review.opendev.org/c/openstack/governance/+/788618 [6] https://review.opendev.org/c/openstack/governance/+/788306 [7] http://lists.openstack.org/pipermail/openstack-discuss/2021-April/022120.ht… [8] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [9] http://eavesdrop.openstack.org/#Technical_Committee_Meeting [10] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours -gmann

1 0

[openstack-helm] Meeting Cancelled
by Gage Hugo 03 May '21

03 May '21

Hey team, Since there are no agenda items [0] for the IRC meeting today May 4th, the meeting is cancelled. Our next meeting will be May 11th. Thanks [0] https://etherpad.opendev.org/p/openstack-helm-weekly-meeting

1 0

[CloudKitty] April 2021 - PTG Summary
by Rafael Weingärtner 03 May '21

03 May '21

Hello, CloudKitty community, Below is my summary of the CloudKitty session during the PTG meeting in April. - CloudKitty community -- we started discussing the CloudKitty community and how to get more people engaged with the project. If we were having physical summits, it would be easier to onboard people. However, that is not our case right now. Therefore, we agreed that if we improve the user stories of CloudKitty showcasing different use cases might help increase people's awareness. These use cases could be added to the following page: https://docs.openstack.org/cloudkitty/latest/#what-can-be-done-with-cloudki…. Furthermore, we also agreed to monitor Storyboard more: https://storyboard.openstack.org/#!/project_group/cloudkitty, to engage with people reporting bugs. - Review of past releases -- after discussing the CloudKitty community, we moved on to revisit the past release (Wallaby). We agreed that it might be interesting to add more effort to merge things at the beginning of the release cycle; then, we work from the middle to the end to stabilize things. This would allow/enable us to add more new features and bug fixes into the release. - CloudKitty Next release main focus -- we discussed that besides the already ongoing efforts to fix bugs, and create new features, we will try to work towards the following new features: - Reprocessing API - Reprocessing with data still on Backend - Reprocessing without data on the backend (for cases when the data has already been deleted) will not be addressed now. - V2 CI testing: https://review.opendev.org/c/openstack/cloudkitty-tempest-plugin/+/685344 - Date to start a new price for a metric Those are the main topics we covered during the PTG. If I forgot something, please let me know. Now, we just gotta work to keep evolving this awesome billing stack :) Link for the PTG Etherpad: https://etherpad.opendev.org/p/apr2021-ptg-cloudkitty -- Rafael Weingärtner

1 0

[charms] OpenStack Charms 21.04 release is now available
by Peter Matulis 03 May '21

03 May '21

The 21.04 release of the OpenStack Charms is now available. This release brings several new features to the existing OpenStack Charms deployments for Queens, Stein, Ussuri, Victoria, Wallaby and many stable combinations of Ubuntu + OpenStack. Please see the Release Notes for full details: https://docs.openstack.org/charm-guide/latest/2104.html == Highlights == * OpenStack Wallaby OpenStack Wallaby is now supported on Ubuntu 20.04 LTS (via UCA) and Ubuntu 21.04 natively. * Ceph Pacific The Pacific release of Ceph is now supported, starting with OpenStack Wallaby. * Denying service restarts and charm hook calls The deferred service events feature can be enabled on a per-charm basis to avoid sudden service interruptions caused by maintenance and operational procedures applied to the cloud. This allows operators to apply the service restarts and hook calls at their prerogative. * Cloud operational improvements Improvements have been implemented at the operational level through the addition of scaling down actions for the hacluster and nova-compute charms. It is also now possible to query a nova-compute unit's hypervisor node name, list all hypervisor node names, and mark individual Ceph OSDs as 'out' or 'in'. * Sync Juju availability zones with Nova availability zones The nova-cloud-controller charm has a new action that synchronises Juju availability zones with Nova availability zones. This effectively configures host aggregates in Nova using the AZs already known to the nova-compute application. * Tech-preview charms Two tech-preview charms are now available for the deployment of OpenStack Magnum. The list of Manila charms is also expanded by two tech-preview charms. The new charms are magnum, magnum-dashboard, manila-dashboard, and manila-netapp. * Documentation updates Ongoing improvements to the OpenStack Charms Deployment Guide, the OpenStack Charm Guide, and the charm READMEs. A central documentation presence is also now available: https://ubuntu.com/openstack/docs . == OpenStack Charms team == The OpenStack Charms team can be contacted on the #openstack-charms IRC channel on Freenode. == Thank you == Lots of thanks to the below 37 contributors who squashed 54 bugs, enabled new features, and improved the documentation! Alex Kavanagh Alvaro Uria Arif Ali Aurelien Lourot Bartosz Woronicz Bayani Carbone Billy Olsen Chris MacNaughton Corey Bryant Cornellius Metto Cory Johns Dariusz Smigiel David Ames Dmitrii Shcherbakov Edward Hope-Morley Erlon R. Felipe Reyes Frode Nordahl Garrett Thompson Hemanth Nakkina Hernan Garcia Ionut Balutoiu James Page James Vaughn Liam Young Marius Oprin Martin Kalcok Mauricio Faria Nicolas Bock Nobuto Murata Pedro Guimaraes Peter Matulis Przemysław Lal Robert Gildein Rodrigo Barbieri Seyeong Kim Yanos Angelopoulos -- OpenStack Charms Team

1 0

[wallaby][magnum] Cluster Deployment Unhealthy
by Ammad Syed 03 May '21

03 May '21

Hi, I have upgraded my magnum environment from victoria to wallaby. The upgrade went successfully. When I am trying to deploy a cluster from template, the status of cluster shows UNHEALTHY but create complete. I have logged into the master nodes and found no error message in heat logs. The nodes status still sees NotReady. [root@k8s-cluster-iomfrpuadezp-master-0 kubernetes]# kubectl get nodes --all-namespaces NAME STATUS ROLES AGE VERSION k8s-cluster-iomfrpuadezp-master-0 NotReady master 14m v1.18.16 k8s-cluster-iomfrpuadezp-node-0 NotReady <none> 9m51s v1.18.16 Also there is no pods running in kube-system namespace. [root@k8s-cluster-iomfrpuadezp-master-0 kubernetes]# kubectl get pods --all-namespaces No resources found I have checked the logs, the flannel was deployed. + printf 'Starting to run calico-service\n' + set -e + set +x + '[' flannel = calico ']' + printf 'Finished running calico-service\n' + set -e + set +x Finished running calico-service + '[' flannel = flannel ']' + _prefix=quay.io/coreos/ + FLANNEL_DEPLOY=/srv/magnum/kubernetes/manifests/flannel-deploy.yaml + '[' -f /srv/magnum/kubernetes/manifests/flannel-deploy.yaml ']' + echo 'Writing File: /srv/magnum/kubernetes/manifests/flannel-deploy.yaml' Writing File: /srv/magnum/kubernetes/manifests/flannel-deploy.yaml ++ dirname /srv/magnum/kubernetes/manifests/flannel-deploy.yaml + mkdir -p /srv/magnum/kubernetes/manifests + set +x + '[' '' = 0 ']' + /usr/bin/kubectl apply -f /srv/magnum/kubernetes/manifests/flannel-deploy.yaml --namespace=kube-system podsecuritypolicy.policy/psp.flannel.unprivileged created clusterrole.rbac.authorization.k8s.io/flannel created clusterrolebinding.rbac.authorization.k8s.io/flannel created serviceaccount/flannel created configmap/kube-flannel-cfg created daemonset.apps/kube-flannel-ds created I tried to deploy the flannel again, but it showing unchanged. [root@k8s-cluster-iomfrpuadezp-master-0 heat-config-script]# kubectl apply -f /srv/magnum/kubernetes/manifests/flannel-deploy.yaml --namespace=kube-system podsecuritypolicy.policy/psp.flannel.unprivileged configured clusterrole.rbac.authorization.k8s.io/flannel unchanged clusterrolebinding.rbac.authorization.k8s.io/flannel unchanged serviceaccount/flannel unchanged configmap/kube-flannel-cfg unchanged daemonset.apps/kube-flannel-ds unchanged The other thing I have noticed that cluster deployment still uses old parameters of victoria like heat_agent_tag and others. Its not using latest default tags of wallaby release. I am using magnum on ubuntu 20.04. The other components in stack are already upgraded to wallaby release. -- Regards, Ammad Ali

3 3

[release] Meeting Time Poll
by Herve Beraud 03 May '21

03 May '21

Hello We have a few regular attendees of the Release Management meeting who have conflicts with the current meeting time. As a result, we would like to find a new time to hold the meeting. I've created a Doodle poll[1] for everyone to give their input on times. It's mostly limited to times that reasonably overlap the working day in the US and Europe since that's where most of our attendees are located. If you attend the Release Management meeting, please fill out the poll so we can hopefully find a time that works better for everyone. For the sake of organization and to allow everyone to schedule his agenda accordingly, the poll will be closed on April 5th. On that date, I will announce the time of this meeting and the date on which it will take effect. Thanks! [1] https://doodle.com/poll/ip6tg4fvznz7p3qx -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 5

[oslo] Stepping down as Oslo core
by Ken Giusti 03 May '21

03 May '21

Hi all, The time has come to face the fact that I'm unable to give my role as an Oslo core contributor the attention and effort it deserves. I'd say that it has been great to work will all of you - and it most certainly has - but that would be a bit premature because this isn't "good bye". I'll still be kicking around the oslo.messaging project, helping out as time permits. Cheers -- Ken Giusti (kgiusti(a)gmail.com)

3 2

[barbican][oslo][nova][glance][cinder] cursive library status
by Brian Rosmaita 03 May '21

03 May '21

Hello Barbican team, Apologies for not including barbican in the previous thread on this topic: http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019430… The situation is that cursive is used by Nova, Glance, and Cinder and we'd like to move it out of the 'x' namespace into openstack governance. The question is then what team would oversee it. It seems like a good fit for Oslo, and the Oslo team seems OK with that, but since barbican-core is currently included in cursive-core, it make sense to give the Barbican team first dibs. From the consuming teams' side, I don't think we have a preference as long as it's clear who we need to bother about approvals if a bugfix is posted for review. Thus my ask is that the Barbican team indicate whether they'd like to move cursive to the 'openstack' namespace under their governance, or whether they'd prefer Oslo to oversee the library. Thank you! brian

5 5

[ptg][cinder] xena virtual PTG summary
by Brian Rosmaita 03 May '21

03 May '21

Sorry for the delay, it's posted here: https://wiki.openstack.org/wiki/CinderXenaPTGSummary The wiki page contains links to all the recordings. cheers, brian

1 0

[release] How to create feature branch
by Artem Goncharov 03 May '21

03 May '21

Hi all, During PTG we agreed to proceed with the R1 as a feature branch for the OpenStackSDK to finally prepare the Big Bang. I have went through some documents I was able to find (namely https://docs.opendev.org/opendev/infra-manual/latest/drivers.html#branches <https://docs.opendev.org/opendev/infra-manual/latest/drivers.html#branches>) but haven’t found the working way to get it done (in Gerrit seems I lack required privileges and it is not clear now how to request those). Thus the question: what is the right way for a project to create/request a feature branch? Thanks, Artem

3 4

[neutron] Bug Deputy Report April 26 - May 3
by Lucas Alvares Gomes 03 May '21

03 May '21

Hi, This is the Neutron bug report of the week of 2021-04-26. Critical: * https://bugs.launchpad.net/neutron/+bug/1926109 - "SSH timeout (wait timeout) due to potential paramiko issue" Unassigned High: * https://bugs.launchpad.net/neutron/+bug/1926476 - "Deprecation of pyroute2.IPDB in favor of pyroute2.NDB" Assigned to: ralonsoh * https://bugs.launchpad.net/neutron/+bug/1926638 - " Neutron - "neutron-tempest-plugin-designate-scenario" gate fails all the time" Assigned to: Dr. Jens Harbott * https://bugs.launchpad.net/neutron/+bug/1926653 - "[ovn] ml2/ovn may time out connecting to ovsdb server and stays dead in the water" Assigned to: flaviof * https://bugs.launchpad.net/neutron/+bug/1926693 - " Logic to obtain hypervisor hostname is not completely compatible with libvirt" Assigned to: Takashi Kajinami * https://bugs.launchpad.net/neutron/+bug/1926780 - "Multicast traffic scenario test is failing sometimes on OVN job" Unassigned Medium: * https://bugs.launchpad.net/neutron/+bug/1926273 - "Port can be created with an invalid MAC address" Assigned to: ralonsoh * https://bugs.launchpad.net/neutron/+bug/1926417 - "ObjectChangeHandler excessive thread usage" Assigned to: Szymon Wróblewski * https://bugs.launchpad.net/neutron/+bug/1926515 - " DHCP for VM fails when removing security group default rules" Assigned to: slaweq Low: * https://bugs.launchpad.net/neutron/+bug/1926149 - " [OVN] Neutron server is filter by "subnet:segment_id", but not when OVS is used" Assigned to: ralonsoh Wishlist: * https://bugs.launchpad.net/neutron/+bug/1926787 - " [DB] Neutron quota request implementation can end in a lock status" Unassigned Needs further triage: * https://bugs.launchpad.net/neutron/+bug/1926428 - " allocate_dynamic_segment() returns different segment dicts if segment exists" Unassigned * https://bugs.launchpad.net/neutron/+bug/1926531 - " SNAT namespace prematurely created then deleted on hosts, resulting in removal of RFP/FPR link to FIP namespace" Unassigned * https://bugs.launchpad.net/neutron/+bug/1926838 - "[OVN] infinite loop in ovsdb_monitor" Unassigned

1 0

[Diversity] Diversity & Inclusion WG Meeting reminder
by Amy Marrich 30 Apr '21

30 Apr '21

The Diversity & Inclusion WG invites members of all OSF projects to our meeting Monday May 3rd, at 17:00 UTC in the #openinfra-diversity channel. The agenda can be found at https://etherpad.openstack.org/p/diversity -wg-agenda. Please feel free to add any topics you wish to discuss at the meeting. Thanks, Amy (spotz)

1 0

[interop] Weekly meeting is at Fridays 4:00pm UTC
by Kanevsky, Arkady 30 Apr '21

30 Apr '21

Every Fridays at 16:00 UTC <16:00%20UTC > on https://meetpad.opendev.org/Interop-WG-weekly-meeting Current Meeting Logs on etherpad - https://etherpad.opendev.org/p/interop Wiki is updated with the latest info. https://wiki.openstack.org/wiki/Governance/InteropWG Arkady Kanevsky, Ph.D. SP Chief Technologist & DE Dell Technologies office of CTO Dell Inc. One Dell Way, MS PS2-91 Round Rock, TX 78682, USA Phone: 512 7204955

1 0

[tripleo] removing myself from tripleo-core
by Emilien Macchi 29 Apr '21

29 Apr '21

Hi people, If you didn't notice, I am not working on TripleO anymore (as a developer, but still a heavy user) and therefore my amount of contribution and awareness in the project makes me think I shouldn't be considered a maintainer anymore. I'll remove myself from tripleo-core in Gerrit. I just want to let you know that I'm not far, I'm still on IRC and sometimes participate in the chat. I can also provide support for the crappy code that I wrote (Alex made me do it most of the time). However don't expect me to be heavily involved like it used to be the case. I just want to say that I already miss a lot working on TripleO and in OpenStack in general. The Community, the maturity of the project and all that we built is something that can't be compared to anything else out there. My focus is now "Kubernetes (OpenShift) on top of OpenStack", heavily consuming what OpenStack has to offer and connecting the two worlds. It's a lot of fun and a lot of new things to learn! But I'm sure OpenStack won't go too far away from my plate, so let's keep in touch. Take care, -- Emilien Macchi

2 1

[glance][ceph] Openstack Wallaby and Ceph Pacific- ERROR cinder.scheduler.flows.create_volume
by Tecnologia Charne.Net 29 Apr '21

29 Apr '21

Hello! I'm working with Openstack Wallaby (1 controller, 2 compute nodes) connected to Ceph Pacific cluster in a devel environment. With Openstack Victoria and Ceph Pacific (before last friday update) everything was running like a charm. Then, I upgraded Openstack to Wallaby and Ceph to version 16.2.1. (Because of auth_allow_insecure_global_id_reclaim I had to upgrade many clients... but that's another story...) After upgrade, when I try to create a volume from image, openstack volume create --image f1df058d-be99-4401-82d9-4af9410744bc debian10_volume1 --size 5 with "show_image_direct_url = True", I get "No valid backend" in /var/log/cinder/cinder-scheduler.log 2021-04-26 20:35:24.957 41348 ERROR cinder.scheduler.flows.create_volume [req-651937e5-148f-409c-8296-33f200892e48 c048e887df994f9cb978554008556546 f02ae99c34cf44fd8ab3b1fd1b3be964 - - -] Failed to run task cinder.scheduler.flows.create_volume.ScheduleCreateVolumeTask;volume:create: No valid backend was found. Exceeded max scheduling attempts 3 for resource 56fbb645-2c34-477d-9a59-beec78f4fd3f: cinder.exception.NoValidBackend: No valid backend was found. Exceeded max scheduling attempts 3 for resource 56fbb645-2c34-477d-9a59-beec78f4fd3f and 2021-04-26 20:35:24.968 41347 ERROR oslo_messaging.rpc.server [req-651937e5-148f-409c-8296-33f200892e48 c048e887df994f9cb978554008556546 f02ae99c34cf44fd8ab3b1fd 1b3be964 - - -] Exception during message handling: rbd.InvalidArgument: [errno 22] RBD invalid argument (error creating clone) in /var/log/cinder/cinder-volume.log If I disable "show_image_direct_url = False", volume creation from image works fine. I have spent the last four days googling and reading lots of docs, old and new ones, unlucly... Does anybody have a clue, (please)? Thanks in advance! Javier.-

2 2

[Cinder] Problem in iSCSI Portal
by Taha Adel 29 Apr '21

29 Apr '21

Hello, The situation is, I have one storage node that has cinder-volume service up and running on top of it and has a dedicated physical NIC for storage traffic. I have set the following configuration in /etc/cinder/cinder.conf file at the storage node: volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver volume_group = cinder-volumes target_protocol = iscsi target_helper = lioadm iscsi_ip_address = 10.0.102.11 (different than the management ip) The service is able to create the volume and attach it as a backstore for iSCSI, but it can't create a Portal for iSCSI service. Should I create the portal entry by myself? or is there a mistake I have made in the config file? Thanks in advance

2 1

Fwd: cinder + Unity
by Rajat Dhasmana 29 Apr '21

29 Apr '21

Hi Albert, On Mon, Apr 19, 2021 at 11:45 PM Albert Shih <Albert.Shih(a)obspm.fr> wrote: > Hi everyone, > > I'm a total newbie with openstack, currently I'm trying to put a POC with a > Unity storage element, 4 computes, and few servers (cinder, keystone, > glance, neutron, nova, placement and horizon). > > I think my keystone, glance, placement are working (at least they past the > test). > > Currently I'm trying to make cinder working with my Unity (480), the > objectif are to use iSCSI. > > Here the configuration of my /etc/cinder/cinder.conf > > [DEFAULT] > rootwrap_config = /etc/cinder/rootwrap.conf > api_paste_confg = /etc/cinder/api-paste.ini > iscsi_helper = tgtadm > volume_name_template = volume-%s > volume_group = cinder-volumes > verbose = True > auth_strategy = keystone > state_path = /var/lib/cinder > lock_path = /var/lock/cinder > volumes_dir = /var/lib/cinder/volumes > enabled_backends = unity > transport_url = rabbit://openstack:XXXXXX@amqp-cloud.private.FQDN > /openstack > auth_strategy = keystone > debug = True > verbose = True > > [database] > connection = mysql+pymysql://cinder:XXXXXXX@mariadb-cloud.private.FQDN > /cinder > > [keystone_authtoken] > www_authenticate_uri = http://keystone.private.FQDN:5000/v3 > auth_url = http://keystone.private.FQDN:5000 > identity_uri = http://keystone.private.FQDN:5000 > memcached_servers = memcached-cloud.private.FQDN:11211 > auth_type = password > project_domain_name = default > user_domain_name = default > project_name = service > username = cinder > password = XXXXXX > > [oslo_concurrency] > lock_path = /var/lib/cinder/tmp > > [unity] > # Storage protocol > storage_protocol = iSCSI > # Unisphere IP > san_ip = onering-remote.FQDN > # Unisphere username and password > san_login = openstack > san_password = "XXXXX" > # Volume driver name > volume_driver = cinder.volume.drivers.dell_emc.unity.Driver > # backend's name > volume_backend_name = Unitiy_ISCSI > This might be something to look at with the wrong spelling causing mismatch. > unity_io_ports = *_enp1s0 > unity_storage_pool_names = onering > > When I'm trying to create a storage through a > > openstack volume create volumetest --type thick_volume_type --size 100 > > I don't even see (with tcpdump) the cinder server trying to connect to > > onering-remote.FQDN > > Inside my /var/log/cinder/cinder-scheduler.log I have > > 2021-04-19 18:06:56.805 21315 INFO cinder.scheduler.base_filter > [req-4808cc9d-b9c3-44cb-8cae-7503db0b0256 f5e5c9ea20064b17851f07c276d71aee > b1d58ebae6b84f7586ad63b94203d7ae - - -] Filtering removed all hosts for the > request with volume ID '06e5f07d-766f-4d07-b3bf-6153a2cf6abd'. Filter > results: AvailabilityZoneFilter: (start: 0, end: 0), CapacityFilter: > (start: 0, end: 0), CapabilitiesFilter: (start: 0, end: 0) > This log mentions that no host is valid to pass the 3 filters in the scheduler. > 2021-04-19 18:06:56.806 21315 WARNING cinder.scheduler.filter_scheduler > [req-4808cc9d-b9c3-44cb-8cae-7503db0b0256 f5e5c9ea20064b17851f07c276d71aee > b1d58ebae6b84f7586ad63b94203d7ae - - -] No weighed backend found for volume > with properties: {'id': '5f16fc1f-76ff-41ee-8927-56925cf7b00f', 'name': > 'thick_volume_type', 'description': None, 'is_public': True, 'projects': > [], 'extra_specs': {'provisioning:type': 'thick', > 'thick_provisioning_support': 'True'}, 'qos_specs_id': None, 'created_at': > '2021-04-19T15:07:09.000000', 'updated_at': None, 'deleted_at': None, > 'deleted': False} > 2021-04-19 18:06:56.806 21315 INFO cinder.message.api > [req-4808cc9d-b9c3-44cb-8cae-7503db0b0256 f5e5c9ea20064b17851f07c276d71aee > b1d58ebae6b84f7586ad63b94203d7ae - - -] Creating message record for > request_id = req-4808cc9d-b9c3-44cb-8cae-7503db0b0256 > 2021-04-19 18:06:56.811 21315 ERROR cinder.scheduler.flows.create_volume > [req-4808cc9d-b9c3-44cb-8cae-7503db0b0256 f5e5c9ea20064b17851f07c276d71aee > b1d58ebae6b84f7586ad63b94203d7ae - - -] Failed to run task > cinder.scheduler.flows.create_volume.ScheduleCreateVolumeTask;volume:create: > No valid backend was found. No weighed backends available: > cinder.exception.NoValidBackend: No valid backend was found. No weighed > backends available > > > It seem (for me) cinder don't try to use unity.... > > The cinder-volume service is responsible for communicating with the backend and this create request fails on scheduler only, hence no sign of it. > Any help ? > > Regards > > Looking at the scheduler logs, there are a few things you can check: 1) execute ``cinder-manage service list`` command and check the status of cinder-volume service if it's active or not. If it shows an X sign then check in cinder-volume logs for any startup failure. 2) Check the volume type properties and see if ``volume_backend_name`` is set to the right value i.e. Unitiy_ISCSI (which looks suspicious because the spelling is wrong and there might be a mismatch somewhere) Also it's good to mention the openstack version you're using since the code changes every cycle and it's hard to track the issues with every release. Thanks and regards Rajat Dhasmana > > -- > Albert SHIH > Observatoire de Paris > Heure local/Local time: > Mon Apr 19 08:01:37 PM CEST 2021 > >

3 2

[release] Release countdown for week R-23, April 26-30
by Herve Beraud 29 Apr '21

29 Apr '21

Welcome back to the release countdown emails! These will be sent at major points in the Xena development cycle, which should conclude with a final release on 06 October, 2021. Development Focus ----------------- At this stage in the release cycle, focus should be on planning the Xena development cycle, assessing Xena community goals and approving Xena specs. General Information ------------------- Xena is a 25 weeks development cycle. In case you haven't seen it yet, please take a look over the schedule for this release: https://releases.openstack.org/xena/schedule.html By default, the team PTL is responsible for handling the release cycle and approving release requests. This task can (and probably should) be delegated to release liaisons. Now is a good time to review release liaison information for your team and make sure it is up to date: https://opendev.org/openstack/releases/src/branch/master/data/release_liais… By default, all your team deliverables from the Xena release are continued in Xena with a similar release model. Upcoming Deadlines & Dates -------------------------- Xena-1 milestone: 27 May, 2021 Hervé Beraud and the Release Management team -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 0

[oslo] Team meetings updates for Xena
by Herve Beraud 29 Apr '21

29 Apr '21

Hi Osloers, Please notice the following updates concerning the team's meetings during Xena. Meetings are now scheduled the first and the third Monday of each month. No longer weekly meetings. Meeting's courtesy ping list will be updated soon for Xena. If you want to continue to be called at the beginning of each meeting please add you nick here: https://wiki.openstack.org/wiki/Meetings/Oslo#Xena_Courtesy_Ping Thanks for your attention. -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 0

An compute service hang issue
by Yingji Sun 29 Apr '21

29 Apr '21

Buddies, Have you ever met such issue that the nova-compute service looks hanging there and not able to boot instance? When creating an instance, we can only see logs like below and there is NOT any information. 2021-04-23 02:39:00.252 1 DEBUG nova.compute.manager [req-a2ed90b6-792f-48e1-ba7f-e1e35d9537c2 373cb863547407cf3b99034b3b66395e76c137b40f905e7a61e25b1f97df4f3e 1ee7955a2eaf4c86bcc3e650f2a8e2a7 - fc86abb50a684911a30f7955d386a3ea fc86abb50a684911a30f7955d386a3ea] [instance: e0e77edc-99b4-473e-b318-8e6f04428cda] Starting instance... _do_build_and_run_instance /usr/lib/python3.7/site-packages/nova/compute/manager.py:2202^[[00m 2021-04-23 03:03:04.927 1 DEBUG oslo_concurrency.lockutils [req-50659582-ad9b-4c17-bbb2-254d5e1141f9 373cb863547407cf3b99034b3b66395e76c137b40f905e7a61e25b1f97df4f3e 1ee7955a2eaf4c86bcc3e650f2a8e2a7 - fc86abb50a684911a30f7955d386a3ea fc86abb50a684911a30f7955d386a3ea] Lock "a3619b50-3704-4f3e-b908-d525a41756eb" acquired by "nova.compute.manager.ComputeManager.build_and_run_instance.<locals>._locked_do_build_and_run_instance" :: waited 0.001s inner /usr/lib/python3.7/site-packages/oslo_concurrency/lockutils.py:327 There is NO other messages, including the periodically tasks. If I sent a request to create another instance, I can only see another _do_build_and_run_instance log. 2021-04-23 03:03:05.061 1 DEBUG nova.compute.manager [req-50659582-ad9b-4c17-bbb2-254d5e1141f9 373cb863547407cf3b99034b3b66395e76c137b40f905e7a61e25b1f97df4f3e 1ee7955a2eaf4c86bcc3e650f2a8e2a7 - fc86abb50a684911a30f7955d386a3ea fc86abb50a684911a30f7955d386a3ea] [instance: a3619b50-3704-4f3e-b908-d525a41756eb] Starting instance... _do_build_and_run_instance /usr/lib/python3.7/site-packages/nova/compute/manager.py:2202^[[00m 2021-04-23 03:32:44.718 1 DEBUG oslo_concurrency.lockutils [req-c7857cb3-02ae-4c7b-92d7-b2ec178c1b13 373cb863547407cf3b99034b3b66395e76c137b40f905e7a61e25b1f97df4f3e 1ee7955a2eaf4c86bcc3e650f2a8e2a7 - fc86abb50a684911a30f7955d386a3ea fc86abb50a684911a30f7955d386a3ea] Lock "3b07a6eb-12bb-4d19-9302-25ea3e746944" acquired by "nova.compute.manager.ComputeManager.build_and_run_instance.<locals>._locked_do_build_and_run_instance" :: waited 0.001s inner /usr/lib/python3.7/site-packages/oslo_concurrency/lockutils.py:327 I am sure the compute service is still running as I can see the heart-beat time changes correctly. From the rabbitmq message, It looks the code goes here nova/compute/manager.py def _build_and_run_instance(self, context, instance, image, injected_files, admin_password, requested_networks, security_groups, block_device_mapping, node, limits, filter_properties, request_spec=None): image_name = image.get('name') self._notify_about_instance_usage(context, instance, 'create.start', extra_usage_info={'image_name': image_name}) compute_utils.notify_about_instance_create( context, instance, self.host, phase=fields.NotificationPhase.START, bdms=block_device_mapping) as I can see a message with "event_type": "compute.instance.create.start" INFO:root:Body: {'oslo.version': '2.0', 'oslo.message': '{"message_id": "0ef11509-7a65-46b8-ac7e-ed6482fc527d", "publisher_id": "compute.compute01", "event_type": "compute.instance.create.start", "priority": "INFO", "payload": {"tenant_id": "1ee7955a2eaf4c86bcc3e650f2a8e2a7", "user_id": "373cb863547407cf3b99034b3b66395e76c137b40f905e7a61e25b1f97df4f3e", "instance_id": "3b07a6eb-12bb-4d19-9302-25ea3e746944", "display_name": "yingji-06", "reservation_id": "r-f8iphdcf", "hostname": "yingji-06", "instance_type": "m1.tiny", "instance_type_id": 15, "instance_flavor_id": "4d5644e1-c561-4b6c-952c-f4dd93c87948", "architecture": null, "memory_mb": 512, "disk_gb": 1, "vcpus": 1, "root_gb": 1, "ephemeral_gb": 0, "host": null, "node": null, "availability_zone": "nova", "cell_name": "", "created_at": "2021-04-23 03:32:39+00:00", "terminated_at": "", "deleted_at": "", "launched_at": "", "image_ref_url": "https://192.168.111.160:9292//images/303a325f-048 This issue is not always reproducible and restarting the compute service can work around this. Could you please give any suggestion on how to resolve this issue or how I can investigate ? Yingji.

2 5

[neutron] Drivers meeting agenda - 30.04.2021
by Slawek Kaplonski 28 Apr '21

28 Apr '21

Hi, Agenda for our tomorrow's drivers meeting is available at https://wiki.openstack.org/wiki/ Meetings/NeutronDrivers[1] We have 1 RFE to discuss: - https://bugs.launchpad.net/neutron/+bug/1922716[2] It was already discussed briefly during the PTG last week but let's get it official during the drivers meeting :) Have a great day and see You all tomorrow. -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers [2] https://bugs.launchpad.net/neutron/+bug/1922716

1 0

[wallaby][trove] MySQL 8.0 Support
by Ammad Syed 28 Apr '21

28 Apr '21

Hi, I am using trove wallaby release and trying to create a database instance with MySQL 8.0. I have created a mysql datastore version 8.0. The instance deployment failed with ERROR. Digging it further in guest agent logs, it is found that MySQL 8.0 container is not booting up and getting failed with below errors. 2021-04-28 09:35:27+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.0.24-1debian10 started. 2021-04-28T09:35:28.496216Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.24) starting as process 1 2021-04-28T09:35:28.574978Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started. 2021-04-28T09:35:29.318823Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended. mysqld: Table 'mysql.plugin' doesn't exist 2021-04-28T09:35:29.566920Z 0 [ERROR] [MY-010735] [Server] Could not open the mysql.plugin table. Please perform the MySQL upgrade procedure. 2021-04-28T09:35:29.568058Z 0 [Warning] [MY-010441] [Server] Failed to open optimizer cost constant tables 2021-04-28T09:35:29.569103Z 0 [Warning] [MY-010441] [Server] Failed to open optimizer cost constant tables 2021-04-28T09:35:29.570029Z 0 [Warning] [MY-010441] [Server] Failed to open optimizer cost constant tables 2021-04-28T09:35:29.570986Z 0 [Warning] [MY-010441] [Server] Failed to open optimizer cost constant tables 2021-04-28T09:35:29.571894Z 0 [Warning] [MY-010441] [Server] Failed to open optimizer cost constant tables 2021-04-28T09:35:29.572835Z 0 [Warning] [MY-010441] [Server] Failed to open optimizer cost constant tables 2021-04-28T09:35:29.573939Z 0 [Warning] [MY-010441] [Server] Failed to open optimizer cost constant tables 2021-04-28T09:35:29.576559Z 0 [System] [MY-011323] [Server] X Plugin ready for connections. Bind-address: '::' port: 33060, socket: /var/run/mysqld/mysqlx.sock 2021-04-28T09:35:29.665764Z 0 [Warning] [MY-010015] [Repl] Gtid table is not ready to be used. Table 'mysql.gtid_executed' cannot be opened. 2021-04-28T09:35:29.705075Z 0 [Warning] [MY-010015] [Repl] Gtid table is not ready to be used. Table 'mysql.gtid_executed' cannot be opened. 2021-04-28T09:35:29.718900Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed. 2021-04-28T09:35:29.719698Z 0 [System] [MY-013602] [Server] Channel mysql_main configured to support TLS. Encrypted connections are now supported for this channel. 2021-04-28T09:35:29.724833Z 0 [Warning] [MY-010441] [Server] Failed to open optimizer cost constant tables 2021-04-28T09:35:29.725997Z 0 [ERROR] [MY-013129] [Server] A message intended for a client cannot be sent there as no client-session is attached. Therefore, we're sending the information to the error-log instead: MY-001146 - Table 'mysql.component' doesn't exist 2021-04-28T09:35:29.726837Z 0 [Warning] [MY-013129] [Server] A message intended for a client cannot be sent there as no client-session is attached. Therefore, we're sending the information to the error-log instead: MY-003543 - The mysql.component table is missing or has an incorrect definition. 2021-04-28T09:35:29.727818Z 0 [ERROR] [MY-000067] [Server] unknown variable 'ignore-db-dir=lost+found'. 2021-04-28T09:35:29.729297Z 0 [ERROR] [MY-010119] [Server] Aborting 2021-04-28T09:35:31.237003Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.24) MySQL Community Server - GPL. get_actual_db_status /opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/mysql_common/service.py:80 2021-04-28 09:35:31.266 930 DEBUG trove.guestagent.datastore.service [-] Waiting for DB status to change from running to healthy. wait_for_status /opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/service.py:319 I think this requires some changes in config.template of mysql. -- Regards, Syed Ammad Ali

1 1

[tc][all][ Xena Virtual PTG Summary
by Ghanshyam Mann 28 Apr '21

28 Apr '21

Hello Everyone, I am summarizing the Technical Committee discussion that happened in the Xena cycle PTG. Pop Up Team Check-In --------------------------- Currently, we have two pop-up teams 1. policy-popup 2. Encryption, as per checks, both are active, and we will continue on both teams in the Xena cycle. policy pop-up team almost served its purpose and ready to be converted as community-wide goal as next step which can happen in Y cycle. Community-wide goals Check-In --------------------------------------- *In the Wallaby cycle, we selected two community-wide goals. In PTG we checked the progress and any blocker. 1. Migrate RBAC Policy Format from JSON to YAML[1] This is almost completed, only heat and few patches in openstack-ansible are pending. Tracking etherpad[2]. Action Items: Finish the pending patches to merge. Assignee: gmann 2. Migrate from oslo.rootwrap to oslo.privsep[3] ralonsoh could not join this session due to conflict with neutron sessions, but this needs more work and will continue in Xena cycle too. Action Items: Continue this work in Xena cycle Assignee: ralonsoh * Along with the above goals, we checked a few previous cycle goals pending work also, and the below two are pretty simple and important to complete. We will spend some time finishing these in Xena cycle. 1. offline pdf doc: https://storyboard.openstack.org/#!/story/list?tags=pdf-doc-enabled Assignee: gmann 2. Contributor guide: https://storyboard.openstack.org/#!/story/2007236 Assignee: gmann, diablo_rojo *Y cycle goal selection. As per the community-wide goal schedule[4], we need to start the goal selection for the Y cycle. We have two TC members volunteer to drive this work. Assignee: ricolin, diablo_rojo TC tag advertising and encourage project adoption. -------------------------------------------------------------- We discussed the TC tags[5] adoption and if it is worth continuing it or who actually gets benefit from these. It is not so clear if they are being checked by users or anyone. Projects are adopted in production by their stability and feature, not just by tag. We decided to review each tag for its usefulness and cleanup. Based on what left, we can make a decision on whether to continue the tag concept or not. Action Items: Review each tag for its usefulness and cleanup Assignee: yoctozepto, jungleboyj Discussion on moving OpenStack to a yearly release cycle -------------------------------------------------------------------- This topic has been discussed before also and it was live-streamed on youtube too, which you can watch[6]. Discussion is about if the current 6-month release cycle is fine/fast for consumers to adopt the releases/upgrade etc. There were both side arguments about moving OpenStack release to 1-year cycle and it was not so clear if that actually solve the upgrade/consuming feature or not. Also, there are few points on developer perspective and being a long 1-year release can slow down the community activeness and developer time for upstream work. But there were more important points also which I did not summarize here but you to watch the youtube video for details. In summary, there is no consensus on this and we gathered some of the action items to continue this get feedback or educating about upgrade operation guides& best practices. Action Items: * Reach out to the Project team + operators about feedback via ML. * Encourage "Operation Docs and Tooling" SIG to add upgrades and operational education guideline Assignee: I forgot to ask the volunteer for this, please let me know if anyone would like to help with this. Wallaby Retrospective --------------------------- Below is what we discussed in the previous cycle retrospective * TC is more productive with the weekly meetings which helped to speed up the review and discussions. * Happy to see TC engagement on the gate and infra stuff. We will be continuing this as our weekly meeting agenda too. Thanks to dansmith to initiate this * Did not promote election well. We discussed this in detail as a separate topic, I am writing the summary for this in the below section. * We need more interaction with project/SIG(and also popups?:) ) team. Ditto, I am writing the summary for this in the below section. * Doing great with settling projects to DPL and also we have zero projects left behind as leaderless. * Landed the TC stance on SDK/OSC Patch * Started SIG audit too in terms of health checks which is good to keep SIG list active and maintained Thanks to ricolin and diablo_rojo. * Thanks to mnaser and diablo_rojo for serving as Chair/Vice-chair and running the show in a great way. Getting projects to broadcast out/mentor ++ ---------------------------------------------------- This topic is about encouraging projects to broadcast out successes, wins, and possibly get people in projects to engage in some public speaking of their work, why it is important to them, the change they see it making in the world, team values, what does the team find important. We discussed the various way to achieve that and some of part is about marketing the things. There is openinfra live tv which broadcast the live sessions every Thursday, take more help from the foundation or reach out to local user groups. Apart from marketing stuff, TC will definitely encourage projects to start talking about the more and more technical stuff in public speaking. Action Items: * TC to reachout to board/foundation to provide an exact platform for broadcast these, existing or any new platform * TC to document this as best practice to do by projects in project team guide. Assignee: spotz, belmoreira How do we not break cross-vendor drivers? --------------------------------------------------- This discussion was about cross-vendor drivers. In Ironic, w recent change to redfish drivers was found to break in one case on another vendor. Even current stable policy state in appropriate-fixes section[7]on taking the best decision on backport fixes. Projects can take decisions as per the project and user's best interest which will help everyone. We talked about the stable policy process in the next topic which is going to help projects in such cases. Stable core team process ----------------------------- We have talked about this in shanghai PTG also but did not proceed with any resolution. We are facing a few issues with the stable backport merges. The stable maintenance team is not so active as it used to be. There is a delay in adding more core in stable project groups or merging the backports. Elod mentioned that right now that generally when people have questions, they refer them to the policy documents and make a decision. We definitely want to fix the current issues and the good news is that we agreed to do few changes on stable policy like let the project core team manages the project side stable team and also policy they would like to define as per the project's use case. Action Items: * Add a resolution and modify stable policy doc for the below changes: ** Let the project team manage the project's stable core team, Global stable maintenance core team is continuing on general advice and help. ** Projects are allowed to define any addition or own policy on top of general stable policy guidelines. Assignee: jungleboyj, mnaser/gmann (gmann to check if mnaser is ok with this item) Stable EM to EOL transition --------------------------------- There are 9 stable branches currently (will be 8 soon after ocata moves to EOL) including EM or maintained stable. Discussion is about the maintenance effort for these many stable branches. how we can handle the supporting team load for EM branches like QA, infra etc. Many projects gate on EM stable branches is broken. QA team or elod end up spending lot of time during py2 drop time on EM branch even we still fix those. But in future, we might not have that much volume on EM branch maintenance. With that, we did not conclude on reducing the number of EM branch and continue as it is. But as 'unmaintained phase is not so clear and not real phase branch transition to, we agreed to remove this phase and let EM branch directly move to EOL state based on their current lifecycle or maintenance. Action Items: Remove the "Unmaintained" phase Assignee: gmann Next, we talked about the TC process & workflow things. Meeting time check ------------------------ As we have two new TC members, we checked on the current meeting time. The current time Thursday 15 UTC is ok for all TC members and we will continue that. Office Hour continuation ------------------------------ TC office hours are still inactive and we discussed if we want to continue on these or we can remove especially when we have weekly meetings. The consensus on this is to continue with the one office hour which is in Asia TZ. Action Items: Keep one office hour Assignee: gmann Charter revision for election vacant seat ----------------------------------------------- This was the first time in the TC election that we had one vacant seat. There was discussion on reducing the TC seats (this requires the charter change but we did not have full TC members to do the charter change) or doing a special election which we went with a special election. This is something we tool as an action item to make our charter handle this situation in future if occur. We also talked about how we can engage AUC in election or voting and decided to add a way for them to be extra ATC. Action Items: * Charter change to write the process to handle these vacant seat situations and how to make a charter change in absence of complete TC or so. * Document the process for adding SIG+project contributors, AUC as extra ATC. Assignee: dansmith How we can improve our election promotion ----------------------------------------------------- In past couple of elections, we have noticed that many members miss the nomination deadline also fewer members step up for the leadership role. We discussed few ways to improve the election promotion but there is no concrete things we agreed on Another but important thing we discussed is how to add more members to the election official team. Every time it's fungi or diablo_rojo helping in front. We decided that we will have two TC members volunteer for every cycle election official or encourage community members to be part of this wG. Action Items: Make a process to ask two TC volunteers for an election official in addition to existing election officials. Assignee: spotz, diablo_rojo Project Health checks -------------------------- We tried a few ways in past to improve the interaction between TC and the project side. TC liaison is our current way to check project health and interaction but that is not so active or helpful. Rico suggested trying some automatic way to check the contribution stats. But apart from that we did not decide any conclusion on that and will continue this discussion in the TC meeting. Action Items: * automate the process to check the health in term of contribution/review/release/gate * Continue this topic in the weekly meetings. Assignee: belmoreira, ricolin Mechanism to define the TC track-able targets per cycle (or redefine the TC tracker) ------------------------------------------------------------------------------------------------- This is to try a mechanism for TC working items per cycle. We agreed to track these in etherpad and check status in our weekly meeting. Action Items: Create the etherpad for Xena cycle tracker: https://etherpad.opendev.org/p/tc-xena-tracker Assignee: gmann [1] https://governance.openstack.org/tc/goals/selected/wallaby/migrate-policy-f… [2] https://etherpad.opendev.org/p/migrate-policy-format-from-json-to-yaml [3] https://governance.openstack.org/tc/goals/selected/wallaby/migrate-to-privs… [4] https://governance.openstack.org/tc/goals/#goal-selection-schedule [5] https://governance.openstack.org/tc/reference/tags/index.html [6] https://www.youtube.com/watch?v=s4HOyAdQx8A [7] https://docs.openstack.org/project-team-guide/stable-branches.html#appropri… -gmann

1 0

[all][tc] Technical Committee next weekly meeting on April 29th at 1500 UTC
by Ghanshyam Mann 28 Apr '21

28 Apr '21

Hello Everyone, Below is the agenda for tomorrow's TC meeting schedule on April 29th at 1500 UTC in #openstack-tc IRC channel. == Agenda for tomorrow's TC meeting == * Roll call * Follow up on past action items * PTG ** https://etherpad.opendev.org/p/tc-xena-ptg * TC tracker for Xena cycle (gmann) ** https://etherpad.opendev.org/p/tc-xena-tracker * Gate performance and heavy job configs (dansmith) ** http://paste.openstack.org/show/jD6kAP9tHk7PZr2nhv8h/ * TC's context, name, and documenting formal responsibilities (TheJulia) * Open Reviews ** https://review.opendev.org/q/project:openstack/governance+is:open -gmann

1 0

Xena PTG Policy Summary
by Lance Bragstad 28 Apr '21

28 Apr '21

Hey all, Last week we spent a lot of time discussing RBAC, where everything stands, and where we need to go to offer a consistent experience for operators and users. We kept track of all the sessions in a single etherpad, which also served as a place for daily summaries [0]. There is a lot of information in there, but we started working through the action items and correlating them to bugs or opening new bugs. Hopefully this helps us track progress through Xena. One of the biggest outcomes from last week was the discussion about how system users should interact with project-owned resources. For context, administrators have always been able to do things for project users because they both have project-scoped tokens. That's no longer going to be the case as services adopt system-scope. We came up with an interesting way to solve the problem and we compared it to other approaches. This all starts at about line 136 in the etherpad [0]. Ultimately, we think it will be the least invasive approach, we have a specification up for review [1], and a PoC in flight [2]. Please look over the summary and links to any actionables for your project. We can use this thread to discuss any questions if you have them. Thanks again for all the dedication and focus on policy last week. I know the discussions aren't easy and it's a tough problem to work through, but landing something this big across OpenStack services will be a huge win for operators and users. Lance [0] https://etherpad.opendev.org/p/policy-popup-xena-ptg [1] https://review.opendev.org/c/openstack/keystone-specs/+/787640 [2] https://review.opendev.org/c/openstack/keystonemiddleware/+/787822

1 0

[all][requirements] sqlalchemy 1.4.x release/upgrade
by Matthew Thode 28 Apr '21

28 Apr '21

Looks like a new release of sqlalchemy is upon us and is breaking tests in openstack (1.4.11 for now). Please test against https://review.opendev.org/788339 to get your project working against the newest version. currently failing are cinder ironic keystone masakari neutron and nova cross gates Thanks, -- Matthew Thode

6 8

[openstack-ansible-modules] Openstack Ansible collections PTG session summary
by Sagi Shnaidman 28 Apr '21

28 Apr '21

Hi, all Highlights from Openstack Ansible collection/modules PTG session[1] In the last cycle we had 68 commits, 3 released versions, 5 new contributors, 14 solved issues. The roadmap for next cycle: All modules in Xena should convert SDK output to a dictionary to match last SDK changes. CI tasks: 1. Automatic release jobs 2. Docs generation and publishing jobs - docs.openstack.org and readthedocs will be evaluated. 3. Gating jobs for projects starting to use the collections, like TripleO. Bugtracker - to evaluate Launchpad for bugs and issues submission. We continue to convert modules to use a standard OpenstackModule class. Features coverage for Openstack Ansible modules would help us to see how good we cover the current functionality. It would be useful to have roles in collection which will run specific and common tasks, which can be used by OPs easily. (Like Terraform "modules" concept) For fetching Openstack SDK logs during the tasks execution we may have a specific role or/and OpenstackModule class modifications. Ansible-test is used now for sanity testing only, we'll evaluate it for integration tests next cycle. Thanks [1] https://etherpad.opendev.org/p/xena-ptg-os-ansible-collections -- Best regards Sagi Shnaidman

1 0