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

[tc][infra] Splitting OpenDev out of OpenStack Governance
by Clark Boylan 18 Jan '20

18 Jan '20

Hello, About six weeks ago I kicked off a discussion on what the future of OpenDev's governance looks like [0]. I think we had expected part of this process would be to split OpenDev out of OpenStack's governance, but wanted to be sure we had a bit more of a plan before we made that official. After some discussion in this thread [0] I believe we now have enough of a plan to move forward on splitting out. I've pushed a change [1] to the openstack/governance repo to make this official in git. I also wanted to make sure this change had some visibility so am sending this email too. Now for some background. The OpenDev effort intends to make our software development tools and processes available to projects outside of the OpenStack itself. We have actually made these resources available since Stackforge, but one of the major concerns we hear over and over is the implication that a project hosted on our platforms is still "OpenStack". The next step to avoiding this confusion and better reflecting our goals is to formally remove OpenDev from OpenStack's governance. As mentioned in the original thread [0], OpenDev would still incorporate input from the OpenStack project as one of its users. We aren't going away and will continue to work closely together to meet OpenStack's needs. But now we'll formalize doing that with other projects as well. Feedback is still welcome, though I ask people to read through the original thread [0] first. Please let me know if there is anything else I can do to help with this process. [0] http://lists.openstack.org/pipermail/openstack-infra/2019-December/006537.h… [1] https://review.opendev.org/703134 Clark

1 0

[Neutron] cancel neutron L3 meeting
by LIU Yulong 17 Jan '20

17 Jan '20

Hi all, Hi guys, due to the Chinese Spring Festival I will be offline in next two weeks. So I will not be available to chair the L3 meeting. Let's cancel the next two meetings. Then the L3 meeting will be rescheduled on 5th Feb, 2020. OK, see you guys then.  And happy Chinese New Year! 春节快乐！ Regards, LIU Yulong

1 0

Re: [Release-job-failures] release-post job for openstack/releases for ref refs/heads/master failed
by Thierry Carrez 17 Jan '20

17 Jan '20

zuul(a)openstack.org wrote: > Build failed. > > - tag-releases https://zuul.opendev.org/t/openstack/build/a414023508294a65abe9715546757e41 : POST_FAILURE in 5m 13s > - publish-tox-docs-static https://zuul.opendev.org/t/openstack/build/None : SKIPPED There was an error running the post-job tasks on the tag job on https://review.opendev.org/702925. While trying to collect log output: ssh: connect to host 38.108.68.119 port 22: No route to host This looks like a transient error, and it can be ignored (the job itself had run and was a NOOP anyway). -- Thierry Carrez (ttx)

1 0

[cinder][ops] new driver/new target driver merge deadline
by Brian Rosmaita 17 Jan '20

17 Jan '20

Greetings to anyone developing a new Cinder driver (or target driver), or anyone trying to get someone to develop such a driver, This is a reminder that the deadline for merging a new backend driver or a new target driver to Cinder for the Ussuri release is the Ussuri-2 milestone on 13 February 2020 (23:59 UTC). New drivers must be (a) code complete including unit tests, (b) merged into the code repository, and (c) must have a 3rd Party CI running reliably. (The idea is that new drivers will be included in a release at the second milestone and thus be easily available for downstream testing, documentation feedback, etc.) You can find more information about Cinder drivers here: https://docs.openstack.org/cinder/latest/drivers-all-about.html and you can ask questions in #openstack-cinder on IRC or here on the mailing list. cheers, brian

1 0

[magnum] subnet created in public network?
by Ionut Biru 17 Jan '20

17 Jan '20

Hello, I'm using magnum 9.2.0 and while trying to experiment with this version, i was finding out that while deploying the cluster, heat creates the subnet into the public network. In the past, on rocky and stein, magnum/heat was creating a new network, with a router and an port within the public network for connectivity. I was wondering, if this is the expected behavior (subnet in public network). How do I revert to the old way of having new network? -- Ionut Biru - https://fleio.com

1 0

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

17 Jan '20

Hi everyone, The Large Scale SIG held a meeting earlier this week. Thanks to belmiro for chairing it! You can access the summary and logs of the meeting at: http://eavesdrop.openstack.org/meetings/large_scale_sig/2020/large_scale_si… For the "Scaling within one cluster, and instrumentation of the bottlenecks" goal, I created a ML thread and etherpad to collect user stories, so far without much success. masahito is still working on the draft for oslo.metrics, hopefully will be ready by end of January. [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-January/011925.… [2] https://etherpad.openstack.org/p/scaling-stories Standing TODOs: - all post short descriptions of what happens (what breaks first) when scaling up a single cluster to https://etherpad.openstack.org/p/scaling-stories - 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, amorin started a thread[3] and etherpad[4] on documenting configuration defaults for large scale, to which slaweq contributed for Neutron. [3] http://lists.openstack.org/pipermail/openstack-discuss/2020-January/011820.… [4] https://etherpad.openstack.org/p/large-scale-sig-documentation Standing TODOs: - oneswig to follow up with Scientific community to find articles around large scale openstack The next meeting will happen on January 29, at 9:00 UTC on #openstack-meeting. They will happen from now on every two weeks. Cheers, -- Thierry Carrez (ttx)

1 0

RE: DR options with openstack
by Burak Hoban 17 Jan '20

17 Jan '20

Hey Tony, Keep in mind that if you're looking to run OpenStack, but you're not feeling comfortable with the community support then there's always the option to go with a vendor backed version. These are usually a good option for those a little more risk adverse, or who don't have the time/or skills to maintain upstream releases - however going down that path usually means you can do less with OpenStack (depending on the vendor), but you have a large pool of resources to help troubleshoot and answer questions. We do both approaches internally for different clusters, so both approaches have their pro and cons. You touched on a few points in your original email... > If you had two OpenStack clusters, one in "site 1" and another in "site 2", then you could look at below for backup/restore of instances cross-cluster: - Freezer -> https://wiki.openstack.org/wiki/Freezer - Trillio (basically just a series of nova snapshots under the cover) -> https://www.trilio.io/ You could then over the top roll out a file level based backup tool on each instance, this would pretty much offer you replication functionality without having to do block-level tinkering. > Failover of OpenStack controller/computes If you have two sites, you can always go for 3x Controller deployment spanning cross site. Depending on latency obviously, however all you really need is a good enough link for RabbitMQ/Galera to talk reliably etc. Failing that, I'd recommend backing up your Controller with ReaR. From there you can also schedule frequent automated jobs to do a OpenStack DB backups. Recovering should be a case of ReaR restore, load latest OpenStack DB and start everything up... You'll probably want to ensure your VLANs are spanned cross-site so you can reuse same IP addresses. https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/post_de… https://superuser.openstack.org/articles/tutorial-rear-openstack-deployment/ In reality, the best solution would be to have two isolated clusters, and your workloads spanned across both sites. Obviously that isn't always possible (from personal experience), but pushing people down the Kubernetes path and then for the rest automation/backup utilities may cater for your needs. Having said that, Albert's link does look promising -> https://docs.openstack.org/cinder/pike/contributor/replication.html Date: Thu, 16 Jan 2020 19:49:08 +0000 From: Albert Braden <Albert.Braden(a)synopsys.com> To: Tony Pearce <tony.pearce(a)cinglevue.com>, "openstack-discuss(a)lists.openstack.org" <openstack-discuss(a)lists.openstack.org> Subject: RE: DR options with openstack Message-ID: <BN8PR12MB3636451FC8E2BC6A50216425D9360(a)BN8PR12MB3636.namprd12.prod.outlook.com> Content-Type: text/plain; charset="utf-8" Hi Tony, It looks like Cheesecake didn’t survive but apparently some components of it did; details in https://docs.openstack.org/cinder/pike/contributor/replication.html I’m not using Cinder now; we used it at eBay with Ceph and Netapp backends. Netapp makes it easy but is expensive; Ceph is free but you have to figure out how to make it work. You’re right about forking; we did it and then upgrading turned from an incredibly difficult ordeal to an impossible one. It’s better to stay with the “official” code so that upgrading remains an option. I’m just an operator; hopefully someone more expert will reply with more useful info. It’s true that our community lacks participation. It’s very difficult for a new operator to start using openstack and get help with the issues that they encounter. So far this mailing list has been the best resource for me. IRC and Ask Openstack are mostly unattended. I try to help out in #openstack when I can, but I don’t know a lot so I mostly end up telling people to ask on the list. On IRC sometimes I find help by asking in other openstack-* channels. Sometimes people complain that I’m asking in a developer channel, but sometimes I get help. Persistence is the key. If I keep asking long enough in enough places, eventually someone will answer. If all else fails, I open a bug. Good luck and welcome to the Openstack community! From: Tony Pearce <tony.pearce(a)cinglevue.com> Sent: Wednesday, January 15, 2020 11:37 PM To: openstack-discuss(a)lists.openstack.org Subject: DR options with openstack Hi all My questions are; 1. How are people using iSCSI Cinder storage with Openstack to-date? For example a Nimble Storage array backend. I mean to say, are people using backend integration drivers for other hardware (like netapp)? Or are they using backend iscsi for example? 2. How are people managing DR with Openstack in terms of backend storage replication to another array in another location and continuing to use Openstack? The environment which I am currently using; 1 x Nimble Storage array (iSCSI) with nimble.py Cinder driver 1 x virtualised Controller node 2 x physical compute nodes This is Openstack Pike. In addition, I have a 2nd Nimble Storage array in another location. To explain the questions I’d like to put forward my thoughts for question 2 first: For point 2 above, I have been searching for a way to utilise replicated volumes on the 2nd array from Openstack with existing instances. For example, if site 1 goes down how would I bring up openstack in the 2nd location and boot up the instances where their volumes are stored on the 2nd array. I found a proposal for something called “cheesecake” ref: https://specs.openstack.org/openstack/cinder-specs/specs/rocky/cheesecake-p…<https://urldefense.proofpoint.com/v2/url?u=https-3A__specs.openstack.org_op…> But I could not find if it had been approved or implemented. So I return to square 1. I have some thoughts about failing over the controller VM and compute node but I don’t think there’s any need to go into here because of the above blocker and for brevity anyway. The nimble.py driver which I am using came with Openstack Pike and it appears Nimble / HPE are not maintaining it any longer. I saw a commit to remove nimble.py in Openstack Train release. The driver uses the REST API to perform actions on the array. Such as creating a volume, downloading the image, mounting the volume to the instance, snapshots, clones etc. This is great for me because to date I have around 10TB of openstack storage data allocated and the Nimble array shows the amount of data being consumed is <900GB. This is due to the compression and zero-byte snapshots and clones. So coming back to question 2 – is it possible? Can you drop me some keywords that I can search for such as an Openstack component like Cheesecake? I think basically what I am looking for is a supported way of telling Openstack that the instance volumes are now located at the new / second array. This means a new cinder backend. Example, new iqn, IP address, volume serial number. I think I could probably hack the cinder db but I really want to avoid that. So failing the above, it brings me to the question 1 I asked before. How are people using Cinder volumes? May be I am going about this the wrong way and need to take a few steps backwards to go forwards? I need storage to be able to deploy instances onto. Snapshots and clones are desired. At the moment these operations take less time than the horizon dashboard takes to load because of the waiting API responses. When searching for information about the above as an end-user / consumer I get a bit concerned. Is it right that Openstack usage is dropping? There’s no web forum to post questions. The chatroom on freenode is filled with ~300 ghosts. Ask Openstack questions go without response. Earlier this week (before I found this mail list) I had to use facebook to report that the Openstack.org website had been hacked. Basically it seems that if you’re a developer that can write code then you’re in but that’s it. I have never been a coder and so I am somewhat stuck. Thanks in advance Sent from Mail<https://urldefense.proofpoint.com/v2/url?u=https-3A__go.microsoft.com_fwlin…> for Windows 10 _____________________________________________________________________ The information transmitted in this message and its attachments (if any) is intended only for the person or entity to which it is addressed. The message may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited. If you have received this in error, please contact the sender and delete this e-mail and associated material from any computer. The intended recipient of this e-mail may only use, reproduce, disclose or distribute the information contained in this e-mail and any attached files, with the permission of the sender. This message has been scanned for viruses. _____________________________________________________________________

6 6

[keystone] Keystone Team Update - Week of 13 January 2020
by Vishakha Agarwal 17 Jan '20

17 Jan '20

# Keystone Team Update - Week of 13 January 2020 ## News ### Roadmap Review The Team has decided to review the roadmap every other week so as to keep up the development momentum of the ussuri cycle [1]. [1] https://tree.taiga.io/project/keystone-ussuri-roadmap/kanban ### User Support and Bug Duty Every week the duty is being rotated between the members. The person-in-charge for bug duty for current and upcoming week can be seen on the etherpad [2] [2] https://etherpad.openstack.org/p/keystone-l1-duty ## 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 7 changes this week. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 36 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/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 https://review.opendev.org/#/c/697444/ Adding options to user cli https://review.opendev.org/#/c/702374/ Cleanup doc/requirements.txt ## Bugs This week we opened 2 new bugs and closed 4. Bugs opened (2) Bug #1859759 (keystone:Undecided): Keystone is unable to remove role-assignment for deleted LDAP users - Opened by Eigil Obrestad https://bugs.launchpad.net/keystone/+bug/1859759 Bug #1859844 (keystone:Undecided): Impossible to rename the Default domain id to the string 'default.' - Opened by Marcelo Subtil Marcal https://bugs.launchpad.net/keystone/+bug/1859844 Bugs closed (4) Bug #1833207 (keystoneauth:Undecided) https://bugs.launchpad.net/keystoneauth/+bug/1833207 Bug #1858189 (keystoneauth:Undecided) https://bugs.launchpad.net/keystoneauth/+bug/1858189 Bug #1857086 (keystone:Won't Fix) https://bugs.launchpad.net/keystone/+bug/1857086 Bug #1859844 (keystone:Invalid) https://bugs.launchpad.net/keystone/+bug/1859844 ## Milestone Outlook https://releases.openstack.org/ussuri/schedule.html Reminder for Spec freeze as it is on the week of 10 Feburary. ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

[all] cirros-cloud.net is down
by Radosław Piliszek 17 Jan '20

17 Jan '20

Hi, Folks! If your CI jobs depend on downloaded cirros image, then be aware that cirros links are seemingly permanently down atm. I reported [1] due to lack of a better place (that I know of). [1] https://github.com/cirros-dev/cirros/issues/12 -yoctozepto

2 2

[tc] January meeting agenda
by Jean-Philippe Evrard 16 Jan '20

16 Jan '20

Hello everyone, Our next meeting is happening next week Thursday (the 16th), and the agenda is, as usual, on the wiki! Here is a primer of the agenda for this month: - report on large scale sig -- how does this fly and how/what are the action items. - report on the vision reflection update - report on the analysis of the survey - report on the convo for Telemetry with Catalyst -- where are we now? What are the next steps (Gnocchi fork)? - report on multi-arch SIG - report on infra liaison and static hosting -- check if there is progress - report on stable branch policy work. - report on the oslo metrics project -- has code appeared since last convo? - report on the community goals for U and V, py2 drop, and goal select process schedule. - report on release naming - report on the ideas repo See you there! Regards, Jean-Philippe Evrard (evrardjp)

1 1