- openstack-discuss - lists.openstack.org

[all] Announcing OpenStack Victoria!
by Sean McGinnis 13 Jan '20

13 Jan '20

Hello everyone, The polling results are in, and the legal vetting process has now completed. We now have an official name for the "V" release. The full results of the poll can be found here: https://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=1&id=E_13ccd49b6… While Victoria and Vancouver were technically a tie, based on the Minimax rankingi, it puts Victoria slightly ahead of Vancouver based on the votes. In addition to that, we chose to have the TC do a tie breaker vote which confirmed Victoria as the winner. Victoria is the capital city of British Columbia: https://en.wikipedia.org/wiki/Victoria,_British_Columbia Thank you all for participating in the release naming! Sean

2 1

[neutron] Bug deputy report - Jan 06 to 12
by Hongbin Lu 12 Jan '20

12 Jan '20

1 0

[tripleo][ci] Proposing Sorin Barnea as TripleO-CI core
by Marios Andreou 12 Jan '20

12 Jan '20

I would like to propose Sorin Barnea (ssbarnea(a)redhat.com) as core on tripleo-ci repos (tripleo-ci, tripleo-quickstart, tripleo-quickstart-extras). Sorin has been a member of the tripleo-ci team for over one and a half years and has made many contributions across the tripleo-ci repos and beyond - highlights include helping the team to adopt molecule testing, leading linting efforts/changes/fixes and many others. Please vote by replying to this thread with +1 or -1 for any objections thanks marios

9 8

[tripleo][ci] Proposing Chandan Kumar and Arx Cruz as TripleO-CI cores
by Ronelle Landy 11 Jan '20

11 Jan '20

Hello All, I'd like to propose Arx Cruz (arxcruz(a)redhat.com) and Chandan Kumar ( chkumar(a)redhat.com) as core on tripleo-ci repos (tripleo-ci, tripleo-quickstart, tripleo-quickstart-extras). In addition to the extensive work that Arx and Chandan have done on the Tempest-related repos ( and Tempest interface/settings within the Tripleo CI repos) , they have become active contributors to the core Tripleo CI repos, in general, in the past two years. Please vote by replying to this thread with +1 or -1 for any objections. We will close the vote 7 days from now. Thank you, Ronelle

5 5

[keystone] Keystone Team Update - Week of 6 January 2020
by vishakha agarwal 11 Jan '20

11 Jan '20

# Keystone Team Update - Week of 6 January 2020 ## News ### User Support and Bug Duty The person in-charge for bug duty for current and upcoming week can be seen on the etherpad [1] [1] https://etherpad.openstack.org/p/keystone-l1-duty ## Action Items The one-fourth of the ussuri cycle is almost over. We need to find a new mechanism for the retrospective and to check our progress for this cycle which is more convenient and less time consuming for the members. ## Open Specs Ussuri specs: https://bit.ly/2XDdpkU Ongoing specs: https://bit.ly/2OyDLTh ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 19 changes this week. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 37 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ### Priority Reviews * Community Goals https://review.opendev.org/#/c/699127/ [ussuri][goal] Drop python 2.7 support and testing keystone-tempest-plugin https://review.opendev.org/#/c/699126/ [ussuri][goal] Drop python 2.7 support and testing ldappool https://review.opendev.org/#/c/699119/ [ussuri][goal] Drop python 2.7 support and testing python-keystoneclient * Special Requests https://review.opendev.org/#/c/662734/ Change the default Identity endpoint to internal https://review.opendev.org/#/c/699013/ Always have username in CADF initiator https://review.opendev.org/#/c/700826/ Fix role_assignments role.id filter ## Bugs This week we opened 3 new bugs and closed 5. Bugs opened (3) Bug #1858410 (keystone:Low): Got error 'NoneType' when executing unittest on stable/rocky - Opened by Eric Xie https://bugs.launchpad.net/keystone/+bug/1858410 Bug #1858186 (keystoneauth:Undecided): http_log_request will print debug info include pki certificate which is unsafety - Opened by kuangpeiling https://bugs.launchpad.net/keystoneauth/+bug/1858186 Bug #1858189 (keystoneauth:Undecided): http_log_request will print debug info include pki certificate which is unsafety - Opened by kuangpeiling https://bugs.launchpad.net/keystoneauth/+bug/1858189 Bugs closed (5) Bug #1858186 (keystoneauth:Undecided) https://bugs.launchpad.net/keystoneauth/+bug/1858186 Bug #1856881 (keystone:Medium): keystone-manage bootstrap fails with ambiguous role names - Fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1856881 Bug #1856962 (keystone:Undecided): openid method failed when federation_group_ids is empty list - Fixed by Colleen Murphy https://bugs.launchpad.net/keystone/+bug/1856962 Bug #1857086 (keystone: Won't Fix) https://bugs.launchpad.net/keystone/+bug/1857086 Bug #1831018 (keystone: Invalid)https://bugs.launchpad.net/keystone/+bug/1831018 ## Milestone Outlook https://releases.openstack.org/ussuri/schedule.html Spec freeze is on the week of 10 February. All the specs targeted for this cycle should be ready for the review soon. ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter

1 0

[aodh][keystone] handling of webhook / alarm authentication
by info＠dantalion.nl 11 Jan '20

11 Jan '20

Hello, I was wondering how a service receiving an aodh webhook could perform authentication? The documentation describes the webhook as a simple post-request so I was wondering if a keystone token context is available when these requests are received? If not, I was wondering if anyone had any recommendation on how to perform authentication upon received post-requests? So far I have come up with limiting the functionality of these webhooks such as rate-limiting and administrators having to explicitly enable these webhooks before they work. Hope anyone else could provide further valuable information. Kind regards, Corne Lukken Watcher core-reviewer

3 4

[release] Release countdown for week R-17, January 13-17
by Sean McGinnis 11 Jan '20

11 Jan '20

Development Focus ----------------- The Ussuri-2 milestone will happen in next month, on February 13. Ussuri-related specs should now be finalized so that teams can move to implementation ASAP. Some teams observe specific deadlines on the second milestone (mostly spec freezes): please refer to https://releases.openstack.org/ussuri/schedule.html for details. General Information ------------------- Please remember that libraries need to be released at least once per milestone period. At milestone 2, the release team will propose releases for any library that has not been otherwise released since milestone 1. Other non-library deliverables that follow the cycle-with-intermediary release model should have an intermediary release before milestone-2. Those who haven't will be proposed to switch to the cycle-with-rc model, which is more suited to deliverables that are released only once per cycle. At milestone-2 we also freeze the contents of the final release. If you have a new deliverable that should be included in the final release, you should make sure it has a deliverable file in: https://opendev.org/openstack/releases/src/branch/master/deliverables/ussuri You should request a beta release (or intermediary release) for those new deliverables by milestone-2. We understand some may not be quite ready for a full release yet, but if you have something minimally viable to get released it would be good to do a 0.x release to exercise the release tooling for your deliverables. See the MembershipFreeze description for more details: https://releases.openstack.org/ussuri/schedule.html#u-mf Finally, now may be a good time for teams to check on any stable releases that need to be done for your deliverables. If you have bugfixes that have been backported, but no stable release getting those. If you are unsure what is out there committed but not released, in the openstack/releases repo, running the command "tools/list_stable_unreleased_changes.sh <cycle_name>" gives a nice report. Upcoming Deadlines & Dates -------------------------- Ussuri-2 Milestone: February 13 (R-13 week)

1 0

[tripleo] introducing zuul-runner
by Wesley Hayutin 11 Jan '20

11 Jan '20

Greetings, Hey everyone I want to highlight work that some of our good friends in zuul are working another way to try and help everyone debug their jobs. The tool is called zuul-runner and the spec is here [1], code is here [2] Please have a look through the spec and vote to show support for Tristan's work. Thanks to Arx Cruz for contributing and testing it as well w/ TripleO jobs. This will be another very nice tool in the toolbox for us if we can get it through. Thanks! [1] https://review.opendev.org/#/c/681277/ [2] https://review.opendev.org/#/c/607078/

1 0

[neutron][rabbitmq] Neutron-server service shows deprecated "AMQPDeprecationWarning"
by Amjad Kotobi 10 Jan '20

10 Jan '20

Hi, Today we are facing losing connection of neutron especially during instance creation or so as “systemctl status neutron-server” shows below message be deprecated in amqp 2.2.0. Since amqp 2.0 you have to explicitly call Connection.connect() before using the connection. W_FORCE_CONNECT.format(attr=attr))) /usr/lib/python2.7/site-packages/amqp/connection.py:304: AMQPDeprecationWarning: The .transport attribute on the connection was accessed before the connection was established. This is supported for now, but will be deprecated in amqp 2.2.0. Since amqp 2.0 you have to explicitly call Connection.connect() before using the connection. W_FORCE_CONNECT.format(attr=attr))) OpenStack release which we are running is “Pike”. Is there any way to remedy this? Thanks Amjad

3 4

Re: [charms][watcher] OpenStack Watcher Charm
by Corey Bryant 10 Jan '20

10 Jan '20

On Fri, Jan 10, 2020 at 6:12 AM James Page <james.page(a)canonical.com> wrote: > Hi Stamatis > > Thankyou for this work! > > I'll take a look at your charm over the next few days. > > On Wed, Jan 8, 2020 at 11:25 AM Stamatis Katsaounis < > skatsaounis(a)admin.grnet.gr> wrote: > >> Hi all, >> >> Purpose of this email is to let you know that we released an unofficial >> charm of OpenStack Watcher [1]. This charm gave us the opportunity to >> deploy OpenStack Watcher to our charmed OpenStack deployment. >> >> After seeing value in it, we decided to publish it through GRNET GitHub >> Organization account for several reasons. First of all, we would love to >> get feedback on it as it is our first try on creating an OpenStack reactive >> charm. Secondly, we would be glad to see other OpenStack operators deploy >> Watcher and share with us knowledge on the project and possible use cases. >> Finally, it would be ideal to come up with an official OpenStack Watcher >> charm repository under charmers umbrella. By doing this, another OpenStack >> project is going to be available not only for Train version but for any >> future version of OpenStack. Most important, the CI tests are going to >> ensure that the code is not broken and persuade other operators to use it. >> >> Before closing my email, I would like to give some insight on the >> architecture of the code base and the deployment process. To begin with, >> charm-watcher is based on other reactive OpenStack charms. During its >> deployment Barbican, Designate, Octavia and other charms' code bases were >> counseled. Furthermore, the structure is the same as any official OpenStack >> charm, of course without functional tests, which is something we cannot >> provide. >> > I'd suggest that we initiate the process to include your watcher charm as > part of the OpenStack Charmers project on opendev.org; once the initial > migration completes adding some functional tests should be fairly easy as > you'll be able to run them on the Canonical 3rd party CI infrastructure. > > This requires that a couple of reviews be raised - here are examples for > the new Manila Ganesha charms: > > https://review.opendev.org/#/c/693463/ > https://review.opendev.org/#/c/693462/ > > One is for the infrastructure setup, the other is to formally include the > repositories as part of the TC approved project. If you would like to > raise them for the watcher charm I'm happy to review with Frode (who is the > current PTL). > >> Speaking about the deployment process, apart from having a basic charmed >> OpenStack deployment, operator has to change two tiny configuration options >> on Nova cloud controller and Cinder. As explained in the Watcher >> configuration guide, special care has to be done with Oslo notifications >> for Nova and Cinder [2]. In order to achieve that in charmed OpenStack some >> issues were met and solved with the following patches [3], [4], [5], [6]. >> With these patches, operator can set the extra Oslo configuration and this >> is the only extra configuration needs to take place. Finally, with [7] >> Keystone charm can accept a relation with Watcher charm instead of ignoring >> it. >> >> To be able to deploy GRNET Watcher charm on Train, patches [3], [4], [5] >> and [7] have to be back-ported to stable/19.10 branch but that will require >> the approval of charmers team. Please let me know if such an option is >> available and in that case I am going to open the relevant patches. >> Furthermore, if you think that it could be a good option to create a spec >> and then introduce an official Watcher charm, I would love to help on that. >> > I'd rather we wait until the 20.02 charm release - dependent changes have > all landed and will be included. > > I wish all a happy new year and I am looking forward to your response and >> possible feedback. >> > > Happy new year to you as well! > > PS. If we could have an Ubuntu package for watcher-dashboard [8] like >> octavia-dashboard [9] we would release a charm for it as well. >> > > I'll chat with coreycb and see if we might be able to package that for > 20.04/Ussuri. > > Hi, I'll take a look at packaging watcher-dashboard. Corey Cheers > > James > >> >> -- Corey

1 0

[largescale-sig] Next meeting: Jan 15, 9utc
by Thierry Carrez 10 Jan '20

10 Jan '20

Hi everyone, The Large Scale SIG will have a meeting next week on Wednesday, Jan 15 at 9 UTC[1] in #openstack-meeting on IRC. I'll not be around but Belmiro Moreira volunteered to chair the meeting. [1] https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200115T09 We had several TODOs out of our December meeting, so I invite you to review the summary of that meeting in preparation of the next: http://lists.openstack.org/pipermail/openstack-discuss/2019-December/011667… As always, the agenda for the meeting next week is available at: https://etherpad.openstack.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez (ttx)

1 0

[kolla] Kayobe 7.0.0 released for Train
by Mark Goddard 10 Jan '20

10 Jan '20

Hi, I'm pleased to announce the release of Kayobe 7.0.0 - the first release in the Train series, and the first release as a deliverable of the Kolla project. Full details are available in the release notes which are available here: https://docs.openstack.org/releasenotes/kayobe/train.html We anticipate significant changes during the Train release series to support a migration to CentOS 8. We will communicate which releases are affected. Thanks to everyone who contributed to this release, and for the Kolla project for accepting us. I look forward to the continued integration of these teams. Cheers, Mark

1 0

[release] decentralising release approvals
by Mark Goddard 10 Jan '20

10 Jan '20

Hi, If this topic has been discussed many times already then someone please say so and we can leave it alone. As kolla PTL and ironic release liaison I've proposed a number of release patches recently. Generally the release team is good at churning through these, but sometimes patches can hang around for a while. Usually a ping on IRC will get things moving again within a day or so (thanks in particular to Sean who has been very responsive). Related to the recent discussion about decentralising stable branch maintenance, should we do this for releases too? To be clear, I'm proposing giving project teams more control over their own releases. I brought this up in IRC recently and there was a brief discussion. I suggested that releases are hard to undo, and Monty corrected me by saying they are impossible to undo. Still, if teams (or a subset of their members) had more ownership of their releases, they would become more familiar with the process, and the risk would be reduced. I'm not suggesting that release team should be disbanded - there is clearly work to do to maintain the tooling, determine and communicate the schedule, and more. But there's a lot of toil involved in checking and approving patches to the releases repo, and it's done by some of our most senior, busy colleagues. There are a number of checks that are performed automatically by the tooling and used to gate merges. I have a few questions for the release team about these reviews. * What manual checks do you do beyond those that are currently automated? * Could the above checks be automated? * What issues have you caught that were not caught by CI jobs? Hopefully I haven't offended anyone here. There's often more involved with these things than you first suspect. Cheers, Mark

5 10

[ops][largescale-sig] Collecting scaling stories
by Thierry Carrez 10 Jan '20

10 Jan '20

Hi everyone, As part of its goal of further pushing back scaling limits within a given cluster, the Large Scale SIG would like to collect scaling stories from OpenStack users. There is a size/load limit for single clusters past which things in OpenStack start to break, and we need to start using multiple clusters or cells to scale out. The SIG is interested in hearing: - what broke first for you, is it RabbitMQ or something else - what were the first symptoms - at what size/load did it start to break This will be a great help to document expected limits, and identify where improvements should be focused. You can contribute your experience by replying directly to this thread, or adding to the following etherpad: https://etherpad.openstack.org/p/scaling-stories Thanks in advance for your help ! -- Thierry Carrez (ttx) on behalf of the Large Scale SIG

1 0

Re: [charms][watcher] OpenStack Watcher Charm
by James Page 10 Jan '20

10 Jan '20

Dropping direct recipients as this causes a reject from openstack-discuss! On Fri, Jan 10, 2020 at 11:12 AM James Page <james.page(a)canonical.com> wrote: > Hi Stamatis > > Thankyou for this work! > > I'll take a look at your charm over the next few days. > > On Wed, Jan 8, 2020 at 11:25 AM Stamatis Katsaounis < > skatsaounis(a)admin.grnet.gr> wrote: > >> Hi all, >> >> Purpose of this email is to let you know that we released an unofficial >> charm of OpenStack Watcher [1]. This charm gave us the opportunity to >> deploy OpenStack Watcher to our charmed OpenStack deployment. >> >> After seeing value in it, we decided to publish it through GRNET GitHub >> Organization account for several reasons. First of all, we would love to >> get feedback on it as it is our first try on creating an OpenStack reactive >> charm. Secondly, we would be glad to see other OpenStack operators deploy >> Watcher and share with us knowledge on the project and possible use cases. >> Finally, it would be ideal to come up with an official OpenStack Watcher >> charm repository under charmers umbrella. By doing this, another OpenStack >> project is going to be available not only for Train version but for any >> future version of OpenStack. Most important, the CI tests are going to >> ensure that the code is not broken and persuade other operators to use it. >> >> Before closing my email, I would like to give some insight on the >> architecture of the code base and the deployment process. To begin with, >> charm-watcher is based on other reactive OpenStack charms. During its >> deployment Barbican, Designate, Octavia and other charms' code bases were >> counseled. Furthermore, the structure is the same as any official OpenStack >> charm, of course without functional tests, which is something we cannot >> provide. >> > I'd suggest that we initiate the process to include your watcher charm as > part of the OpenStack Charmers project on opendev.org; once the initial > migration completes adding some functional tests should be fairly easy as > you'll be able to run them on the Canonical 3rd party CI infrastructure. > > This requires that a couple of reviews be raised - here are examples for > the new Manila Ganesha charms: > > https://review.opendev.org/#/c/693463/ > https://review.opendev.org/#/c/693462/ > > One is for the infrastructure setup, the other is to formally include the > repositories as part of the TC approved project. If you would like to > raise them for the watcher charm I'm happy to review with Frode (who is the > current PTL). > >> Speaking about the deployment process, apart from having a basic charmed >> OpenStack deployment, operator has to change two tiny configuration options >> on Nova cloud controller and Cinder. As explained in the Watcher >> configuration guide, special care has to be done with Oslo notifications >> for Nova and Cinder [2]. In order to achieve that in charmed OpenStack some >> issues were met and solved with the following patches [3], [4], [5], [6]. >> With these patches, operator can set the extra Oslo configuration and this >> is the only extra configuration needs to take place. Finally, with [7] >> Keystone charm can accept a relation with Watcher charm instead of ignoring >> it. >> >> To be able to deploy GRNET Watcher charm on Train, patches [3], [4], [5] >> and [7] have to be back-ported to stable/19.10 branch but that will require >> the approval of charmers team. Please let me know if such an option is >> available and in that case I am going to open the relevant patches. >> Furthermore, if you think that it could be a good option to create a spec >> and then introduce an official Watcher charm, I would love to help on that. >> > I'd rather we wait until the 20.02 charm release - dependent changes have > all landed and will be included. > > I wish all a happy new year and I am looking forward to your response and >> possible feedback. >> > > Happy new year to you as well! > > PS. If we could have an Ubuntu package for watcher-dashboard [8] like >> octavia-dashboard [9] we would release a charm for it as well. >> > > I'll chat with coreycb and see if we might be able to package that for > 20.04/Ussuri. > > Cheers > > James > >> >>

1 0

[infra][stable] python3 is used by default in older stable branches
by Akihiro Motoki 10 Jan '20

10 Jan '20

Hi, The horizon team recently noticed that python3 is used as a default python interpreter in older stable branches like pike or ocata. For example, horizon pep8 job in stable/pike and stable/ocata fails [1][2]. We also noticed that some jobs which are expected to run with python2 (using the tox default interpreter as of the release) are now run with python3 [3]. What is the recommended way to cope with this situation? Individual projects can cope with the default interpreter change repo by repo, but this potentially affects all projects with older stable branches. This is the reason I am sending this mail. Best Regards, Akihiro Motoki (amotoki) [1] https://zuul.opendev.org/t/openstack/build/daaeaedb0a184e29a03eeaae59157c78 [2] https://zuul.opendev.org/t/openstack/build/525dc7f926684e54be8b565a7bbf7193 [3] https://zuul.opendev.org/t/openstack/build/adbc53b8d1f74dac9cd606f4a796c442…

3 3

[neutron][vpnaas] New neutron-vpnaas maintainer and core reviewer
by Slawek Kaplonski 10 Jan '20

10 Jan '20

Hi, After our last call for volunteers to maintain some of the neutron stadium projects, we have new neutron-vpnaas maintainer now \o/ Dongcan Ye just stepped up to take care of this project. After discussion with other neutron-vpnaas core reviewers I added him to neutron-vpnaas core team. He works on neutron-vpnaas since some time already and in our opinion he knows this project good enough to be core reviewer there. Thank You very much Dongcan Ye for help with neutron-vpnaas project :) — Slawek Kaplonski Senior software engineer Red Hat

1 0

[magnum]: K8s cluster creation times out. OpenStack Train : [ERROR]: Unable to render networking. Network config is likely broken
by Bhupathi, Ramakrishna 10 Jan '20

10 Jan '20

Folks, I am building a Kubernetes Cluster( Openstack Train) and using fedora atomic-29 image . The nodes come up fine ( I have a simple 1 master and 1 node) , but the cluster creation times out, and when I access the cloud-init logs I see this error . Wondering what I am missing as this used to work before. I wonder if this is image related . [ERROR]: Unable to render networking. Network config is likely broken: No available network renderers found. Searched through list: ['eni', 'sysconfig', 'netplan'] Essentially the stack creation fails in "kube_cluster_deploy" Can somebody help me debug this ? Any help is appreciated. --RamaK E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.

2 1

Re: [Release-job-failures] release-post job for openstack/releases for ref refs/heads/master failed
by Sean McGinnis 10 Jan '20

10 Jan '20

On Thu, Jan 09, 2020 at 08:32:28PM +0000, zuul(a)openstack.org wrote: > Build failed. > > - tag-releases https://zuul.opendev.org/t/openstack/build/deb8b8d5504b4689ab6d669eac92f979 : FAILURE in 3m 46s > - publish-tox-docs-static https://zuul.opendev.org/t/openstack/build/None : SKIPPED > This failure can be safely ignored. This was a side effect of marking some older independent repos as 'abandoned' in https://review.opendev.org/#/c/700013/. These are old repos that are no longer under governance and/or retired. The failure itself appears to be from one of the retired repos, before we had specified in the retire procedure that the gitreview file should be kept around. Since these are no longer active, and there wasn't actually anything to tag and release, no need to worry about this failure. Sean

1 0

[qa][infra][stable] Stable branches gate status: tempest-full-* jobs failing for stable/ocata|pike|queens
by Ghanshyam Mann 09 Jan '20

09 Jan '20

Hello Everyone, tempest-full-* jobs are failing on stable/queens, stable/pike, and stable/ocata(legacy-tempest-dsvm-neutron-full-ocata) [1].ld Please hold any recheck till fix is merged. whoami-rajat reported about the tempest-full-queens-py3 job failure and later while debugging we found that same is failing for pike and ocata(job name there - legacy-tempest-dsvm-neutron-full-ocata). Failure is due to "Timeout on connecting the vnc console url" because there is no 'n-cauth' service running which is required for these stable branches. In Ussuri that service has been removed from nova. 'n-cauth' has been removed from ENABLED_SERVICES recently in - https://review.opendev.org/#/c/700217/ which effected only stable branches till queens. stable/rocky|stein are working because we have moved the services enable things from devstack-gate's test matrix to devstack base job[2]. Patch[2] was not backported to stable/queens and stable/pike which I am not sure why. We have two ways to fix the stable branches gate: 1. re-enable the n-cauth in devstack-gate. Hope all other removes services create no problem. pros: easy to fix, fix for all three stable branches. patch- https://review.opendev.org/#/c/701404/ 2. Backport the 546765[2] to stable/queens and stable/pike. pros: this removes the dependency form test-matrix which is the overall goal to remove d-g dependency. cons: It cannot be backported to stable/ocata as no zuulv3 base jobs there. This is already EM and anyone still cares about this? I think for fixing the gate (Tempest master and stable/queens|pike|ocata), we can go with option 1 and later we backport the devstack migration. [1] - http://zuul.openstack.org/builds?job_name=tempest-full-queens-py3 - http://zuul.openstack.org/builds?job_name=tempest-full-pike - http://zuul.openstack.org/builds?job_name=legacy-tempest-dsvm-neutron-full-… - reported bug - https://bugs.launchpad.net/devstack/+bug/1858666 [2] https://review.opendev.org/#/c/546765/ -gmann

1 1

[tripleo] tripleo-operator-ansible start and request for input
by Alex Schultz 09 Jan '20

09 Jan '20

[Hello folks, I've begun the basic start of the tripleo-operator-ansible collection work[0]. At the start of this work, I've chosen the undercloud installation[1] as the first role to use to figure out how we the end user's to consume these roles. I wanted to bring up this initial implementation so that we can discuss how folks will include these roles. The initial implementation is a wrapper around the tripleoclient command as run via openstackclient. This means that the 'tripleo-undercloud' role provides implementations for 'openstack undercloud backup', 'openstack undercloud install', and 'openstack undercloud upgrade'. In terms of naming conventions, I'm proposing that we would name the roles "tripleo-<command-base>" with the last part of the command action being an "action". Examples: "openstack undercloud *" -> role: tripleo-undercloud action: (backup|install|upgrade) "openstack undercloud minion *" -> role: tripleo-undercloud-minion action: (install|upgrade) "openstack overcloud *" -> role: tripleo-overcloud action: (deploy|delete|export) "openstack overcloud node *" -> role: tripleo-overcloud-node action: (import|introspect|provision|unprovision) In terms of end user interface, I've got two proposals out in terms of possible implementations. Tasks from method: The initial commit propose that we would require the end user to use an include_role/tasks_from call to perform the desired action. For example: - hosts: undercloud gather_facts: true tasks: - name: Install undercloud collections: - tripleo.operator import_role: name: tripleo-undercloud tasks_from: install vars: tripleo_undercloud_debug: true Variable switch method: I've also proposed an alternative implementation[2] that would use include_role but require the end user to set a specific variable to change if the role runs 'install', 'backup' or 'upgrade'. With this patch the playbook would look something like: - hosts: undercloud gather_facts: true tasks: - name: Install undercloud collections: - tripleo.operator import_role: name: tripleo-undercloud vars: tripleo_undercloud_action: install tripleo_undercloud_debug: true I would like to solicit feedback on which one of these is the preferred integration method when calling these roles. I have two patches up in tripleo-quickstart-extras to show how these calls could be run. The "Tasks from method" can be viewed here[3]. The "Variable switch method" can be viewed here[4]. I can see pros and cons for both methods. My take would be: Tasks from method: Pros: - action is a bit more explicit - dynamic logic left up to the playbook/consumer. - May not have a 'default' action (as main.yml is empty, though it could be implemented). - tasks_from would be a global implementation across all roles rather than having a changing variable name. Cons: - internal task file names must be known by the consumer (though IMHO this is no different than the variable name + values in the other implementation) - role/action inclusions is not dynamic in the role (it can be in the playbook) Variable switch method: Pros: - inclusion of the role by default runs an install - action can be dynamically changed from the calling playbook via an ansible var - structure of the task files is internal to the role and the user of the role need not know the filenames/structure. Cons: - calling playbook is not explicit in that the action can be switched dynamically (e.g. intentionally or accidentally because it is dynamic) - implementer must know to configure a variable called `tripleo_undercloud_action` to switch between install/backup/upgrade actions - variable names are likely different depending on the role My personal preference might be to use the "Tasks from method" because it would lend itself to the same implementation across all roles and the dynamic logic is left to the playbook rather than internally in the role. For example, we'd end up with something like: - hosts: undercloud gather_facts: true collections: - tripleo.operator tasks: - name: Install undercloud import_role: name: tripleo-undercloud tasks_from: install vars: tripleo_undercloud_debug: true - name: Upload images import_role: name: tripleo-overcloud-images tasks_from: upload vars: tripleo_overcloud_images_debug: true - name: Import nodes import_role: name: tripleo-overcloud-node tasks_from: import vars: tripleo_overcloud_node_debug: true tripleo_overcloud_node_import_file: instack.json - name: Introspect nodes import_role: name: tripleo-overcloud-node tasks_from: introspect vars: tripleo_overcloud_node_debug: true tripleo_overcloud_node_introspect_all_manageable: True tripleo_overcloud_node_introspect_provide: True - name: Overcloud deploy import_role: name: tripleo-overcloud tasks_from: deploy vars: tripleo_overcloud_debug: true tripleo_overcloud_deploy_environment_files: - /home/stack/params.yaml The same general tasks performed via the "Variable switch method" would look something like: - hosts: undercloud gather_facts: true collections: - tripleo.operator tasks: - name: Install undercloud import_role: name: tripleo-undercloud vars: tripleo_undercloud_action: install tripleo_undercloud_debug: true - name: Upload images import_role: name: tripleo-overcloud-images vars: tripleo_overcloud_images_action: upload tripleo_overcloud_images_debug: true - name: Import nodes import_role: name: tripleo-overcloud-node vars: tripleo_overcloud_node_action: import tripleo_overcloud_node_debug: true tripleo_overcloud_node_import_file: instack.json - name: Introspect nodes import_role: name: tripleo-overcloud-node vars: tripleo_overcloud_node_action: introspect tripleo_overcloud_node_debug: true tripleo_overcloud_node_introspect_all_manageable: True tripleo_overcloud_node_introspect_provide: True - name: Overcloud deploy import_role: name: tripleo-overcloud vars: tripleo_overcloud_action: deploy tripleo_overcloud_debug: true tripleo_overcloud_deploy_environment_files: - /home/stack/params.yaml Thoughts? Thanks, -Alex [0] https://blueprints.launchpad.net/tripleo/+spec/tripleo-operator-ansible [1] https://review.opendev.org/#/c/699311/ [2] https://review.opendev.org/#/c/701628/ [3] https://review.opendev.org/#/c/701034/ [4] https://review.opendev.org/#/c/701628/

7 7

[infra] Retire openstack/js-openstack-lib repository
by Andreas Jaeger 09 Jan '20

09 Jan '20

The js-openstack-lib repository is orphaned and has not seen any real merges or contributions since February 2017, I propose to retire it. I'll send retirement changes using topic retire-js-openstack-lib, Andreas -- Andreas Jaeger aj(a)suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg (HRB 36809, AG Nürnberg) GF: Felix Imendörffer GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB

5 10

[largescale-sig] Meeting summary and next actions
by Thierry Carrez 09 Jan '20

09 Jan '20

Hi everyone, The Large Scale SIG held a meeting earlier today. You can access the summary and logs of the meeting at: http://eavesdrop.openstack.org/meetings/large_scale_sig/2019/large_scale_si… This meeting was focused on immediate next steps on the two initial goals for the SIG. For the "Scaling within one cluster, and instrumentation of the bottlenecks" goal, after the holidays we will collect user stories of what happens (or what breaks first) as you scale up single clusters. We will also produce a first RFC draft for an oslo.metric blueprint, and learn more about the "Golden signals" concept. Standing TODOs: - all prepare a short description of what happens (what breaks first) when scaling up a single cluster - ttx to prepare etherpad and send ML thread asking for user scaling stories, to be posted after the end-of-year holidays - masahito to produce first draft for the oslo.metric blueprint - all learn more about golden signals concept as described in https://landing.google.com/sre/book.html For the "Document large scale configuration and tips &tricks" goal we will start collecting relevant articles and blogposts. We agreed that in order to properly document large scale configuration defaults, we should probably both patch existing docs and create new documentation. Standing TODOs: - all add links to relevant articles around large scale openstack (if you find any) to the etherpad - oneswig to follow up with Scientific community to find such articles - amorin to start a thread on documenting configuration defaults for large scale, introduce the "mixture of both" tactic The next meeting will happen on January 15, at 9:00 UTC on #openstack-meeting. Cheers, -- Thierry Carrez (ttx)

3 4

[scientific][www] Unable to download OpenStack for Scientific Research book
by Pierre Riteau 09 Jan '20

09 Jan '20

Hello, I tried to download the book at https://www.openstack.org/science/ but the link doesn't work. Could this please be fixed? I looked on openstack.org for a contact address, but couldn't find one. Please let me know if there is a specific address I should use next time. Thanks, Pierre

2 2

[tripleo] Use Podman 1.6 in CI
by Luke Short 09 Jan '20

09 Jan '20

Hey folks, We have been running into a situation where an older version of Podman is used in CI that has consistent failures. It has problems deleting storage associated with a container. A possible workaround (originally created by Damien) can be found here [1]. A few of us been in talks with the Podman team about this problem and have tested with a newer version of it (1.6.4, to be exact) and found that it is no longer an issue. The most ideal situation is to simply use this newer version of Podman instead of adding hacky workarounds that we will soon revert. However, I am unsure about how we would go about doing this upstream. RHEL will soon get an updated Podman version but CentOS always lags behind. Even CentOS 8 Stream does not contain the newer version [2]. The question/ask I have is can we ship/use a newer version of Podman in our upstream CI? Or should we continue our efforts on making a workaround? 1. https://review.opendev.org/#/c/698999/ 2. http://mirror.centos.org/centos/8-stream/AppStream/x86_64/os/Packages/ Sincerely, Luke Short

5 6