January 2020 - openstack-discuss - lists.openstack.org

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