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

Re: [openstack-dev] Are we ready to put stable/ocata into extended maintenance mode?
by Alex Schultz 03 Mar '21

03 Mar '21

On Tue, Sep 18, 2018 at 1:30 PM Alex Schultz <aschultz(a)redhat.com> wrote: > > On Tue, Sep 18, 2018 at 1:27 PM, Matt Riedemann <mriedemos(a)gmail.com> wrote: > > The release page says Ocata is planned to go into extended maintenance mode > > on Aug 27 [1]. There really isn't much to this except it means we don't do > > releases for Ocata anymore [2]. There is a caveat that project teams that do > > not wish to maintain stable/ocata after this point can immediately end of > > life the branch for their project [3]. We can still run CI using tags, e.g. > > if keystone goes ocata-eol, devstack on stable/ocata can still continue to > > install from stable/ocata for nova and the ocata-eol tag for keystone. > > Having said that, if there is no undue burden on the project team keeping > > the lights on for stable/ocata, I would recommend not tagging the > > stable/ocata branch end of life at this point. > > > > So, questions that need answering are: > > > > 1. Should we cut a final release for projects with stable/ocata branches > > before going into extended maintenance mode? I tend to think "yes" to flush > > the queue of backports. In fact, [3] doesn't mention it, but the resolution > > said we'd tag the branch [4] to indicate it has entered the EM phase. > > > > 2. Are there any projects that would want to skip EM and go directly to EOL > > (yes this feels like a Monopoly question)? > > > > I believe TripleO would like to EOL instead of EM for Ocata as > indicated by the thead > http://lists.openstack.org/pipermail/openstack-dev/2018-September/134671.ht… > Bringing this backup to see what we need to do to get the stable/ocata branches ended for the TripleO projects. I'm bringing this up because we have https://review.openstack.org/#/c/647009/ which is for the upcoming rename but CI is broken and we have no interest in continue to keep the stable/ocata branches alive (or fix ci for them). Thanks, -Alex > Thanks, > -Alex > > > [1] https://releases.openstack.org/ > > [2] > > https://docs.openstack.org/project-team-guide/stable-branches.html#maintena… > > [3] > > https://docs.openstack.org/project-team-guide/stable-branches.html#extended… > > [4] > > https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.… > > > > -- > > > > Thanks, > > > > Matt > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

5 11

[swift] Adding disks - one by one or all lightly weighted?
by Mark Kirkwood 15 May '20

15 May '20

Hi, We are wanting to increase the number of disks in each of our storage nodes - from 4 to 12. I'm wondering whether it is better to: 1/ Add 1st new disk (with a reduced weight)...increase the weight until full, then repeat for next disk etc 2/ Add 'em all with a (much i.e 1/8 of that in 1/ ) reduced weight...increase the weights until done Thoughts? regards Mark

2 2

[Syntribos] Does anyone still use this?
by Gage Hugo 08 May '20

08 May '20

The Security SIG has recently been looking into updating several sites/documentation and one part we discussed the last couple meetings was the security tools listings[0]. One of the projects listed there, Syntribos, doesn't appear to have much activity[1] outside of zuul/python/docs maintenance and the idea of retiring the project was mentioned. However, there does seem to be an occasional bug-fix submitted, so we are sending this email out to see if anyone is still utilizing Syntribos. If so, please either respond here, reach out to us in the #openstack-security irc channel, or fill out the section in the Security SIG Agenda etherpad[2]. Thanks! [0] https://security.openstack.org/#security-tool-development [1] https://review.opendev.org/#/q/project:openstack/syntribos [2] https://etherpad.openstack.org/p/security-agenda

2 2

[openstack-ansible] dropping suse support
by Mohammed Naser 05 May '20

05 May '20

Hi everyone, I've been trying to avoid writing this email for the longest time ever. It's really painful to have to reach this state, but I think we've hit a point where we can no longer maintain support for SUSE within OpenStack Ansible. Unfortunately, with the recent layoffs, the OSA team has taken a huge hit in terms of contributors which means that there is far less contributors within the project. This means that we have less resources to go around and it forces us to focus on a more functional, reliable and well tested set of scenarios. Over the past few cycles, there has been effort to add SUSE support to OpenStack Ansible, during the time that we had maintainers, it was great and SUSE issues were being fixed promptly. In addition, due to the larger team at the time, we found ourselves having some extra time where we can help unbreak other gates. Jesse used to call this a "labour of love", which I admired at the time and hoped we continue to do as much as we can of. However, the lack of a committed maintainer for OpenSUSE has resulted in constantly failing jobs[1][2] (which were moved to non-voting, wasting CI resources as no one fixed them). In addition, it's causing several gate blocks for a few times with no one really finding the time to clean them up. We are resource constrained at this point and we need the resource to go towards making the small subset of supported features functional (i.e. CentOS/Ubuntu). We struggle with that enough, and there seems to be no deployers that are running SUSE in real life at the moment based on bugs submitted. With that, I propose that we drop SUSE support this cycle. If anyone would like to volunteer to maintain it, we can review that option, but that would require a serious commitment as we've had maintainers step off and it hurts the velocity of the project as no one can merge code anymore. ..Really wish I didn't have to write this email Mohammed [1]: http://zuul.opendev.org/t/openstack/builds?job_name=openstack-ansible-funct… [2]: http://zuul.opendev.org/t/openstack/builds?job_name=openstack-ansible-funct…

6 9

Re: [nova][cinder][ops] question/confirmation of legacy vol attachment migration
by Brett Milford 22 Apr '20

22 Apr '20

On Tue, Dec 10, 2019 at 11:15 PM Gorka Eguileor <geguileo(a)redhat.com> wrote: > > On 06/12, Brett Milford wrote: > > On Fri, Nov 22, 2019 at 3:54 AM Matt Riedemann <mriedemos(a)gmail.com> wrote: > > > > > > On 10/17/2019 5:24 AM, Gorka Eguileor wrote: > > > > I stand by my initial recommendation, being able to update the existing > > > > attachment to add the connection information from Nova. > > > > > > OK, thanks for the input and thoughtfulness on this. I've abandoned my > > > change since I'm not going to be pushing this boulder anymore but left > > > notes in the change in case someone else wants to pick it up some day. > > > > > > Note to nova cores: this means we'll have legacy volume attachment > > > compat code around forever. > > > > > > -- > > > > > > Thanks, > > > > > > Matt > > > > > > > Hi Groka, Cinder & Nova devs, > > > > Following up this thread from the context of > > https://review.opendev.org/#/c/579004/ > > > > To summarise the discussion: > > - initialize_connection shouldn't be called more than once, as it > > may mess up some drivers. > > - To (safely) refresh connection_info a new api for cinder is required. > > Hi, > > It may be a new API or a modification of one of the existing ones. > > > > - a patch to nova, such as #579004 could make a call to this new api > > to refresh connection info on events such as reboot. > > > > Is there any other context to this issue I've missed or an alternate > > path to solving this? > > > > Does the creation of a new api for cinder have any implications for > > being able to backport this patch for nova? > > > > I don't think backporting it in Nova would do us much good, since the > Cinder code would not be backportable (it's a new feature, not a bug > fix). > > > > What would be the process for me to kick off this work? > > > > You should propose a Cinder spec [1] for your work and you may provide a > WIP patch to Cinder at the same time, though depending on the review you > may have to completely change that code later. > > Cheers, > Gorka. > > [1]: https://opendev.org/openstack/cinder-specs > > > Thanks for your help, > > Brett (bcm) > > -- > > ❯ brett > > > Cheers Matt, Groka, I thought this might be the case. -- ❯ brett

2 2

[cinder][ops][extended-maintenance-sig][public-cloud-sig][enterprise-wg] Cinder to EOL some branches
by Brian Rosmaita 13 Apr '20

13 Apr '20

This is a courtesy notice that having received no responses to my email of 28 October [0] proposing to EOL some currently open Cinder branches, and following the policy articulated in [1], at today's Virtual PTG meeting the Cinder project team has decided to put the following stable branches into the End of Life state: driverfixes/mitaka driverfixes/newton stable/ocata stable/pike I will submit the paperwork to get this process moving one week from today (2 December 2019). cheers, brian [0] http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010385.… [1] https://docs.openstack.org/project-team-guide/stable-branches.html#end-of-l…

4 8

[neutron][OVN] Multiple mechanism drivers
by Sam Morrison 07 Apr '20

07 Apr '20

We are looking at using OVN and are having some issues with it in our ML2 environment. We currently have 2 mechanism drivers in use: linuxbridge and midonet and these work well (midonet is the default tenant network driver for when users create a network) Adding OVN as a third mechanism driver causes the linuxbridge and midonet networks to stop working in terms of CRUD operations etc. It looks as if the OVN driver thinks it’s the only player and is trying to do things on ports that are in linuxbridge or midonet networks. Am I missing something here? (We’re using Stein version) Thanks, Sam

5 6

[ptl][release][stable][EM] Extended Maintenance - Rocky
by Elõd Illés 27 Feb '20

27 Feb '20

Hi, In less than one month Rocky is planned to enter into Extended Maintenance phase [1] (estimated date: 2020-02-24). I have generated the list of *open* and *unreleased* changes in *stable/rocky* for the follows-policy tagged repositories [2]. These lists could help the teams, who are planning to do a final release on Rocky before moving stable/rocky branches to Extended Maintenance. Feel free to edit them! * At the transition date the Release Team will tag the latest (Rocky) releases of repositories with *rocky-em* tag. * After the transition stable/rocky will be still open for bugfixes, but there won't be any official releases. NOTE: teams, please focus on wrapping up your libraries first if there is any concern about changes, in order to avoid any broken releases! Thanks, Előd [1] https://releases.openstack.org/ [2] https://etherpad.openstack.org/p/rocky-final-release-before-em

4 5

[ops] nova wsgi config
by Arnaud Morin 27 Feb '20

27 Feb '20

Hey all, I am trying to configure apache as a WSGI. Is there any other documentation than this: https://docs.openstack.org/nova/stein/user/wsgi.html Is there any recommendations? Thanks in advance! -- Arnaud Morin

4 7

[tripleo] missing centos-8 rpms for kolla builds
by Wesley Hayutin 26 Feb '20

26 Feb '20

Greetings, I know the ceph repo is in progress. TripleO / RDO is not releasing opendaylight Can the RDO team comment on the rest of the missing packages here please? Thank you!! https://review.opendev.org/#/c/699414/9/kolla/image/build.py NOTE(mgoddard): Mark images with missing dependencies as unbuildable for # CentOS 8. 'centos8': { "barbican-api", # Missing uwsgi-plugin-python3 "ceph-base", # Missing Ceph repo "cinder-base", # Missing Ceph repo "collectd", # Missing collectd-ping and # collectd-sensubility packages "elasticsearch", # Missing elasticsearch repo "etcd", # Missing etcd package "fluentd", # Missing td-agent repo "glance-base", # Missing Ceph repo "gnocchi-base", # Missing Ceph repo "hacluster-base", # Missing hacluster repo "ironic-conductor", # Missing shellinabox package "kibana", # Missing elasticsearch repo "manila-share", # Missing Ceph repo "mongodb", # Missing mongodb and mongodb-server packages "monasca-grafana", # Using python2 "nova-compute", # Missing Ceph repo "nova-libvirt", # Missing Ceph repo "nova-spicehtml5proxy", # Missing spicehtml5 package "opendaylight", # Missing opendaylight repo "ovsdpdk", # Not supported on CentOS "sensu-base", # Missing sensu package "tgtd", # Not supported on CentOS 8 }, 'centos8+source': { "barbican-base", # Missing uwsgi-plugin-python3 "bifrost-base", # Bifrost does not support CentOS 8 "cyborg-agent", # opae-sdk does not support CentOS 8 "freezer-base", # Missing package trickle "masakari-monitors", # Missing hacluster repo "zun-compute", # Missing Ceph repo

9 19

[all][neutron][neutron-fwaas] Maintainers needed
by Slawek Kaplonski 20 Feb '20

20 Feb '20

Hi, Over the past couple of cycles we have noticed that new contributions and maintenance efforts for neutron-fwaas project were almost non existent. This impacts patches for bug fixes, new features and reviews. The Neutron core team is trying to at least keep the CI of this project healthy, but we don’t have enough knowledge about the details of the neutron-fwaas code base to review more complex patches. During the PTG in Shanghai we discussed that with operators and TC members during the forum session [1] and later within the Neutron team during the PTG session [2]. During these discussions, with the help of operators and TC members, we reached the conclusion that we need to have someone responsible for maintaining project. This doesn’t mean that the maintainer needs to spend full time working on this project. Rather, we need someone to be the contact person for the project, who takes care of the project’s CI and review patches. Of course that’s only a minimal requirement. If the new maintainer works on new features for the project, it’s even better :) If we don’t have any new maintainer(s) before milestone Ussuri-2, which is Feb 10 - Feb 14 according to [3], we will need to mark neutron-fwaas as deprecated and in “V” cycle we will propose to move the project from the Neutron stadium, hosted in the “openstack/“ namespace, to the unofficial projects hosted in the “x/“ namespace. So if You are using this project now, or if You have customers who are using it, please consider the possibility of maintaining it. Otherwise, please be aware that it is highly possible that the project will be deprecated and moved out from the official OpenStack projects. [1] https://etherpad.openstack.org/p/PVG-Neutron-stadium-projects-the-path-forw… [2] https://etherpad.openstack.org/p/Shanghai-Neutron-Planning-restored - Lines 379-421 [3] https://releases.openstack.org/ussuri/schedule.html -- Slawek Kaplonski Senior software engineer Red Hat

8 14

[vmware][hyperv][kolla] Is there any interest? (or should we deprecate and remove?)
by Radosław Piliszek 19 Feb '20

19 Feb '20

Hello Fellow Stackers, In Kolla and Kolla-Ansible we have some support for VMware (both hypervisor and networking controller stuff) and Hyper-V. The issue is the relevant code is in pretty bad shape and we had no recent reports about these being used nor working at all for that matter and we are looking into dropping support for these. Please respond if you are interested in these. Long term we would require access to some CI running these to really keep things in shape. -yoctozepto

1 1

[qa][stable][tempest-plugins]: Tempest & plugins py2 jobs failure for stable branches (1860033: the EOLing python2 drama)
by Ghanshyam Mann 09 Feb '20

09 Feb '20

Hello Everyone, This is regarding bug: https://bugs.launchpad.net/tempest/+bug/1860033. Using Radosław's fancy statement of 'EOLing python2 drama' in subject :). neutron tempest plugin job on stable/rocky started failing as neutron-lib dropped the py2. neutron-lib 2.0.0 is py3 only and so does u-c on the master has been updated to 2.0.0. All tempest and its plugin uses the master u-c for stable branch testing which is the valid way because of master Tempest & plugin is being used to test the stable branches which need u-c from master itself. These failed jobs also used master u-c[1] which is trying to install the latest neutron-lib and failing. This is not just neutron tempest plugin issue but for all Tempest plugins jobs. Any lib used by Tempest or plugins can drop the py2 now and leads to this failure. Its just neutron-lib raised the flag first before I plan to hack on Tempest & plugins jobs for py2 drop from master and kepe testing py2 on stable bracnhes. We have two way to fix this: 1. Separate out the testing of python2 jobs with python2 supported version of Tempest plugins and with respective u-c. For example, test all python2 job with tempest plugin train version (or any latest version if any which support py2) and use u-c from stable/train. This will cap the Tempest & plugins with respective u-c for stable branches testing. 2. Second option is to install the tempest and plugins in py3 env on py2 jobs also. This should be an easy and preferred way. I am trying this first[2] and testing[3]. [1] https://zuul.opendev.org/t/openstack/build/fb8a928ed3614e09a9a3cf4637f2f6c2… [2] https://review.opendev.org/#/c/703011/ [3] https://review.opendev.org/#/c/703012/ -gmanne

5 17

[all] Nominations for the "W" release name
by Sean McGinnis 07 Feb '20

07 Feb '20

Hello all, We get to be a little proactive this time around and get the release name chosen for the "W" release. Time to start thinking of good names again! Process Changes --------------- There are a couple of changes to be aware of with our naming process. In the past, we had always based our naming criteria on something geographically local to the Summit location. With the event changes to no longer have two large Summit-type events per year, we have tweaked our process to open things up and make it hopefully a little easier to pick a good name that the community likes. There are a couple of significant changes. First, names can now be proposed for anything that starts with the appropriate letter. It is no longer tied to a specific geographic region. Second, in order to simplify the process, the electorate for the poll will be the OpenStack Technical Committee. Full details of the release naming process can be found here: https://governance.openstack.org/tc/reference/release-naming.html Name Selection -------------- With that, the nomination period for the "W" release name is now open. Please add suitable names to: https://wiki.openstack.org/wiki/Release_Naming/W_Proposals We will accept nominations until February 7, 202 at 23:59:59 UTC. We will then have a brief period for any necessary discussions and to get the poll set up, with the TC electorate voting starting by February 17, 2020 and going no longer than February 23, 2020. Based on past timing with trademark and copyright reviews, we will likely have an official release name by mid to late March. Happy naming! Sean

2 2

[all][requirements][monasca][gnocchi] ujson, not maintained for over 4 years, has compiler issues
by Radosław Piliszek 06 Feb '20

06 Feb '20

This is a spinoff discussion of [1] to attract more people. As the subject goes, the situation of ujson is bad. Still, monasca and gnocchi (both server and client) seem to be using it which may break depending on compiler. The original issue is that the released version of ujson is in non-spec-conforming C which may break randomly based on used compiler and linker. There has been no release of ujson for more than 4 years. Based on general project activity, Monasca is probably able to fix it but Gnocchi not so surely... [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-January/thread.… -yoctozepto

5 10

[ops][cinder] Moving volume to new type
by Jonathan Proulx 06 Feb '20

06 Feb '20

Hi All, I'm currently languishing on Mitaka so perhaps further back than help can reach but...if anyone can tell me if this is something dumb I'm doing or a know bug in mitaka that's preventing me for movign volumes from one type to anyother it'd be a big help. In the further past I did a cinder backend migration by creating a new volume type then changing all the existign volume sto the new type. This is how we got from iSCSI to RBD (probably in Grizzly or Havana). Currently I'm starting to move from one RBD pool to an other and seems like this should work in the same way. Both pools and types exist and I can create volumes in either but when I run: openstack volume set --type ssd test-vol it rather silently fails to do anything (CLI returns 0), looking into schedulerlogs I see: # yup 2 "hosts" to check DEBUG cinder.scheduler.base_filter Starting with 2 host(s) get_filtered_objects DEBUG cinder.scheduler.base_filter Filter AvailabilityZoneFilter returned 2 host(s) get_filtered_objects DEBUG cinder.scheduler.filters.capacity_filter Space information for volume creation on host nimbus-1@ssdrbd#ssdrbd (requested / avail): 8/47527.78 host_passes DEBUG cinder.scheduler.base_filter Filter CapacityFilter returned 2 host(s) get_filtered_objects /usr/lib/python2.7/dist-packages/cinder/scheduler/base DEBUG cinder.scheduler.filters.capabilities_filter extra_spec requirement 'ssdrbd' does not match 'rbd' _satisfies_extra_specs /usr/lib/python2.7/dist- DEBUG cinder.scheduler.filters.capabilities_filter host 'nimbus-1@rbd#rbd': free_capacity_gb: 71127.03, pools: None fails resource_type extra_specs req DEBUG cinder.scheduler.base_filter Filter CapabilitiesFilter returned 1 host(s) get_filtered_objects /usr/lib/python2.7/dist-packages/cinder/scheduler/ # after filtering we have one DEBUG cinder.scheduler.filter_scheduler Filtered [host 'nimbus-1@ssdrbd#ssdrbd': free_capacity_gb: 47527.78, pools: None] _get_weighted_candidates # but it fails? ERROR cinder.scheduler.manager Could not find a host for volume 49299c0b-8bcf-4cdb-a0e1-dec055b0e78c with type bc2bc9ad-b0ad-43d2-93db-456d750f194d. successfully creating a volume in ssdrbd is identical to that point, except rather than ERROR on the last line it goes to: # Actually chooses 'nimbus-1@ssdrbd#ssdrbd' as top host DEBUG cinder.scheduler.filter_scheduler Filtered [host 'nimbus-1@ssdrbd#ssdrbd': free_capacity_gb: 47527.8, pools: None] _get_weighted_candidates DEBUG cinder.scheduler.filter_scheduler Choosing nimbus-1@ssdrbd#ssdrbd _choose_top_host # then goes and makes volume DEBUG oslo_messaging._drivers.amqpdriver CAST unique_id: 1b7a9d88402a41f8b889b88a2e2a198d exchange 'openstack' topic 'cinder-volume' _send DEBUG cinder.scheduler.manager Task 'cinder.scheduler.flows.create_volume.ScheduleCreateVolumeTask;volume:create' (e70dcc3f-7d88-4542-abff-f1a1293e90fb) transitioned into state 'SUCCESS' from state 'RUNNING' with result 'None' _task_receiver Anyone recognize this situation? Since I'm retiring the old spinning disks I can also "solve" this on the Ceph side by changing the crush map such that the old rbd pool just picks all ssds. So this isn't critical, but in the transitional period until I have enough SSD capacity to really throw *everything* over, there are some hot spot volumes it would be really nice to move this way. Thanks, -Jon

2 1

Help Shape the Track Content for OpenDev + PTG, June 8-11 in Vancouver
by Ashlee Ferguson 05 Feb '20

05 Feb '20

Hi everyone, Hopefully by now you’ve heard about our upcoming event, OpenDev + PTG Vancouver, June 8-11, 2020 <https://opendevptg2020.eventbrite.com/>. We need your help shaping this event! Our vision is for the content to be programmed by you-- the community. OSF is looking to kick things off by selecting members for OpenDev Programming Committees for each Track. That Program Committee will then select Moderators who will lead interactive discussions on a particular topic within the track. Below you'll have the opportunity to nominate yourself for a position on the Programming Committee, as a Moderator, or both, as well as suggesting specific Topics within each Track. PTG programming will kick off in the coming weeks. If you’re interested in volunteering as an OpenDev Programming Committee member, discussion Moderator, or would like to suggest topics for moderated discussions within a particular Track, please read the details below, and then fill out this form <https://openstackfoundation.formstack.com/forms/opendev_vancouver2020_volun…>. We’re looking for subject matter experts on the following OpenDev Tracks: - Hardware Automation (accelerators, provisioning hardware, networking) - Large-scale Usage of Open Source Infrastructure Software (scale pain points, multi-location, CI/CD) - Containers in Production (isolation, virtualization, telecom containers) - Key Challenges for Open Source in 2020 (beyond licensing, public clouds, ethics) OpenDev Programming Committee members will: Work with other Committee members, which will include OSF representatives, to curate OpenDev content based on subject expertise, community input, and relevance to open source infrastructure Promote the individual Tracks within your networks Review community input and suggestions for Track discussions Solicit moderators from your network if you know someone who is a subject matter expert Ensure diversity of speakers and companies represented in your Track Focus topics around on real-world user stories and technical, in-the-trenches experiences Programming Committee members need to be available during the following dates/time commitments: 8 - 10 hours from February - May for bi-weekly calls with your Track's Programming Committee (plus a couple of OSF representatives to facilitate the call) OpenDev, June 8 - 10, 2020 (not required, but preferred) Programming Committee members will receive a complimentary pass to the event Programming Committees will be comprised of a few people per Track who will work to select a handful of topics and moderators for each Track. The exact topic counts will be determined before Committees begin deciding. OpenDev Discussion Moderators will Be appointed by the Programming Committees Facilitate discussions within a particular Track Have adequate knowledge and experience to lead and moderate discussion around certain topics during the event Work with Programming Committee to decide focal point of discussion Moderators need to be available to attend OpenDev, June 8 - 10, 2020, and will receive a complimentary pass. Programming Committee nominations are open until February 11. Deadlines to volunteer to be a moderator and suggest topics will be in late February. Nominate yourself or suggest discussion topics here: https://openstackfoundation.formstack.com/forms/opendev_vancouver2020_volun… <https://openstackfoundation.formstack.com/forms/opendev_vancouver2020_volun…> Cheers, The OpenStack Foundation

1 1

[magnum] Help / Pointers on mirroring https://opendev.org/starlingx in github.com for CNCF certification of starlingx
by Waines, Greg 05 Feb '20

05 Feb '20

Hello, I am working in the OpenStack StarlingX team. We are working on getting StarlingX certified through the CNCF conformance program, https://www.cncf.io/certification/software-conformance/ . ( in the same way that you guys, OpenStack Magnum project, got certified with CNCF ) As you know, in order for the logo to be shown as based on open-source, CNCF requires that the code be mirrored on github.com . e.g. https://github.com/openstack/magnum The openstack foundation guys did provide some info on how to do this: The further steps for the project owner to take: * create a dedicated account for zuul * create the individual empty repos * add a job to each repo to do the mirroring, like: * https://opendev.org/airship/deckhand/src/commit/51dcea4fa12b0bcce65c381c286… Also, you can find documentation for the parent job here: https://zuul-ci.org/docs/zuul-jobs/general-jobs.html#job-upload-git-mirror ... maybe it’s cause I don’t know anything about zuul jobs, but these instructions are not super clear to me. Is the person who did this for magnum available to provide some more detailed instructions or help on doing this ? Let me know ... any help is much appreciated, Greg.

3 2

[kuryr] Deprecation of Ingress support and namespace isolation
by Michał Dulko 04 Feb '20

04 Feb '20

Hi, I've decided to put up a patch [1] deprecating the aforementioned features. It's motivated by the fact that there are better ways to do both: * Ingress can be done by another controller or through cloud provider. * Namespace isolation can be achieved through network policies. Both alternative ways are way better tested and there's nobody maintaining the deprecated features. I'm open to keep them if someone using them steps up. With the fact that Kuryr seems to be tied more with Kubernetes releases than with OpenStack ones and given there will be no objections, we might start removing the code in the Ussuri timeframe. [1] https://review.opendev.org/#/c/703420/ Thanks, Michał

2 1

[cinder][ci] Cinder drivers being Unsupported and General CI Status ...
by Jay Bryant 04 Feb '20

04 Feb '20

All, We once again are at the point in the release where we are talking about 3rd Party CI and what is going on for Cinder. At the moment I have analyzed drivers that have not successfully reported results on a Cinder patch in 30 or more days and have put together the following list of drivers to be unsupported in the Ussuri release: * Inspur Drivers * Infortrend * Kaminario * NEC * Quobyte * Zadara * HPE Drivers If your name is in the list above you are receiving this e-mail directly, not just through the mailing list. If you are working on resolving CI issues please let me know so we can discuss how to proceed. In addition to the fact that we will be pushing up unsupported patches for the drivers above, we have already unsupported and removed a number of drivers during this release. They are as follows: * Unsupported: o MacroSAN Driver * Removed: o ProphetStor Driver o Nimble Storage Driver o Veritas Access Driver o Veritas CNFS Driver o Virtuozzo Storage Driver o Huawei FusionStorage Driver o Sheepdog Storage Driver Obviously we are reaching the point that the number of drivers leaving the community is concerning and it has sparked discussions around the fact that maybe our 3rd Party CI approach isn't working as intended. So what do we do? Just mark drivers unsupported and no longer remove drivers? Do we restore drivers that have recently been removed? We are planning to have further discussion around these questions at our next Cinder meeting in #openstack-meeting-4 on Wednesday, 1/29/20 at 14:00 UTC. If you have thoughts or strong opinions around this topic please join us. Thank you! Jay Bryant jsbryant(a)electronicjungle.net IRC: jungleboyj

7 8

[qa] Proposing Radosław Piliszek to devstack core
by Ghanshyam Mann 03 Feb '20

03 Feb '20

Hello Everyone, Radosław Piliszek (yoctozepto) has been doing nice work in devstack from code as well as review perspective. He has been helping for many bugs fixes nowadays and having him as Core will help us to speed up the things. I would like to propose him for Devstack Core. You can vote/feedback on this email. If no objection by end of this week, I will add him to the list. -gmann

4 4

[Watcher] confused about meeting schedule
by info＠dantalion.nl 03 Feb '20

03 Feb '20

Hello everyone, The documentation for Watcher states that meetings will be held on a bi-weekly basis on odd-weeks, however, last meeting was held on the 8th of January which is not an odd-week. Today I was expecting a meeting as the meetings are held bi-weekly and the last one was held on the 8th of January, however, there was none. Can someone clarify when the next meeting will be held and the subsequent one after that? If these are on even weeks we should also update Watcher's documentation. Kind regards, Corne lukken

3 4

Kayobe Openstack deployment
by Tony Pearce 03 Feb '20

03 Feb '20

Hi all - I wanted to ask if there was such a reference architecture / step-by-step deployment guide for Openstack / Kayobe that I could follow to get a better understanding of the components and how to go about deploying it? The documentation is not that great so I'm hitting various issues when trying to follow what is there on the Openstack site. There's a lot of technical things like information on variables - which is fantastic, but there's no context about them. For example, the architecture page is pretty small, when you get further on in the guide it's difficult to contextually link detail back to the architecture. I tried to do the all-in-one deployment as well as the "universe from nothing approach" but hit some issues there as well. Plus it's kind of like trying to learn how to drive a bus by riding a micro-scooter :) Also, the "report bug" bug link on the top of all the pages is going to an error "page does not exist" - not sure that had been realised yet. Regards, *Tony Pearce* | *Senior Network Engineer / Infrastructure Lead**Cinglevue International <https://www.cinglevue.com>* Email: tony.pearce(a)cinglevue.com Web: http://www.cinglevue.com *Australia* 1 Walsh Loop, Joondalup, WA 6027 Australia. Direct: +61 8 6202 0036 | Main: +61 8 6202 0024 Note: This email and all attachments are the sole property of Cinglevue International Pty Ltd. (or any of its subsidiary entities), and the information contained herein must be considered confidential, unless specified otherwise. If you are not the intended recipient, you must not use or forward the information contained in these documents. If you have received this message in error, please delete the email and notify the sender.

2 3

[kolla] ujson issue affected to few containers.
by Eddie Yen 03 Feb '20

03 Feb '20

Hi everyone, I'm not sure it should be bug report or not. So I email out about this issue. In these days, I found the Rocky source deployment always failed at Ceilometer bootstrapping. Then I found it failed at ceilometer-upgrade. So I tried to looking at ceilometer-upgrade.log and the error shows it failed to import ujson. https://pastebin.com/nGqsM0uf Then I googled it and found this issue is already happened and released fixes. https://github.com/esnme/ultrajson/issues/346 But it seems like the container still using the questionable one, even today (Jan 30 UTC+8). And this not only affected to Ceilometer, but may also Gnocchi. I think we have to patch it, but not sure about the workaround. Does anyone have good idea? Many thanks, Eddie.

3 9

[nova] I would like to add another option for cross_az_attach
by Kim KS 02 Feb '20

02 Feb '20

Hello all, In nova with setting [cinder]/ cross_az_attach option to false, nova creates instance and volume in same AZ. but some of usecase (in my case), we need to attach new volume in different AZ to the instance. so I need two options. one is for nova block device mapping and attaching volume and another is for attaching volume in specified AZ. [cinder] cross_az_attach = False enable_az_attach_list = AZ1,AZ2 how do you all think of it? Best, Kiseok

4 4

[cinder] last call for ussuri spec comments
by Brian Rosmaita 01 Feb '20

01 Feb '20

The following specs have two +2s. I believe that all expressed concerns have been addressed. I intend to merge them at 22:00 UTC today unless a serious issue is raised before then. https://review.opendev.org/#/c/684556/ - support volume-local-cache https://review.opendev.org/#/c/700977 - add backup id to volume metadata cheers, brian

3 3

"encoding error when doing console log show" in Rocky
by Albert Braden 01 Feb '20

01 Feb '20

We're running openstack-ansible Rocky and seeing the "encoding error when doing console log show." I see here that there is a patch: https://bugs.launchpad.net/python-openstackclient/+bug/1747862 How can I apply this patch to our Rocky install? Do I need to just copy the file over the existing /usr/lib/python2.7/dist-packages/openstackclient/compute/v2/console.py on controllers and hypervisors? Or is there a better way?

2 13

[tripleo] no rechecks
by Wesley Hayutin 01 Feb '20

01 Feb '20

Greetings, Hey folks we need a few patches to land before it's safe to blindly recheck. A few minor patches need to land before you can expect to get +1 from zuul in a lot of cases. We appreciate your patience while we resolve the issues. Thanks * TRIPLEO GATES ARE BROKEN* * need two patches to fix - * https://review.opendev.org/#/c/705051/ - * https://review.opendev.org/#/c/704885/ - * Also need - * https://review.rdoproject.org/r/#/c/24754/

1 1

[all][requirements][qa] zipp failing py3.5 again
by Radosław Piliszek 01 Feb '20

01 Feb '20

Folks, we are running circles here. [1] merged breaking zipp again for py3.5 The script which generates these proposals needs to learn python version constraints. Reproposed [2]. [1] https://review.opendev.org/705128 [2] https://review.opendev.org/705184 -yoctozepto

3 4

[ironic] An approach to removing WSME
by Steve Baker 31 Jan '20

31 Jan '20

I've put together a set of changes for removing WSME which involves copying just enough of it into ironic, and I think we need to have the conversation about whether this approach is desirable :) This git branch[1] finishes with WSME removed and existing tests passing. Here are some stats about lines of code (not including unit tests, calculated with cloc): 4500 wsme/wsme 6000 ironic/ironic/api master 7000 ironic/ironic/api story/1651346 In words, we need 1000 out of 4500 lines of WSME source in order to support 6000 lines of ironic specific API code. Switching to a replacement for WSME would likely touch a good proportion of that 6000 lines of ironic specific API code. If we eventually replace it with a new library I think it would be easier if the thing being replaced is inside the ironic source tree to allow for a gradual transition. So this approach could be an end in itself, or it could be a step towards the final goal. My strategy for copying in code was to pull in chunks of required logic while removing some unused features (like request pass-through and date & time type serialization). I also replaced py2/3 patterns with pure py3. There is likely further things which can be removed or refactored for simplicity, but what exists currently works. If there is enough positive feedback for this approach I'll start on unit test coverage for the new code. [1] https://review.opendev.org/#/q/topic:story/1651346

3 2

[oslo] AFK this week
by Ben Nemec 31 Jan '20

31 Jan '20

I am going to be out most or all of this week. If someone wants to run the meeting on Monday then feel free to have it without me again. I may not be back right away next week either. A lot of stuff is still to be determined at this point. -Ben

1 1

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

31 Jan '20

# Keystone Team Update - Week of 27 January 2020 ## News ### 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 [1] [1] 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 19 changes this week. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 26 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ### Priority Reviews * Ussuri Roadmap Stories - Groups in keystone SAML assertion https://tree.taiga.io/project/keystone-ussuri-roadmap/us/33 https://review.opendev.org/#/c/588211/ Add openstack_groups to assertion - Add support for modifying resource options to CLI tool https://tree.taiga.io/project/keystone-ussuri-roadmap/us/53 https://review.opendev.org/#/c/697444/ Adding options to user cli * Community Goals https://review.opendev.org/#/c/699119/ [ussuri][goal] Drop python 2.7 support and testing python-keystoneclient * Special Requests https://review.opendev.org/#/c/703578/ Updating tox -e all-plugin command https://review.opendev.org/#/c/704736/ Remove six usage ## Bugs This week we opened 4 new bugs and closed 4. Bugs opened (4) Bug #1860478 (keystone:Low): fetching role assignments should handle domain IDs in addition to project IDs - Opened by Harry Rybacki https://bugs.launchpad.net/keystone/+bug/1860478 Bug #1860252 (keystone:Undecided): security problem，one user can change other user's password without admin - Opened by kuangpeiling https://bugs.launchpad.net/keystone/+bug/1860252 Bug #1861264 (keystone:Undecided): Help information should be returned when executing 'placement-status' alone - Opened by Eric Xie https://bugs.launchpad.net/keystone/+bug/1861264 Bug #1861279 (keystone:Undecided): incomplete instruction in "Install and configure" in keystone in https://docs.openstack.org/keystone/train/install/keystone-install-rdo.html - Opened by Arie Maron https://bugs.launchpad.net/keystone/+bug/1861279 Bugs closed (4) Bug #1860252 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1860252 Bug #1861264 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1861264 Bug #1856904 (keystone:Undecided): CADF Notifications are missing user name in initiator object - Fixed by Gage Hugo https://bugs.launchpad.net/keystone/+bug/1856904 Bug #1858012 (keystone:Undecided): List role assignments by role ID may leak extra system assignments outside of filter - Fixed by Colleen Murphy https://bugs.launchpad.net/keystone/+bug/1858012 ## Milestone Outlook https://releases.openstack.org/ussuri/schedule.html Milestone 2 is in two weeks, which means spec freeze is coming up followed closely by feature proposal freeze. ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

[cinder][nova] Migrating servers' root block devices from a cinder backend to another
by Jean-Philippe Méthot 31 Jan '20

31 Jan '20

Hi, We have a several hundred VMs which were built on cinder block devices as root drives which use a SAN backend. Now we want to change their backend from the SAN to Ceph. We can shutdown the VMs but we will not destroy them. I am aware that there is a cinder migrate volume command to change a volume’s backend, but it requires that the volume be completely detached. Forcing a detached state on that volume does let the volume migration take place, but the volume’s path in Nova block_device_mapping doesn’t update, for obvious reasons. So, I am considering forcing the volumes to a detached status in Cinder and then manually updating the nova db block_device_mapping entry for each volume so that the VM can boot back up afterwards. However, before I start toying with the database and accidentally break stuff, has anyone else ever done something similar? Got any tips or hints on how best to proceed? Jean-Philippe Méthot Openstack system administrator Administrateur système Openstack PlanetHoster inc.

7 10

[openstack-ansible][ansible-sig][tripleo] Openstack Ansible modules - update on progress, new meeting time
by Sagi Shnaidman 30 Jan '20

30 Jan '20

Hi, all because no people have been available in the meeting, I'll write a quick summary in ML. Agenda and progress are tracked here as usual: https://etherpad.openstack.org/p/openstack-ansible-modules 1. Because people had overlapping meetings I've created a poll for better meeting time. I think we can switch now to the bi-weekly meeting if no objections to it. The poll is here: https://xoyondo.com/dp/ITMGRZSvaZaONcz 2. We have the same coverage as we had in Ansible repository, so now we can start to improve our testing. It should include a matrix with various ansible versions and openstacksdk versions. We had already some issues with versions mismatch [1] Also we should start to do a better module design. 3. In case of critical patches to 2.9 and when openstack modules will be removed from Ansible repo, please submit patches directly to the 2.9-stable branch of Ansible. Confirmed that with Ansible folks. 4. The CI job in Ansible repository now is failing with a message about moving modules. I hope it won't block from 2.9 patches to land but will do more checking. But at least we've got attention to the fact modules are moving. 5. Jobs for pushing collections to ansible-galaxy are in progress and please review patches in the repo in your time: [1] https://review.opendev.org/705054 [2] https://review.opendev.org/#/q/project:openstack/ansible-collections-openst… -- Best regards Sagi Shnaidman

1 0

[ops] Federated Identity Management survey
by Colleen Murphy 30 Jan '20

30 Jan '20

Hello operators, A researcher from the University of Kent who was influential in the design of keystone's federation implementation has asked the keystone team to gauge adoption of federated identity management in OpenStack deployments. This is something we've neglected to track well in the last few OpenStack user surveys, so I'd like to ask OpenStack operators to please take a few minutes to complete the following survey about your usage of identity federation in your OpenStack deployment (even if you don't use federation): https://uok.typeform.com/to/KuRY0q The results of this survey will benefit not only university research but also the keystone team as it will help us understand where to focus our efforts. Your participation is greatly appreciated. Thanks for your time, Colleen (cmurphy)

1 3

[neutron][drivers team] Proposing Nate Johnston as drivers team member
by Slawek Kaplonski 30 Jan '20

30 Jan '20

Hi Neutrinos, I would like to propose Nate Johnston to be part of Neutron drivers team. Since long time Nate is very active Neutron's core reviewer. He is also actively participating in our Neutron drivers team meetings and he shown there that he has big experience and knowledge about Neutron, Neutron stadium projects as well as whole OpenStack. I think that he really deservers to be part of this team and that he will be great addition it. I will wait for Your feedback for 1 week and if there will be no any votes agains, I will add Nate to drivers team in next week. -- Slawek Kaplonski Senior software engineer Red Hat

5 5

[nova] API updates week 20-5
by Ghanshyam Mann 30 Jan '20

30 Jan '20

Hello Everyone, Please find the Nova API updates of this week. Please add if I missed any BPs/API related work. API Related BP : ============ COMPLETED: 1. Add image-precache-support spec: - https://blueprints.launchpad.net/nova/+spec/image-precache-support Code Ready for Review: ------------------------------ 1. Nova API policy improvement - Topic: https://review.opendev.org/#/q/topic:bp/policy-defaults-refresh+(status:ope… - Weekly Progress: First set is merged and 4 APIs policy are ready to review. I will push more changes in this week. - Review guide over ML - http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008504.h… Specs are merged and code in-progress: ------------------------------ ------------------ 1. Non-Admin user can filter their instance by availability zone: - Topic: https://review.opendev.org/#/q/topic:bp/non-admin-filter-instance-by-az+(st… - Weekly Progress: Spec is just merged. 2. Boot from volume instance rescue - Topic: https://review.opendev.org/#/q/topic:bp/virt-bfv-instance-rescue+(status:op… - Weekly Progress: Code is in progress. WIP as of now. Spec Ready for Review or Action from Author: --------------------------------------------------------- 1. Support specifying vnic_type to boot a server -Spec: https://review.opendev.org/#/c/672400/ - Weekly Progress: As discussed in spec, this is something can be done via heat or other automation instead of doing it in nova. 2. Add action event fault details -Spec: https://review.opendev.org/#/c/699669/ - Weekly Progress: This seems good to go, it has two +2. 3. Allow specify user to reset password -Spec: https://review.opendev.org/#/c/682302/5 - Weekly Progress: One +2 on this but other are disagree on this idea. More discussion on review. 4. Support re-configure deleted_on_termination in server -Spec: https://review.openstack.org/#/c/580336/ - Weekly Progress: This is old spec and there is no consensus on this till now. Others: 1. None Bugs: ==== I will track the bug data from next report. NOTE- There might be some bug which is not tagged as 'api' or 'api-ref', those are not in the above list. Tag such bugs so that we can keep our eyes. -gmann

1 0

[NOVA] instance hostname vs display_name vs dns_name
by Volodymyr Litovka 30 Jan '20

30 Jan '20

Dear colleagues, I'm using DNS Integration and just faced an issue - after renaming instance, I can't bind port to the instance using new name: 1) I've created intances with name 'devel' 2) then I renamed it to devel (openstack server set --name packager devel) 3) when binding port with dns_name using new name ('packager' in my case), the following error appear: ERROR nova.api.openstack.wsgi PortNotUsableDNS: Port c3a92cf6-b49b-4570-b69b-0c23af1d1f94 not usable for instance 6aa78bd5-099e-4878-a5ac-90262505a924. Value packager assigned to dns_name attribute does not match instance's hostname devel and yes, record in DB still uses an old hostname: mysql> select display_name from instances where hostname='devel'; +--------------+ | display_name | +--------------+ | packager | +--------------+ 1 row in set (0.00 sec) and hostname remains the same (initial) regardless of any changes to display_name. I'm on Rocky. Is it bug or feature and are there ways to work around this? Thank you. -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

2 2

[goals][Drop Python 2.7 Support] Week R-15 Update (# 2.5 weeks left to complete)
by Ghanshyam Mann 30 Jan '20

30 Jan '20

Hello Everyone, Below is the progress on "Drop Python 2.7 Support" for R-15 week. Schedule: https://governance.openstack.org/tc/goals/selected/ussuri/drop-py27.html#sc… Highlights: ======== * Schedule is to finish the py2-drop from every deliverable (except requirement repo) by m-2 on R13. Only 2.5 weeks left to finish the work. * There are still cases where Tempest and plugins does not work due to py2 drops. New plan & option has been sent in separate ML thread [1] and work in progress. * Few services merged the patches but not all. If your project is in the below list, I request PTLs to review it on priority. Project wise status and need reviews: ============================ Phase-1 status: The OpenStack services have not merged the py2 drop patches: NOTE: This was supposed to be completed by milestone-1 (Dec 13th, 19). * Adjutant * Karbor * Masakari * Tacker * Qinling * Tricircle Phase-2 status: This is ongoing work and I think most of the repo have patches up to review. Try to review them on priority. If any query and I missed to respond on review, feel free to ping me in irc. * Open review: https://review.opendev.org/#/q/topic:drop-py27-support+status:open How you can help: ============== - Review the patches. Push the patches if I missed any repo. [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-January/012241.… -gmann

1 0

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

30 Jan '20

Hi everyone, The Large Scale SIG held a meeting today. You can access the summary and logs of the meeting at: http://eavesdrop.openstack.org/meetings/large_scale_sig/2020/large_scale_si… Regarding progress on our "Documenting large scale operations" goal, we turned our collection of relevant articles more as a group background activity than an immediate TODO. The idea is more to remember to add links to the etherpad[1] when we come across relevant content. oneswig mentioned the list to the Scientific SIG, in hopes that it would trigger more entries. [1] https://etherpad.openstack.org/p/large-scale-sig-documentation On the "Scaling within one cluster, and instrumentation of the bottlenecks" goal, nobody filed a scaling story yet on the etherpad[2] set up to collect them. masahito produced a first draft of the oslo.metrics blueprint[3], up for the group review. Finally, oneswig signed up to prepare a show-and-tell about some investigation they have been doing in this area, for presentation at next meeting. [2] https://etherpad.openstack.org/p/scaling-stories [3] https://review.opendev.org/#/c/704733/ Between now and next meeting, group members should prioritize: - Reviewing oslo.metrics draft at https://review.opendev.org/#/c/704733/ and comment so that we can iterate on it - Reading page on golden signals at https://landing.google.com/sre/sre-book/chapters/monitoring-distributed-sys… Other action items: - oneswig to prepare show-and-tell for presentation at next meeting - ttx to add meeting to eavesdrop on a every-two-week cadence - all post short descriptions of what happens (what breaks first) when scaling up a single cluster to https://etherpad.openstack.org/p/scaling-stories The next meeting will happen on February 12, at 9:00 UTC on #openstack-meeting. Cheers, -- Thierry Carrez (ttx)

2 1

[cinder] driver removal policy update (draft)
by Brian Rosmaita 30 Jan '20

30 Jan '20

I've posted a patch updating our third-party driver removal policy along the lines discussed at today's cinder meeting: https://review.opendev.org/704906 Let's continue the discussion in gerrit. I'll update the wiki after we've come to a consensus on the patch. cheers, brian

1 0

[tripleo] Removing the `openstack overcloud plan *` commands
by Dougal Matthews 29 Jan '20

29 Jan '20

Hey all, While doing work on the Mistral to Ansible port I was looking at the openstack overcloud plan commands. These are; - openstack overcloud plan create - openstack overcloud plan delete - openstack overcloud plan deploy - openstack overcloud plan list - openstack overcloud plan export I believe none of these commands make sense in a post-TripleO UI world. There is no other way to interact and update a plan. Deploys are always done via "openstack overcloud deploy" and this deletes the contents of the plan container and repopulates it with the local files[1]. I am therefore proposing that we remove these commands and skip the normal deprecation process. https://review.opendev.org/#/c/704581/1 What do you think? Thanks, Dougal [1]: https://github.com/openstack/python-tripleoclient/blob/3c589979ceb05d732b3c…

3 4

horizon: Trailing spaces removed on passwords
by Orestes Leal Rodríguez 29 Jan '20

29 Jan '20

>From the dashboard openstack is removing the trailing spaces from our user's passwords. We have a modified sql.py backend, that does an ldap bind to an active directory data store. And that works almost always. I say almost because for some users it doesn't work at all. We figure out (and a co-worker also confirmed this) that openstack is removing trailing (also leading?) spaces from the password entered in the dashboard. Also, inside the dashboard trailing spaces are not accepted even when they are equal byte by byte (including the space, I get an error). So this is going on. Do anybody knows where is this removal performed? (python script location, line) So I can remove that since I have users (me included, I have the issue since the very beginning of this deployment) that cannot login. And they can use their Active Directrory passwords from other apps without problem. We are running 'stein' with the latest update for ubuntu 18.04-AMD64.

5 5

[cyborg] No IRC meeting today
by Nadathur, Sundar 29 Jan '20

29 Jan '20

Since many people are traveling on account of the Chinese New Year, there will be no IRC meeting today. Regards, Sundar

1 1

[ops] OpenStack Ops Meetups team meeting 2020-1-20
by Chris Morgan 28 Jan '20

28 Jan '20

Meeting minutes for today's meeting are linked below. This was our first meeting since the very successful (or so I am told) Ops Meetup in London earlier this month, for which the agenda is here https://etherpad.openstack.org/p/LON-2020-OPS-AGENDA and the feedback was collected here https://etherpad.openstack.org/p/LON-2020-OPS-FEEDBACK the meetups team is now turning to looking into what we can arrange for operators at the Vancouver opendev+ptg event and then a second full ops meetup in south korea in september. Watch this space! Chris Morgan on behalf of the openstack ops meetups team <•openstack> Minutes: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2020/ops_meetup_tea… 10:53 AM Minutes (text): http://eavesdrop.openstack.org/meetings/ops_meetup_team/2020/ops_meetup_tea… 10:53 AM Log: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2020/ops_meetup_tea… -- Chris Morgan <mihalis68(a)gmail.com>

1 0

[barbican] TPM2.0 backend
by Balázs Gibizer 28 Jan '20

28 Jan '20

Hi, Looking at the Barbican documentation I see that the secrets can be stored on disk (SimpleCrypto backend) or in a HW vendor specific HSM module. Is there a way to use a TPM 2.0 device as the backend of Barbican via something like [1]? Cheers, gibi [1] https://github.com/tpm2-software/tpm2-pkcs11

1 1

[trio2o] Current state, community interest, alternatives
by Vladimir Kozhukalov 28 Jan '20

28 Jan '20

Hi, I am currently looking for a open source solution that is able to expose a single API endpoint for a user to multiple Openstack instances. Partly the idea behind is to stop investing efforts into tuning of Openstack to make it scalable and instead to deploy a bunch of small Openstack regions (say ~100 nodes) and work with them via API frontend. I am aware of Nova Cells, but it is complicated and Nova is not the only Openstack component that needs scaling. All these ad hoc tuning like dedicated RabbitMQ instances just make the system barely maintainable and it is complicated to reproduce. Requirements for a possible solution are: - Single authentication point (I know this is simple and can be for example SAML based federation) - Single point to manage keys and quotas - Possibly L2 connectivity between VMs in different Openstack instances (I know this can be achieved using VPNs, but this is kinda too complicated for a user) - Ability to work with different Openstack versions (need for gradual upgrade) I know Huawei and others implemented PoC for Openstack cascading and then invested some efforts in Trio2o and Tricircle. Tricircle is about cascading Neutron and IMO it is better to use a scalable SDN (like TangstenFabric or OVN). Trio2o looks like what I actually need, but the community interest around Trio2o is very limited (frankly, it looks almost dead). Last few weeks I was experimenting with Trio2o and Devstack with Stein release. It looks working, but the functionality is limited. Is there anyone who is interested in reviving Trio2o and investing into it? Maybe there are other solutions that I am not aware of? -- Best regards, Kozhukalov Vladimir

1 0

[cinder] changes for sqlalchemy 1.3.13
by Brian Rosmaita 28 Jan '20

28 Jan '20

Updating to the latest release of sqlalchemy breaks a cinder unit test. This patch shows the breakage and makes some suggestions about how it could be fixed. I could use some feedback: https://review.opendev.org/704425 thanks! brian

1 0

[neutron] CI meeting date changed
by Slawek Kaplonski 27 Jan '20

27 Jan '20

Hi, Just short info, according to what we agreed on our last CI meeting, it's now changed and will be on Wednesday at 1500 UTC. Please also note that IRC channel is also changed and now it will be on "openstack-meeting-3" You can check [1] for details. [1] https://review.opendev.org/#/c/704200/ -- Slawek Kaplonski Senior software engineer Red Hat

1 0

[ceilometer] Stable releases
by Pierre Riteau 27 Jan '20

27 Jan '20

Hello, Is it planned to release new Ceilometer tarballs for rocky and stein? There are several bug fixes (for example [1]) in stable branches that would be useful to include in a release. If t can help, I can submit patches to the releases repository. Thanks, Pierre Riteau (priteau) [1] https://bugs.launchpad.net/ceilometer/+bug/1801348

2 2

[tripleo] TripleO CI Summary: Sprint 41
by Rafael Folco 27 Jan '20

27 Jan '20

Greetings, The TripleO CI team has just completed Sprint 41 / Unified Sprint 20 (Jan 03 thru Jan 22). The following is a summary of completed work during this sprint cycle: - Fixed the new promoter code and added testing to cover identified bugs. - Manually built CentOS8 containers and documented missing requirements [4]. Started building RHEL8 containers for OSP. - Documented the design for the new component promotion pipeline [3]. Continue to implement the downstream version of the component pipeline. - Addressed necessary changes to promote-hash role to support the new multi-hash component provided by delorean [5]. - Turned the ansible-collect-logs role into an infra-red plugin as part of the shared goals for the combined CI team. The planned work for the next sprint [1] extends the work started in the previous sprint and focuses on CentOS8 container builds as a base requirement to leverage other fronts of work. The Ruck and Rover for this sprint are Wesley Hayutin (weshay) and Chandan Kumar (chkumar). Please direct questions or queries to them regarding CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on their nick. Ruck/rover notes to be tracked in etherpad [2]. Thanks, rfolco [1] https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-21 [2] https://etherpad.openstack.org/p/ruckroversprint21 [3] https://hackmd.io/5uYRmLaOTI2raTbHWsaiSQ [4] https://hackmd.io/dSagCbocQ4KSVEZR1uf8Tw [5] https://trunk.rdoproject.org/centos8-master/tripleo-ci-testing/delorean.repo

1 0

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

27 Jan '20

Hi everyone, The Large Scale SIG will have a meeting this week on Wednesday, Jan 29 at 9 UTC[1] in #openstack-meeting on IRC: [1] https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200129T09 As always, the agenda for our meeting is available at: https://etherpad.openstack.org/p/large-scale-sig-meeting Feel free to add topics to it. We had several standing TODOs out of our January 15 meeting, so I also invite you to review the summary of that meeting in preparation of the next: http://lists.openstack.org/pipermail/openstack-discuss/2020-January/012049.… Regards, -- Thierry Carrez

1 0

[Devstack] Unable to find pip2.7 ?
by Martin Chacon Piza 27 Jan '20

27 Jan '20

Dear all, It seems that there is a problem stacking Devstack using the master branch. The problem happens during the step: Installing package prerequisites [ERROR] /home/vagrant/devstack/inc/python:41 Unable to find pip2.7; cannot continue This is the minimum local.conf I used: [[local|localrc]] SERVICE_HOST=192.168.10.6 HOST_IP=192.168.10.6 HOST_IP_IFACE=eth1 DATABASE_PASSWORD=secretdatabase RABBIT_PASSWORD=secretrabbit ADMIN_PASSWORD=secretadmin SERVICE_PASSWORD=secretservice LOGFILE=$DEST/logs/stack.sh.log LOGDIR=$DEST/logs LOG_COLOR=False DEST=/opt/stack USE_PYTHON3=True As a workaround I need to revert the following change, then it ends up properly: commit 279a7589b03db69fd1b85d947cd0171dacef94ee Author: Jens Harbott (frickler) <j.harbott(a)x-ion.de> Date: Mon Apr 16 12:08:30 2018 +0000 Revert "Do not use pip 10 or higher" This reverts commit f99d1771ba1882dfbb69186212a197edae3ef02c. Added workarounds that might want to get split into their own patch before merging: - Don't install python-psutil - Don't run peakmem_tracker Change-Id: If4fb16555e15082a4d97cffdf3cfa608a682997d Any hints? -- Best regards, *Martín Chacón Pizá* *chacon.piza(a)gmail.com <chacon.piza(a)hotmail.com>*

2 3

[neutron] Bug deputy report for week of January 20th
by Lajos Katona 27 Jan '20

27 Jan '20

Hi, I was Neutron bug deputy last week, see my short summary of last week's bugs. Summary: A lot of not serious CI related issue, most of them in progress or even already fixed. As a consequence of networking-ovn code moving old bugs from https://bugs.launchpad.net/networking-ovn were moved to neutron bugs repository in launchpad. - High - https://bugs.launchpad.net/neutron/+bug/1860612 (OVN agent devstack script doesn't support IPv6) - In Progress - Medium - https://bugs.launchpad.net/neutron/+bug/1860209 (Local variable referenced before assignment in "_router_fip_qos_after_admin_state_down_up") - Fix released - https://bugs.launchpad.net/neutron/+bug/1860332 ([CI] gate py3{6,7} jobs timeout ) - Fix Released - https://bugs.launchpad.net/neutron/+bug/1860326 (Kill neutron-keepalived-state-change-monitor fails) - Fix Released - https://bugs.launchpad.net/neutron/+bug/1860488 (Encapsulated DHCP options are not supported in neutron) - In Progress - https://bugs.launchpad.net/neutron/+bug/1860560 ([ovn] lsp_set_address Exception possible when passed empty list of addresses) - In Progress - https://bugs.launchpad.net/neutron/+bug/1860586 ([Tempest] SSH exception "No existing session") - In Progress - https://bugs.launchpad.net/neutron/+bug/1860774([CI] gate functional and fullstack timeouts without reports of the causative test case) - In Progress - https://bugs.launchpad.net/neutron/+bug/1860662 ([OVN] FIP on OVN Load balancer doesn't work if member has FIP assigned on DVR setup) - Low - https://bugs.launchpad.net/neutron/+bug/1860436 ([ovn] Agent liveness checks are flaky and report false positives) - Fix Released - RFE - https://bugs.launchpad.net/neutron/+bug/1860521 (L2 pop notifications are not reliable) - Wishlist - https://bugs.launchpad.net/neutron/+bug/1860338 ([OVS] OVS agent should not plug/unplug smartNIC ports) - This one is related to Smartnic support ( https://bugs.launchpad.net/neutron/+bug/1785608) and os-vif, I suppose drivers team should discuss it. - Moved from OVN: - https://bugs.launchpad.net/neutron/+bug/1689880 ([OVN] The "neutron_sync_mode = repair" option breaks the whole cloud!) - https://bugs.launchpad.net/neutron/+bug/1860273 (Delete static route exception OVN) - https://bugs.launchpad.net/neutron/+bug/1841154 ([OVN][RFE] Make use of external ports) - https://bugs.launchpad.net/neutron/+bug/1832003 ([OVN] Left-over namespaces left in the environment by ovn-metadata-agent) - https://bugs.launchpad.net/neutron/+bug/1813551 ([OVN]Missing ingress QoS in OVN) - https://bugs.launchpad.net/neutron/+bug/1670666 ([OVN] Support native DHCP service for subnet without gateway IP) - https://bugs.launchpad.net/neutron/+bug/1542503 ([OVN] Lacking mechanism to provide proper MTU to instances) - https://bugs.launchpad.net/neutron/+bug/1664475 ([OVN] Can not retrieve where a OVN gateway router lives) - https://bugs.launchpad.net/neutron/+bug/1648525 ([OVN] QoS doesn't work with DVR, vlan tenant networks or provider networks.) - https://bugs.launchpad.net/neutron/+bug/1639835 ([OVN] Add functional testing to kuryr CI job) - https://bugs.launchpad.net/neutron/+bug/1764408 ([OVN] DHCP ports don't recreated after deleting them)

1 0

[goals][Drop Python 2.7 Support] Week R-16 Update (# 3 weeks left to complete)
by Ghanshyam Mann 26 Jan '20

26 Jan '20

Hello Everyone, Below is the progress on "Drop Python 2.7 Support" for R-16 week. Schedule: https://governance.openstack.org/tc/goals/selected/ussuri/drop-py27.html#sc… Highlights: ======== * Schedule is to finish the py2-drop from every deliverable (except requirement repo) by m-2 on R13. Only 3 weeks left to finish the work so I am going to send the status twice a week from now. * Every project has to merge their py2 drop patches on priority. We are/will face more gate issue on py2 things if the transition period is longer. * I have pushed the patches on tempest-plugins and wherever applicable jobs defined in plugin repo have been modified to run on py2 for stable branches and on py3 on the master gate. * Fixing neutron-tempest-plugin failure on stable/rocky by running Tempest on >py3.6 venv[1]. Project wise status and need reviews: ============================ Phase-1 status: The OpenStack services have not merged the py2 drop patches: NOTE: This was supposed to be completed by milestone-1 (Dec 13th, 19). * Adjutant * ec2-api * Karbor * Sahara (its plugins) * Masakari * Tacker * Qinling * Tricircle Phase-2 status: This is ongoing work and I think most of the repo have patches up to review. I will start tracking the progress for unmerged patches form next week. Each project is requested to merge the open patches asap. * Open review: https://review.opendev.org/#/q/topic:drop-py27-support+status:open How you can help: ============== - Review the patches. Push the patches if I missed any repo. [1] https://bugs.launchpad.net/neutron/+bug/1860033 -gmann

1 0

quick question
by Ruchi Rajasekhar 25 Jan '20

25 Jan '20

Would anyone happen to know of any data science platforms that can run on OpenStack? I was looking at Pivotal, Pachyderm but they don't run on OpenStack ☹

6 5

[Telemetry][TC]Telemetry status
by Rong Zhu 24 Jan '20

24 Jan '20

Hi, As discussed with Rico I send a mail to report the telemetry project status. We had already finished some work in Ussuri: 1.Support dynamic pollster feature Thanks Rafael Weingärtner hard working https://review.opendev.org/#/c/677031/ https://review.opendev.org/#/c/691659/ https://review.opendev.org/#/c/691944/ https://review.opendev.org/#/c/694345/ https://review.opendev.org/#/c/693088/ https://review.opendev.org/#/c/694519/ 2.Support aodh-evaluator built-in active/active deployment mode 3.Support threshold type alarm again Thanks, Lingxian https://review.opendev.org/#/c/697566/ https://review.opendev.org/#/c/695997/ Also, We plan to do some work in Ussuri: 1.Add Ceilometer API back Since Gnocchi is out of OpenStack and is unmaintained, we need to add Ceilometer API back again. 2.Mongodb database backend support As this thread [0] discuss, there are still some users still use mongodb as the database backend, we decide to add this support again. License issue should consider and fix by user. The OVH and Catalyst Cloud had fix the mongodb performance issue with some mongodb changes. Gnoochi will still support as the backed. Other database (like influxdb, ES....), we would happy everyone to submit patches to support as the database backed in ceilometer. 3.cpu_utils support This is mentioned many many times, this is a useful metric, so we decide support this again. 4.Support container meters with Zun 5. Acknowledgment of OpenStack-wide Goals I created a storyboard to track Ceilometer Ussuri release to do things in [1]. Free free to add things you want to do in Ussuri release. [0]: http://lists.openstack.org/pipermail/openstack-discuss/2019-November/010922… [1]: https://storyboard.openstack.org/#!/board/205 -- Thanks, Rong Zhu

17 34

RE: [cinder][ci] Cinder drivers being Unsupported and General CI Status ...
by SAITO NAOKI(齊藤　直樹) 24 Jan '20

24 Jan '20

Hi Jay, NEC Cinder CI was configured with zuul v2.5 and Jenkins, and has not been working since "Drop Xenial support". We are fixing our CI with zuul v3 using Software Factory mentioned in the last Cinder Ussuri Virtual Mid-Cycle meeting [1]. We installed Software Factory referring to guide [2], and are investigating how we can monitor openstack/cinder events and create cinder test jobs. It will be helpful if cinder-specific examples are available. [1] https://etherpad.openstack.org/p/cinder-ussuri-mid-cycle-planning [2] https://softwarefactory-project.io/r/#/c/17097/ Thanks, Naoki Saito E-Mail: nasaito at nec.com > From: Jay Bryant <jungleboyj at gmail.com> > Sent: Thursday, January 23, 2020 4:51 AM > To: openstack-discuss at lists.openstack.org; inspur.ci at inspur.com; wangyong2017 at inspur.com; Chengwei.Chou at infortrend.com; Bill.Sung at infortrend.com; Kuirong.Chen(陳奎融) <Kuirong.Chen at infortrend.com>; ido.benda at kaminario.com; srinivasd.ctr at kaminario.com; nec-cinder-ci at istorage.jp.nec.com; silvan at quobyte.com; robert at quobyte.com; felix at quobyte.com; bjoern at quobyte.com; OpenStack Development <openstack-dev at zadarastorage.com>; Shlomi Avihou | Zadara <shlomi at zadarastorage.com>; msdu-openstack at groups.ext.hpe.com > Subject: [nec-cinder-ci:76204] [cinder][ci] Cinder drivers being Unsupported and General CI Status ... > > All, > We once again are at the point in the release where we are talking about 3rd Party CI and what is going on for Cinder. At the moment I have analyzed drivers that have not successfully reported results on a Cinder patch in 30 or more days and have put together the following list of drivers to be unsupported in the Ussuri release: > • Inspur Drivers > • Infortrend > • Kaminario > • NEC > • Quobyte > • Zadara > • HPE Drivers > If your name is in the list above you are receiving this e-mail directly, not just through the mailing list. > If you are working on resolving CI issues please let me know so we can discuss how to proceed. > In addition to the fact that we will be pushing up unsupported patches for the drivers above, we have already unsupported and removed a number of drivers during this release. They are as follows: > • Unsupported: > o MacroSAN Driver > • Removed: > o ProphetStor Driver > o Nimble Storage Driver > o Veritas Access Driver > o Veritas CNFS Driver > o Virtuozzo Storage Driver > o Huawei FusionStorage Driver > o Sheepdog Storage Driver > Obviously we are reaching the point that the number of drivers leaving the community is concerning and it has sparked discussions around the fact that maybe our 3rd Party CI approach isn't working as intended. So what do we do? Just mark drivers unsupported and no longer remove drivers? Do we restore drivers that have recently been removed? > We are planning to have further discussion around these questions at our next Cinder meeting in #openstack-meeting-4 on Wednesday, 1/29/20 at 14:00 UTC. If you have thoughts or strong opinions around this topic please join us. > Thank you! > Jay Bryant > mailto:jsbryant at electronicjungle.net > IRC: jungleboyj

4 3

Backup and restore questions
by Tony Pearce 24 Jan '20

24 Jan '20

Is it possible to restore "openstack" to a different cloud? For example, either of the following; 1. Backup Openstack with version "X" and restore to different fresh deployment of the same version or 2. Backup Openstack with version "X" and restore to Openstack Version Y or even later, Z And are there any tools associated with Openstack that achieves this? I think this would come under the term "migration". I've been reading the Openstack docs with regards to backup/restore and doing some trial and error on my side. It appears to me that the "backup/restore" is only applicable for the same system - can anyone confirm it? Are there any options for transferring data to a different Openstack deployment? Thanks in advance *Tony Pearce* | *Senior Network Engineer / Infrastructure Lead**Cinglevue International <https://www.cinglevue.com>* Email: tony.pearce(a)cinglevue.com Web: http://www.cinglevue.com *Australia* 1 Walsh Loop, Joondalup, WA 6027 Australia. Direct: +61 8 6202 0036 | Main: +61 8 6202 0024 Note: This email and all attachments are the sole property of Cinglevue International Pty Ltd. (or any of its subsidiary entities), and the information contained herein must be considered confidential, unless specified otherwise. If you are not the intended recipient, you must not use or forward the information contained in these documents. If you have received this message in error, please delete the email and notify the sender.

2 1

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

24 Jan '20

# Keystone Team Update - Week of 20 January 2020 ## News ### Roadmap Review The team isn't organizing a midcycle or milestone-ly meetings in this cycle. Instead we decided to utilize the meeting time and go through the ussuri roadmap [1]. We discussed the progress with the card owners and if they need any help with them. Please find the updated status of the cards in the roadmap [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 2 changes this week. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 40 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 https://review.opendev.org/#/c/588211/ Add openstack_groups to assertion https://review.opendev.org/#/c/703578/ Updating tox -e all-plugin command ## Bugs This week we opened 2 new bugs and closed 1. Bugs opened (2) Bug #1860478 (keystone:Low): fetching role assignments should handle domain IDs in addition to project IDs - Opened by Harry Rybacki https://bugs.launchpad.net/keystone/+bug/1860478 Bug #1860252 (keystone:Undecided): security problem，one user can change other user's password without admin - Opened by kuangpeiling https://bugs.launchpad.net/keystone/+bug/1860252 Bugs closed (1) Bug #1860252 (keystone:Invalid): https://bugs.launchpad.net/keystone/+bug/1860252 ## Milestone Outlook https://releases.openstack.org/ussuri/schedule.html Spec freeze is on the week of 10 Feburary. We have 3 specs proposed for usuri cycle that needs reviews. ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

[neutron] Drivers meeting on 24.01 cancelled
by Slawek Kaplonski 24 Jan '20

24 Jan '20

Hi, I am on PTO and I will not have time to chair tomorrow's drivers meeting. Lets cancel it this week. See You all next week on the meeting. Sorry for late info about it. -- Slawek Kaplonski Senior software engineer Red Hat

1 0

Re: [openstack-helm] Core Reviewer Nominations
by Tin Lam 23 Jan '20

23 Jan '20

+1. Thanks for your reviews and contributions to the OSH projects, Gage and Steven. Tin On Mon, Jan 20, 2020 at 7:14 PM Pete Birley < > petebirley+openstack-dev(a)gmail.com> wrote: > >> OpenStack-Helm team, >> >> >> >> Based on their record of quality code review and substantial/meaningful >> code contributions to the openstack-helm project, at last weeks meeting we >> proposed the following individuals as core reviewers for openstack-helm: >> >> >> >> - Gage Hugo >> - Steven Fitzpatrick >> >> >> >> All OpenStack-Helm Core Reviewers are invited to reply with a +1/-1 by >> EOD next Monday (27/1/2020). A lone +1/-1 will apply to both candidates, >> otherwise please spell out votes individually for the candidates. >> >> >> >> Cheers, >> >> >> Pete >> > -- Regards, Tin Lam

2 1

[all] pep8 results for maintenance branches over time
by John Fulton 23 Jan '20

23 Jan '20

What are projects doing about new linters working only with newer deps or even python3 only? For example [1] [2]. Might it be OK to ignore pep8 results on maintenance branches? Thanks, John [1] https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/… Ignoring ruamel.yaml: markers 'python_version == "3.4"' don't match your environment ERROR: ansible-lint 4.2.0 has requirement ruamel.yaml<1,>=0.15.34; python_version < "3.7", but you'll have ruamel-yaml 0.13.14 which is incompatible. [2] https://zuul.opendev.org/t/openstack/build/82b01fb8a8c04068a906bf0cb888de58 AttributeError: module 'ruamel.yaml' has no attribute 'YAML' Examining undercloud-debug.yaml of type playbook Traceback (most recent call last): File "/home/zuul/src/opendev.org/openstack/tripleo-validations/.tox/pep8/bin/ansible-lint", line 8, in <module> sys.exit(main()) File "/home/zuul/src/opendev.org/openstack/tripleo-validations/.tox/pep8/lib/python3.5/site-packages/ansiblelint/__main__.py", line 187, in main matches.extend(runner.run()) File "/home/zuul/src/opendev.org/openstack/tripleo-validations/.tox/pep8/lib/python3.5/site-packages/ansiblelint/__init__.py", line 287, in run skip_list=self.skip_list)) File "/home/zuul/src/opendev.org/openstack/tripleo-validations/.tox/pep8/lib/python3.5/site-packages/ansiblelint/__init__.py", line 177, in run matches.extend(rule.matchtasks(playbookfile, text)) File "/home/zuul/src/opendev.org/openstack/tripleo-validations/.tox/pep8/lib/python3.5/site-packages/ansiblelint/__init__.py", line 87, in matchtasks yaml = ansiblelint.utils.append_skipped_rules(yaml, text, file['type']) File "/home/zuul/src/opendev.org/openstack/tripleo-validations/.tox/pep8/lib/python3.5/site-packages/ansiblelint/utils.py", line 596, in append_skipped_rules yaml_skip = _append_skipped_rules(pyyaml_data, file_text, file_type) File "/home/zuul/src/opendev.org/openstack/tripleo-validations/.tox/pep8/lib/python3.5/site-packages/ansiblelint/utils.py", line 606, in _append_skipped_rules yaml = ruamel.yaml.YAML() AttributeError: module 'ruamel.yaml' has no attribute 'YAML' Examining undercloud-service-status.yaml of type playbook Traceback (most recent call last): File "/home/zuul/src/opendev.org/openstack/tripleo-validations/.tox/pep8/bin/ansible-lint", line 8, in <module> sys.exit(main()) File "/home/zuul/src/opendev.org/openstack/tripleo-validations/.tox/pep8/lib/python3.5/site-packages/ansiblelint/__main__.py", line 187, in main matches.extend(runner.run()) File "/home/zuul/src/opendev.org/openstack/tripleo-validations/.tox/pep8/lib/python3.5/site-packages/ansiblelint/__init__.py", line 287, in run skip_list=self.skip_list)) File "/home/zuul/src/opendev.org/openstack/tripleo-validations/.tox/pep8/lib/python3.5/site-packages/ansiblelint/__init__.py", line 177, in run matches.extend(rule.matchtasks(playbookfile, text)) File "/home/zuul/src/opendev.org/openstack/tripleo-validations/.tox/pep8/lib/python3.5/site-packages/ansiblelint/__init__.py", line 87, in matchtasks yaml = ansiblelint.utils.append_skipped_rules(yaml, text, file['type']) File "/home/zuul/src/opendev.org/openstack/tripleo-validations/.tox/pep8/lib/python3.5/site-packages/ansiblelint/utils.py", line 596, in append_skipped_rules yaml_skip = _append_skipped_rules(pyyaml_data, file_text, file_type) File "/home/zuul/src/opendev.org/openstack/tripleo-validations/.tox/pep8/lib/python3.5/site-packages/ansiblelint/utils.py", line 606, in _append_skipped_rules yaml = ruamel.yaml.YAML() AttributeError: module 'ruamel.yaml' has no attribute 'YAML' /home/zuul/src/opendev.org/openstack/tripleo-validations ERROR: InvocationError for command /bin/bash tools/ansible-lint.sh (exited with code 1) pep8 finish: run-test after 45.18 seconds pep8 start: run-test-post pep8 finish: run-test-post after 0.00 seconds ___________________________________ summary ____________________________________ ERROR: pep8: commands failed

7 6

Upcoming OSF Event: OpenDev + PTG, June 8-11 in Vancouver
by Ashlee Ferguson 23 Jan '20

23 Jan '20

Join us this June in Vancouver for OpenDev + PTG, and grab your early bird tickets now <https://www.eventbrite.com/e/opendev-ptg-vancouver-2020-tickets-88923270897>! OpenDev + PTG is a new collaborative event organized by the OpenStack Foundation gathering developers, system architects, and operators to address common open source infrastructure challenges. June 8-11, 2020 Vancouver Convention Centre - East Building OpenDev will include discussion oriented sessions around a particular topic to explore a problem within a topic area, share common architectures, and collaborate around potential solutions. This OpenDev will focus specifically on the following Tracks, spanning open source projects, including Airship, Ansible, Ceph, Kata Containers, Kubernetes, OpenStack, StarlingX, and Zuul: Hardware Automation Large-scale Usage of Open Source Infrastructure Software Containers in Production Key Challenges for Open Source in 2020 The conversations will continue into the afternoon with the Project Teams Gathering (PTG) <https://www.openstack.org/ptg>. This is when the morning’s practices will be explored by project teams, SIGs and other workgroups who will have dedicated space to get work done in a productive setting, maximizing the ability of contributors to work through their project objectives in an environment that is focused towards work and productivity. Interested in Sponsoring? Sponsoring these events will help ensure the continued growth and success of open source infrastructure projects. A sponsorship prospectus will be available soon. If your organization is interested in participating and supporting the open infrastructure community, please contact events(a)openstack.org <mailto:events@openstack.org>. P.S. - Stay tuned for more info on OSF’s Q4 event, the Open Infrastructure Summit you know and love! See you in Vancouver! The OpenStack Foundation

1 0

[stestr][tempest] how to conf test suite to get file_name to be pythonlogging instead of stdout
by SCHVENINGER, DOUGLAS P 23 Jan '20

23 Jan '20

When using stestr we are seeing 1. different file_name for logging statement 2. mime type on one test suite run and not the other test suite run 3. test_id on all log statement in one test suite run but missing on some of the log statement from the other test suite run I was wondering if anyone has any input of how to config our internal test suite like tempest to get correct data to show up When we run tempest with stestr the subunit stream is placing all logging data with a test_id and the file_name being pythonlogging. Example sec record 2 below: Record 1 worker-00MùÏ³/àPÈ^'K‡ôoW�@{tempest.api.compute.flavors.test_flavors.FlavorsV2TestJSON.test_list_flavors[id-e36c0eaa-dff5-4082-ad1f-3f9a80aa3f59,smoke] Record 2 worker-0text/plain; charset="utf8"pythonlogging:''P�2020-01-21 19:05:43,639 142 INFO [tempest.lib.common.rest_client] Request (FlavorsV2TestJSON:test_list_flavors): 200 GET https://compute-nc.auk51a.cci.att.com/v2.1/8695795f8370474d9d628b3cdd9f97cb… 0.468s 2020-01-21 19:05:43,639 142 DEBUG [tempest.lib.common.rest_client] Request - Headers: {'Content-Type': 'application/json', 'Accept': 'application/json', 'X-OpenStack-Nova-API-Version': '2.1', 'X-Auth-Token': '<omitted>'} Body: None Response - Headers: {'date': 'Tue, 21 Jan 2020 19:05:43 GMT', 'content-type': 'application/json', 'content-length': '4244', 'connection': 'close', 'vary': 'X-OpenStack-Nova-API-Version', 'x-content-type-options': 'nosniff', 'strict-transport-security': 'max-age=15724800; includeSubDomains', 'content-security-policy': "script-src 'self'; object-src 'self'", 'x-frame-options': 'DENY', 'x-permitted-cross-domain-policies': 'none', 'x-xss-protection': '1; mode=block', 'openstack-api-version': 'compute 2.1', 'x-openstack-nova-api-version': '2.1', 'x-openstack-request-id': 'req-160e3fc6-d568-457d-9cbd-f6670b652565', 'x-compute-request-id': 'req-160e3fc6-d568-457d-9cbd-f6670b652565', 'status': '200', 'content-location': 'https://compute-nc.auk51a.cci.att.com/v2.1/8695795f8370474d9d628b3cdd9f97cb…'} Body: b'{"flavors": [{"id": "5f112417-533d-4e33-b9d7-ca8237a29a83", "name": "m1.xlarge", "links": [{"rel": "self", "href": "https://compute-nc.auk51a.cci.att.com/v2.1/8695795f8370474d9d628b3cdd9f97cb…"}, {"rel": "bookmark", "href": "https://compute-nc.auk51a.cci.att.com/8695795f8370474d9d628b3cdd9f97cb/flav…"}]}, {"id": "877ef018-6134-4d61-ba6b-d40ee58eb6be", "name": "aqa.alt20200121T190526948874", "links": [{"rel": "self", "href": "https://compute-nc.auk51a.cci.att.com/v2.1/8695795f8370474d9d628b3cdd9f97cb…"}, {"rel": "bookmark", "href": "https://compute-nc.auk51a.cci.att.com/8695795f8370474d9d628b3cdd9f97cb/flav…"}]}, {"id": "910d1836-119b-4ecf-9d47-3ef7e5990fad", "name": "aqa.primary20200121T185150095917", "links": [{"rel": "self", "href": "https://compute-nc.auk51a.cci.att.com/v2.1/8695795f8370474d9d628b3cdd9f97cb…"}, {"rel": "bookmark", "href": "https://compute-nc.auk51a.cci.att.com/8695795f8370474d9d628b3cdd9f97cb/flav…"}]}, {"id": "bd850da7-a2d8-48e8-bd42-3378abae556a", "name": "aqa.primary20200121T190526948874", "links": [{"rel": "self", "href": "https://compute-nc.auk51a.cci.att.com/v2.1/8695795f8370474d9d628b3cdd9f97cb…"}, {"rel": "bookmark", "href": "https://compute-nc.auk51a.cci.att.com/8695795f8370474d9d628b3cdd9f97cb/flav…"}]}, {"id": "c6653cba-3cbd-48bd-aa3e-54366bded2b4", "name": "m1.small", "links": [{"rel": "self", "href": "https://compute-nc.auk51a.cci.att.com/v2.1/8695795f8370474d9d628b3cdd9f97cb…"}, {"rel": "bookmark", "href": "https://compute-nc.auk51a.cci.att.com/8695795f8370474d9d628b3cdd9f97cb/flav…"}]}, {"id": "cdb15fe3-66a6-46cb-ab97-b26cc37b6d7f", "name": "m1.medium", "links": [{"rel": "self", "href": "https://compute-nc.auk51a.cci.att.com/v2.1/8695795f8370474d9d628b3cdd9f97cb…"}, {"rel": "bookmark", "href": "https://compute-nc.auk51a.cci.att.com/8695795f8370474d9d628b3cdd9f97cb/flav…"}]}, {"id": "dcc5d1ea-d15a-476e-8587-29bd34e36051", "name": "m1.large", "links": [{"rel": "self", "href": "https://compute-nc.auk51a.cci.att.com/v2.1/8695795f8370474d9d628b3cdd9f97cb…"}, {"rel": "bookmark", "href": "https://compute-nc.auk51a.cci.att.com/8695795f8370474d9d628b3cdd9f97cb/flav…"}]}, {"id": "e43ea269-f785-48f1-a05e-edffae5d5a85", "name": "taas-p1.c2r4d50", "links": [{"rel": "0ËUùÆ³/ðMg^'K‡ôoW�@{tempest.api.compute.flavors.test_flavors.FlavorsV2TestJSON.test_list_flavors[id-e36c0eaa-dff5-4082-ad1f-3f9a80aa3f59,smoke] Record 3 worker-0text/plain; charset="utf8"pythonlogging:''LŸself", "href": "https://compute-nc.auk51a.cci.att.com/v2.1/8695795f8370474d9d628b3cdd9f97cb…"}, {"rel": "bookmark", "href": "https://compute-nc.auk51a.cci.att.com/8695795f8370474d9d628b3cdd9f97cb/flav…"}]}, {"id": "eef05014-3e5f-4ea5-bbfa-8171c2e2707b", "name": "aqa.alt20200121T185150095917", "links": [{"rel": "self", "href": "https://compute-nc.auk51a.cci.att.com/v2.1/8695795f8370474d9d628b3cdd9f97cb…"}, {"rel": "bookmark", "href": "https://compute-nc.auk51a.cci.att.com/8695795f8370474d9d628b3cdd9f97cb/flav…"}]}, {"id": "f1a3141db37c48e49bd84e90d1c1369e", "name": "p1.c5r1.0d10s1.0e10", "links": [{"rel": "self", "href": "https://compute-nc.auk51a.cci.att.com/v2.1/8695795f8370474d9d628b3cdd9f97cb…"}, {"rel": "bookmark", "href": "https://compute-nc.auk51a.cci.att.com/8695795f8370474d9d628b3cdd9f97cb/flav…"}]}, {"id": "f3da4ca8-f8df-44f8-8a06-832bca480234", "name": "m1.tiny", "links": [{"rel": "self", "href": "https://compute-nc.auk51a.cci.att.com/v2.1/8695795f8370474d9d628b3cdd9f97cb…"}, 2020-01-21 19:05:43,878 142 INFO [tempest.lib.common.rest_client] Request (FlavorsV2TestJSON:test_list_flavors): 200 GET https://compute-nc.auk51a.cci.att.com/v2.1/8695795f8370474d9d628b3cdd9f97cb… 0.236s 2020-01-21 19:05:43,878 142 DEBUG [tempest.lib.common.rest_client] Request - Headers: {'Content-Type': 'application/json', 'Accept': 'application/json', 'X-OpenStack-Nova-API-Version': '2.1', 'X-Auth-Token': '<omitted>'} Body: None Response - Headers: {'date': 'Tue, 21 Jan 2020 19:05:43 GMT', 'content-type': 'application/json', 'content-length': '581', 'connection': 'close', 'vary': 'X-OpenStack-Nova-API-Version', 'x-content-type-options': 'nosniff', 'strict-transport-security': 'max-age=15724800; includeSubDomains', 'content-security-policy': "script-src 'self'; object-src 'self'", 'x-frame-options': 'DENY', 'x-permitted-cross-domain-policies': 'none', 'x-xss-protection': '1; mode=block', 'openstack-api-version': 'compute 2.1', 'x-openstack-nova-api-version': '2.1', 'x-openstack-request-id': 'req-38380cca-ecaf-4fb5-a768-cc91172ccbff', 'x-compute-request-id': 'req-38380cca-ecaf-4fb5-a768-cc91172ccbff', 'status': '200', 'content-location': 'https://compute-nc.auk51a.cci.att.com/v2.1/8695795f8370474d9d628b3cdd9f97cb…'} Body: b'{"flavor": {"id": "bd850da7-a2d8-48e8-bd42-3378abae556a", "name": "aqa.primary20200121T190526948874", "ram": 1024, "disk": 5, "swap": "", "OS-FLV-EXT-DATA:ephemeral": 0, "OS-FLV-DISABLED:disabled": false, "vcpus": 1, "os-flavor-access:is_public": true, "rxtx_factor": 1.0, "links": [{"rel": "self", "href": "https://compute-nc.auk51a.cci.att.com/v2.1/8695795f8370474d9d628b3cdd9f97cb…"}, {"rel": "bookmark", "href": "https://compute-nc.auk51a.cci.att.com/8695795f8370474d9d628b3cdd9f97cb/flav…"}]}}' 0£Õ8d³/ƒ@š^'K‡ôoW�@{tempest.api.compute.flavors.test_flavors.FlavorsV2TestJSON.test_list_flavors[id-e36c0eaa-dff5-4082-ad1f-3f9a80aa3f59,smoke] When we run our internal test suite with stestr the subunit stream is placing all logging data sometime with a test_id and the file_name being stdout. Example sec record 2 below: Record 1 process config logging to file_name stdout �'�@�^(�R��worker-0stdout@�2020-01-22 11:24:34.681 24600 INFO aic_aqa_infrastructure_sonobuoy_plugins.host_info.config [-] Config and Logging setup by aic_aqa_infrastructure_sonobuoy_plugins.host_info.config Config data following in DEBUG 0��..�'�B^^(�R�z��worker-0stdoutB82020-01-22 11:24:34.742 24600 INFO aic_aqa_infrastructure_sonobuoy_plugins.common.expected.base [-] Loaded ExpectedData source file: requirements from: /home/ds6901/aic-aqa-infrastructure-sonobuoy-plugins/aic_aqa_infrastructure_sonobuoy_plugins/host_info/expected/data/requirements.yaml 2020-01-22 11:24:34.744 24600 INFO aic_aqa_infrastructure_sonobuoy_plugins.common.expected.base [-] Loaded ExpectedData source file: site from: /home/ds6901/aic-aqa-infrastructure-sonobuoy-plugins/aic_aqa_infrastructure_sonobuoy_plugins/host_info/expected/data/site.yaml 0q��'�A@^(�R�'��worker-0stdoutA2020-01-22 11:24:34.819 24600 INFO aic_aqa_infrastructure_sonobuoy_plugins.common.expected.base [-] Loaded ExpectedData source file: default from: /home/ds6901/aic-aqa-infrastructure-sonobuoy-plugins/aic_aqa_infrastructure_sonobuoy_plugins/host_info/expected/data/default.yaml 0��'�BP^(�S^�worker-0stdoutB*2020-01-22 11:24:35.260 24600 DEBUG aic_aqa_infrastructure_sonobuoy_plugins.common.utils.host_info_utils [-] file mount point /home/ds6901/aic-aqa-infrastructure-sonobuoy-plugins/aic_aqa_infrastructure_sonobuoy_plugins/tests/functional/data/host with path /home/ds6901/aic-aqa-infrastructure-sonobuoy-plugins/aic_aqa_infrastructure_sonobuoy_plugins/tests/functional/data/host/etc/rsyslog.d/40-sensage.conf get_host_mount /home/ds6901/aic-aqa-infrastructure-sonobuoy-plugins/aic_aqa_infrastructure_sonobuoy_plugins/common/utils/host_info_utils.py:18 Record 2 test case exists event 0#l'��/�@�^(�S�#)H@|aic_aqa_infrastructure_sonobuoy_plugins.host_info.tests.network.test_calico_logs.TestCalicoLogs.test_flow_log_file_retentionworker-00�� '�E^(�S�� ________________________________ `worker-0stdoutD�2020-01-22 11:24:35.290 24600 DEBUG aic_aqa_infrastructure_sonobuoy_plugins.common.utils.host_info_utils [-] file mount point /home/ds6901/aic-aqa-infrastructure-sonobuoy-plugins/aic_aqa_infrastructure_sonobuoy_plugins/tests/functional/data/host with path /home/ds6901/aic-aqa-infrastructure-sonobuoy-plugins/aic_aqa_infrastructure_sonobuoy_plugins/tests/functional/data/host/etc/hostname get_host_mount /home/ds6901/aic-aqa-infrastructure-sonobuoy-plugins/aic_aqa_infrastructure_sonobuoy_plugins/common/utils/host_info_utils.py:18 2020-01-22 11:24:35.291 24600 DEBUG aic_aqa_infrastructure_sonobuoy_plugins.common.actuals.commands.base_command [-] Executing command: cat /home/ds6901/aic-aqa-infrastructure-sonobuoy-plugins/aic_aqa_infrastructure_sonobuoy_plugins/tests/functional/data/host/etc/hostname __init__ /home/ds6901/aic-aqa-infrastructure-sonobuoy-plugins/aic_aqa_infrastructure_sonobuoy_plugins/common/actuals/commands/base_command.py:31 2020-01-22 11:24:35.298 24600 INFO aic_aqa_infrastructure_sonobuoy_plugins.host_info.tests.test_base [-] Use environment file point /home/ds6901/aic-aqa-infrastructure-sonobuoy-plugins/aic_aqa_infrastructure_sonobuoy_plugins/tests/functional/data/controller-describe-node.json to describe node. 0�j}��'�D�^(�S��worker-0stdoutD�2020-01-22 11:24:35.342 24600 DEBUG aic_aqa_infrastructure_sonobuoy_plugins.common.utils.host_info_utils [-] file mount point /home/ds6901/aic-aqa-infrastructure-sonobuoy-plugins/aic_aqa_infrastructure_sonobuoy_plugins/tests/functional/data/host with path /home/ds6901/aic-aqa-infrastructure-sonobuoy-plugins/aic_aqa_infrastructure_sonobuoy_plugins/tests/functional/data/host/var/log/calico/flowlogs get_host_mount /home/ds6901/aic-aqa-infrastructure-sonobuoy-plugins/aic_aqa_infrastructure_sonobuoy_plugins/common/utils/host_info_utils.py:18 2020-01-22 11:24:35.343 24600 DEBUG aic_aqa_infrastructure_sonobuoy_plugins.common.utils.host_info_utils [-] file mount point /home/ds6901/aic-aqa-infrastructure-sonobuoy-plugins/aic_aqa_infrastructure_sonobuoy_plugins/tests/functional/data/host with path /home/ds6901/aic-aqa-infrastructure-sonobuoy-plugins/aic_aqa_infrastructure_sonobuoy_plugins/tests/functional/data/host/var/log/calico/audit get_host_mount /home/ds6901/aic-aqa-infrastructure-sonobuoy-plugins/aic_aqa_infrastructure_sonobuoy_plugins/common/utils/host_info_utils.py:18 2020-01-22 11:24:35.345 24600 INFO aic_aqa_infrastructure_sonobuoy_plugins.host_info.tests.network.test_calico_logs [-] Class setup logging Record 3 test case in progress with test_id 0ŋ �/�@�^(�Sԗ&@|aic_aqa_infrastructure_sonobuoy_plugins.host_info.tests.network.test_calico_logs.TestCalicoLogs.test_flow_log_file_retentionworker-0 Record 4 log statements from the test case method but no test_id and file_name=stdout 0��Q�'�A�^(�S�a ________________________________ worker-0stdoutA�2020-01-22 11:24:35.350 24600 INFO aic_aqa_infrastructure_sonobuoy_plugins.host_info.tests.network.test_calico_logs [-] Sample log message 1 2020-01-22 11:24:35.358 24600 INFO aic_aqa_infrastructure_sonobuoy_plugins.host_info.tests.network.test_calico_logs [-] Sample log message 2 2020-01-22 11:24:35.359 24600 INFO aic_aqa_infrastructure_sonobuoy_plugins.host_info.tests.network.test_calico_logs [-] Sample log message 3 0�K��/�@�^(�S�n�0@|aic_aqa_infrastructure_sonobuoy_plugins.host_info.tests.network.test_calico_logs.TestCalicoLogs.test_flow_log_file_retentionworker-00N}� Thanks in advance for any help on this. Doug Schveninger Lead Software Engineer douglas.schveninger(a)att.com<mailto:douglas.schveninger@att.com> Office: (314) 450-3311

2 1

[api][sdk][dev][oslo] using uWSGI breaks CORS config
by Radosław Piliszek 22 Jan '20

22 Jan '20

Fellow Devs, as you might have noticed I started taking care of openstack/js-openstack-lib, now under the openstacksdk umbrella [1]. First goal is to modernize the CI to use Zuul v3, current devstack and nodejs, still WIP [2]. As part of the original suite of tests, the unit and functional tests are run from browsers as well as from node. And, as you may know, browsers care about CORS [3]. js-openstack-lib is connecting to various OpenStack APIs (currently limited to keystone, glance, neutron and nova) to act on behalf of the user (just like openstacksdk/client does). oslo.middleware, as used by those APIs, provides a way to configure CORS by setting params in the [cors] group but uWSGI seemingly ignores that completely [4]. I had to switch to mod_wsgi+apache instead of uwsgi+apache to get past that issue. I could not reproduce locally because kolla (thankfully) uses mostly mod_wsgi atm. The issue I see is that uWSGI is proposed as the future and mod_wsgi is termed deprecated. However, this means the future is broken w.r.t. CORS and so any modern web interface with it if not sitting on the exact same host and port (which is usually different between OpenStack APIs and any UI). [1] https://review.opendev.org/701854 [2] https://review.opendev.org/702132 [3] https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS [4] https://github.com/unbit/uwsgi/issues/1550 -yoctozepto

4 8

Re: [Release-job-failures] Release of openstack/tempest for ref refs/tags/23.0.0 failed
by Sean McGinnis 22 Jan '20

22 Jan '20

On 1/22/20 11:01 AM, zuul(a)openstack.org wrote: > Build failed. > > - release-openstack-python https://zuul.opendev.org/t/openstack/build/f56e6adb34c7425e8bda31ab29db4642 : SUCCESS in 3m 55s > - announce-release https://zuul.opendev.org/t/openstack/build/864c651598e74abca8c15a1aedee01c6 : SUCCESS in 4m 39s > - propose-update-constraints https://zuul.opendev.org/t/openstack/build/38926e79572e48c6909abb878df6ce88 : FAILURE in 15m 55s > > _______________________________________________ > Release-job-failures mailing list > Release-job-failures(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures We found there was a memory issue on one of the gitea servers that caused errors while trying to perform a clone. Everything was fine with the release other than proposing raising the upper constraints in openstack/requirements. I have manually proposed the update here: https://review.opendev.org/#/c/703863/ Sean

1 0

[Cyborg][Ironic][Nova][Neutron][TripleO][Cinder] accelerators management
by Arkady.Kanevsky＠dell.com 22 Jan '20

22 Jan '20

Fellow Open Stackers, I have been thinking on how to handle SmartNICs, GPUs, FPGA handling across different projects within OpenStack with Cyborg taking a leading role in it. Cyborg is important project and address accelerator devices that are part of the server and potentially switches and storage. It is address 3 different use cases and users there are all grouped into single project. 1. Application user need to program a portion of the device under management, like GPU, or SmartNIC for that app usage. Having a common way to do it across different device families and across different vendor is very important. And that has to be done every time a VM is deploy that need usage of a device. That is tied with VM scheduling. 2. Administrator need to program the whole device for specific usage. That covers the scenario when device can only support single tenant or single use case. That is done once during OpenStack deployment but may need reprogramming to configure device for different usage. May or may not require reboot of the server. 3. Administrator need to setup device for its use, like burning specific FW on it. This is typically done as part of server life-cycle event. The first 2 cases cover application life cycle of device usage. The last one covers device life cycle independently how it is used. Managing life cycle of devices is Ironic responsibility, One cannot and should not manage lifecycle of server components independently. Managing server devices outside server management violates customer service agreements with server vendors and breaks server support agreements. Nova and Neutron are getting info about all devices and their capabilities from Ironic; that they use for scheduling. We should avoid creating new project for every new component of the server and modify nova and neuron for each new device. (the same will also apply to cinder and manila if smart devices used in its data/control path on a server). Finally we want Cyborg to be able to be used in standalone capacity, say for Kubernetes. Thus, I propose that Cyborg cover use cases 1 & 2, and Ironic would cover use case 3. Thus, move all device Life-cycle code from Cyborg to Ironic. Concentrate Cyborg of fulfilling the first 2 use cases. Simplify integration with Nova and Neutron for using these accelerators to use existing Ironic mechanism for it. Create idempotent calls for use case 1 so Nova and Neutron can use it as part of VM deployment to ensure that devices are programmed for VM under scheduling need. Create idempotent call(s) for use case 2 for TripleO to setup device for single accelerator usage of a node. [Propose similar model for CNI integration.] Let the discussion start! Thanks., Arkady

7 18

[magnum] podman fedora-coreos authorization failed: SSL exception connecting on keystone
by Ionut Biru 22 Jan '20

22 Jan '20

Hello guys, I'm trying to deploy a kubernetes cluster using magnum 9.2 with fedora-coreos-31.20200113.3.1-openstack. Master vm is deployed correctly but the cluster is never deployed since podman returns the following error: Jan 21 21:55:14 k8s-cluster002-mn5qgp6qlmw6-master-0 podman[2433]: Authorization failed: SSL exception connecting to https://api.mydomain.cloud:5000/v3/auth/tokens: HTTPSConnectionPool(host='api.mydomain.cloud', port=5000): Max retries exceeded with url: /v3/auth/tokens (Caused by SSLError(SSLError(185090184, u'[X509] no certificate or crl found (_ssl.c:3063)'),)) I do have a valid letsencrypt certification on that particular domain. curl https://api.mydomain.cloud:5000/v3/auth/tokens {"error": {"message": "The request you have made requires authentication.", "code": 401, "title": "Unauthorized"}} I was wondering, do you guys seen this issue before? Below is the template. https://paste.xinu.at/OC0Ic/ -- Ionut Biru - https://fleio.com

2 4

Rails Girls Summer of Code
by Amy Marrich 22 Jan '20

22 Jan '20

Hi All, I was contacted about this program to see if OpenStack might be interested in participating and despite the name it is language agnostic. Moe information on the program can be found at Rails Girls Summer of Code, <https://railsgirlssummerofcode.org/about/> I'm willing to help organize our efforts but would need to know level of interest to participate and mentor. Thanks, Amy (spotz) Chair, Diversity and Inclusion WG Chair, User Committee

2 3

[ironic][nova][neutron][cloud-init] Infiniband Support in OpenStack
by Kumari, Madhuri 22 Jan '20

22 Jan '20

Hi, I am trying to deploy a node with infiniband in Ironic without any success. The node has two interfaces, eth0 and ib0. The deployment is successful, node becomes active but is not reachable. I debugged and checked that the issue is with cloud-init. The cloud-init fails to configure the network interfaces on the node complaining that the MAC address of infiniband port(ib0) is not known to the node. Ironic provides a fake MAC address for infiniband ports and cloud-init is supposed to generate the actual MAC address of infiband ports[1]. But it fails[2] before reaching there. I have posted the issue in cloud-init[3] as well. Can someone please help me with this issue? How do we specify "TYPE=InfiniBand" from OpenStack? Currently the type sent is "phy" only. [1] https://github.com/canonical/cloud-init/blob/master/cloudinit/sources/helpe… [2] https://github.com/canonical/cloud-init/blob/master/cloudinit/sources/helpe… [3] https://bugs.launchpad.net/cloud-init/+bug/1857031 Regards, Madhuri

3 5

[nova] block_device_info being introduced to nova.virt.driver.ComputeDriver.rescue
by Lee Yarwood 22 Jan '20

22 Jan '20

Hello all, Just a heads up that as part of my work introducing stable device rescue to Nova the following change will be introducing an additional block_device_info argument to the signature of nova.virt.driver.ComputeDriver.rescue. virt: Provide block_device_info during rescue https://review.opendev.org/#/c/700811/ Any third party drivers implementing instance rescue will need to be updated. Cheers, -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76

1 0

Updating Openstack from Pike non-containerised to something current
by Tony Pearce 22 Jan '20

22 Jan '20

I am planning to upgrade my Openstack Pike. Please could I ask some questions about this so I understand better how to proceed? *Background*: - I have Openstack Pike running on 3 nodes (2 x compute and 1 x controller). Storage is provided by a Cinder driver and separate vendor storage array (iSCSI). - I have a bug which is impacting Cinder in Pike which is not present in Queens/Stein. - Since I installed Openstack some years ago, I was not able to update/patch it for a number of reasons. - The Openstack which I installed was from the tripleo.org website and I followed the instructions there. - I have configured LBaaS that was available in Pike by making config changes to .conf files. - I recall reading a few months ago when I started looking into this that I need to update to the latest within the current version (Pike) first, before updating beyond Pike so I am planning for that. *Questions*: 1. do I first need to deconfigure / remove the LBaaS before attempting an upgrade beyond Pike? 2. The tripleo website is a little confusing. I am running Pike and it is not containerised. The upgrade info on tripleo.org mentions upgrades to Pike in a containerised environment. So should I follow the detail for the "Ocata and earlier" release in this case? ref: http://tripleo.org/upgrade/minor_update.html#updating-your-overcloud-ocata-… 3. Do I need to upgrade to each release? ie from Pike > Queens then Queens > Stein etc ? Or can I do this: a) update Pike to the latest in the current Pike release b) Update Pike to Train *What I've gathered so far:* - If I can execute the 'openstack overcloud update' and limit it to the controller node then I can apply this to a cloned environment consisting of 1 x undercloud "director" and 1 x controller but I am unable to stage this for the compute nodes because they are physical bare-metal - the tripleo website guide lists the latest as 'Rocky' but I could see Stein in the yum search. I think I can follow the tripleo guide with a pinch of salt and replace *rocky* with *stein* Thank you *Tony Pearce* | *Senior Network Engineer / Infrastructure Lead**Cinglevue International <https://www.cinglevue.com>* Email: tony.pearce(a)cinglevue.com Web: http://www.cinglevue.com *Australia* 1 Walsh Loop, Joondalup, WA 6027 Australia. Direct: +61 8 6202 0036 | Main: +61 8 6202 0024 Note: This email and all attachments are the sole property of Cinglevue International Pty Ltd. (or any of its subsidiary entities), and the information contained herein must be considered confidential, unless specified otherwise. If you are not the intended recipient, you must not use or forward the information contained in these documents. If you have received this message in error, please delete the email and notify the sender.

2 3

volume local cache
by Fang, Liang A 22 Jan '20

22 Jan '20

Hi Gibi, Dan, Alex and dear Nova cores Nova Spec: https://review.opendev.org/#/c/689070/ Cinder Spec: https://review.opendev.org/#/c/684556/ Regarding the volume local cache spec, after several rounds of discussion in cinder weekly meeting, we continued discussed in cinder virtual mid-cycle ptg yesterday, and now cinder team is close to get agreement, and major ideas are: * Cinder sets “cacheable” property in volume type * Cinder should guarantee “cacheable” is set correctly, that means: should not set with “multiattach”, should not set for a backend that cannot be cached (NFS, RBD) * Os-brick prevents to attach a volume with cache mode that not safe in cloud environment * e.g. prevent write-back cache mode. So that all the operations, like live migration/snapshot/consistent group/volume backup can work as usual. * Nova schedules the VM with “cacheable” volume to servers with cache capability. * If no such available server, just go ahead without cache, but don’t fail it. * Schedule based on flavor (need more design here with Nova expert) Could you please comment on cinder spec if any before cinder team getting this hammered out? Thank you so much. Below is the performance test I did personally, using Optane SSD p4800x 750G as the cache. Setting fio with block size = 4k, iodepth=1 which is typical for latency measurement. The data may be slightly different on different environment, just FYI: In rand read test: [cid:image004.png@01D5D107.23D05610] In rand write test: [cid:image006.png@01D5D107.23D05610] In 70% rand read + 30% rand write mix test: [cid:image009.png@01D5D107.23D05610] Ceph in above chart means the baseline test, as shown in path ① below. Write-Through and Write-Back means open-cas cached, as shown in path②. [cid:image010.png@01D5D0FD.83839680] So even write-through mode, we still have lots of performance gains. Some concerns maybe: * In real world, the cache hit rate may cannot be so high (95% and more). * It depends on how big the cache device is. But normally a fast SSD with x TB size or a persistent memory with 512G size is big enough for hot data cache. * What will happen when backend storage is RDMA * Pure RDMA network link latency would be as low as ~10us. If plus the disk io to the storage system, the final latency would be dozens of microseconds. So it’s not suitable for an fast ssd(itself ~10us) to cache for RDMA volume, but we can use persistent memory (with latency about hundreds of nanosecond) to do the cache. I will do the measurement after Chinese new year. * It’s a pain that ceph cannot be supported * The major concern to mount ceph volume to host OS is the security considerations, right? It is a performance / security tradeoff for operators. In private cloud which OpenStack maybe mostly used, trust host OS would may be not a big problem, anyway, other backends rather than ceph are still doing in this way. I’m not going to change ceph to mount to host OS in this spec, but it’s not difficult for customer to switch to this way, like they customized other things. Regards LiangFang

1 0

[cinder] virtual mid-cycle summary available
by Brian Rosmaita 22 Jan '20

22 Jan '20

Hello Cinderinos, Thanks for a productive discussion today. I've posted a summary on the wiki so we can remember what happened and for the edification of those who didn't attend: https://wiki.openstack.org/wiki/CinderUssuriMidCycleSummary Also, I've posted a mid-cycle survey to get some feedback about the virtual connectivity and the format of today's meeting: https://forms.gle/muR2vMArZ7Eu1iV46 Please take the survey even if you didn't attend. (What I'm hoping to learn from the non-attendees is whether I could've communicated the event better, or whether the content was un-interesting, or what.) We'll be holding Session Two of the mid-cycle in a few weeks, so your feedback will be helpful in planning. cheers, brian PS: If the survey linked above is inaccessible in your country, please let me know and I'll figure something out so I can collect your feedback. The alternative to google forms I used last time was pretty limited in its free version, plus the only people who used it were located in countries where I know google forms are accessible (Europe & USA), so I succumbed to inertia and stuck with google forms.

1 0

[tc] Follow-up on action tems
by Jean-Philippe Evrard 21 Jan '20

21 Jan '20

Hello TC members, Here are a few things that should keep your attention, on top of the usual reviews... - We should start the business opportunities for 2020. Any takers? - We have action items from the last meeting: - ttx to post a summary of large scale sig's meeting on the ML this week. - mnaser to follow up on the static hosting - mnaser to push an update to distill what happened on the ML in terms of stable branch policy - jungleboyj to update the survey report patch - everyone to let the multi-arch SIG ( https://etherpad.openstack.org/p/Multi-arch) know if you have CI resources in different architectures - We have also new action items: - We should update the governance dashboard to include the "ideas" repo. Anyone? - We need to keep tracking on Telemetry status ( http://lists.openstack.org/pipermail/openstack-discuss/2019-December/011586… ). - Our next meeting will host on 6 February. You can provide suggestion on agenda https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee - ttx should report on his investigation on possible bylaws change for an eventual leadership (tc/uc) merge, UC was more or less okay with the idea, which allows to continue forward the investigation. Note: There is no official stance from the TC on this yet. It's just investigation. - We have updated SIGs tags with https://review.opendev.org/#/c/695625/. This will make sure people aware of the actual status. And as mentioned action ttx and ricolin will works on expose that status tag on governance-sigs' page. And finally, some things to keep in mind: - We need to promote the first contact sig to organisations that might need help on getting things achieved in OpenStack - We need to start collecting ideas for the ideas repo. Regards, JP & Rico

1 0

[all][tc] What happened in OpenStack Governance recently
by Jean-Philippe Evrard 21 Jan '20

21 Jan '20

Hello everyone, It's official, the V release will be codenamed Victoria! The TC is now working on declaring its runtimes [A]. The TC has merged a change in its charter, establishing new rules for the future terms [B]. This will give us leeway for elections and term lengths. The cycle goals selection schedule was made clearer, so that we don't add goals to the teams too late in the future [C]. We have selected the 'project specific PTL and contributor guides' as an official goal for Ussuri. I invite you to read the update of Ghanshyam Mann (gmann) to follow what's going on for our Ussuri goals [D]. You should also have a look at the zuul legacy migration [G], as it could eventually be selected as a V goal :) In terms of release naming, we'll start the W naming process soon, because we know that naming things are hard [E]. If you're interested by security policy, you can have a look at Jeremy's patch [F]. In terms of projects: - There is a new official charm, for watcher [H] - js-openstack-lib is now part of the openstacksdk team [I] - there is a new neutron project, ovn-octavia-provider [J] - the ansible-sig got a new repository, ansible-plugin-container- connection [K] - Justin Ferrieu is the PTL for Cloudkitty for the rest of the cycle [L] - sushi-cli is now part of the ironic team [M] Happy new year to our Chinese community! Regards, Jean-Philippe & Rico [A]: https://review.opendev.org/#/c/693743/ [B]: https://review.opendev.org/#/c/699277/ [C]: https://review.opendev.org/#/c/698299/ [D]: http://lists.openstack.org/pipermail/openstack-discuss/2020-January/012019.… [E]: https://review.opendev.org/#/c/702414/ [F]: https://review.opendev.org/#/c/678426/ [G]: https://review.opendev.org/#/c/691278/ [H]: https://review.opendev.org/#/c/702072/ [I]: https://review.opendev.org/#/c/701854/ [J]: https://review.opendev.org/#/c/697095/ [K]: https://review.opendev.org/#/c/696737/ [L]: https://review.opendev.org/#/c/701214/ [M]: https://review.opendev.org/#/c/700914/

1 0

[all][ci] Gate jobs failures because of broken pip
by Takashi Kajinami 21 Jan '20

21 Jan '20

Hi All, I now observe some of the gate jobs are failing[1] because of broken pip[2], and it guess that we need to pin pip to avoid the error atm. [1] https://81b633e2c5fe858f8400-d324a81a71d524d51ede3dc5aee27774.ssl.cf5.rackc… [2] https://github.com/pypa/pip/issues/7217 May I ask for some help to set that pinning ? I couldn't find the correct way to pin pip after several investigation ... Thank you, Takashi -- ---------- Takashi Kajinami Software Maintenance Engineer Customer Experience and Engagement Red Hat e-mail: tkajinam(a)redhat.com

3 2

[tripleo][ironic][ansible][openstack-ansible] Ironic/Baremetal Ansible modules
by Sagi Shnaidman 21 Jan '20

21 Jan '20

Hi, all in the light of finding the new home place for openstack related ansible modules [1] I'd like to discuss the best strategy to create Ironic ansible modules. Existing Ironic modules in Ansible repo don't cover even half of Ironic functionality, don't fit current needs and definitely require an additional work. There are a few topics that require attention and better be solved before modules are written to save additional work. We prepared an etherpad [2] with all these questions and if you have ideas or suggestions on how it should look you're welcome to update it. We'd like to decide the final place for them, name conventions (the most complex one!), what they should look like and how better to implement. Anybody interested in Ansible and baremetal management in Openstack, you're more than welcome to contribute. Thanks [1] https://review.opendev.org/#/c/684740/ [2] https://etherpad.openstack.org/p/ironic-ansible-modules -- Best regards Sagi Shnaidman

9 18

[horizon][cloudkitty][tacker][masakari][congress][karbar][trove] Drop python2.7 and Django1.11 support in horizon plugins
by Akihiro Motoki 21 Jan '20

21 Jan '20

Hi, I am sending this mail to encourage reviews in horizon plugins. - Drop python 2.7 and Django 1.11 - Remove six usage Horizon has dropped python 2.7 support and Django 1.11 support (which is the last version with python 2.7 support). We proposed changes to horizon plugins to catch up with these changes. - Most projects have merged them. Thanks for your cooperation. - There are several pending reviews. https://review.opendev.org/#/q/topic:drop-django111-support+status:open - Django 1.11 drop depends on python 2.7 drop. In case of karbar-dashboard, python 2.7 drop needs to land before it. https://review.opendev.org/#/c/694442/ horizon also has dropped six usage. There are plugins which depends six on horizon requirements. We proposed a series of changes to avoid UT breakages in plugins. Reviews on them are also appreciated. https://review.opendev.org/#/q/topic:remove-six+status:open Thanks, Akihiro Motoki (amotoki)

1 0

[queens][nova] iscsi issue
by Ignazio Cassano 21 Jan '20

21 Jan '20

Hello all we are testing openstack queens cinder driver for Unity iscsi (driver cinder.volume.drivers.dell_emc.unity.Driver). The unity storage is a Unity600 Version 4.5.10.5.001 We are facing an issue when we try to detach volume from a virtual machine with two or more volumes attached (this happens often but not always): The following is reported nova-compute.log: 2020-01-17 16:05:11.132 6643 ERROR oslo_messaging.rpc.server self.connector.disconnect_volume(connection_info['data'], None) 2020-01-17 16:05:11.132 6643 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/os_brick/utils.py", line 137, in trace_logging_wrapper 2020-01-17 16:05:11.132 6643 ERROR oslo_messaging.rpc.server return f(*args, **kwargs) 2020-01-17 16:05:11.132 6643 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py", line 274, in inner 2020-01-17 16:05:11.132 6643 ERROR oslo_messaging.rpc.server return f(*args, **kwargs) 2020-01-17 16:05:11.132 6643 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/os_brick/initiator/connectors/iscsi.py", line 848, in disconnect_volume 2020-01-17 16:05:11.132 6643 ERROR oslo_messaging.rpc.server device_info=device_info) 2020-01-17 16:05:11.132 6643 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/os_brick/initiator/connectors/iscsi.py", line 892, in _cleanup_connection 2020-01-17 16:05:11.132 6643 ERROR oslo_messaging.rpc.server path_used, was_multipath) 2020-01-17 16:05:11.132 6643 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/os_brick/initiator/linuxscsi.py", line 271, in remove_connection 2020-01-17 16:05:11.132 6643 ERROR oslo_messaging.rpc.server self.flush_multipath_device(multipath_name) 2020-01-17 16:05:11.132 6643 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/os_brick/initiator/linuxscsi.py", line 329, in flush_multipath_device 2020-01-17 16:05:11.132 6643 ERROR oslo_messaging.rpc.server root_helper=self._root_helper) 2020-01-17 16:05:11.132 6643 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/os_brick/executor.py", line 52, in _execute 2020-01-17 16:05:11.132 6643 ERROR oslo_messaging.rpc.server result = self.__execute(*args, **kwargs) 2020-01-17 16:05:11.132 6643 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/os_brick/privileged/rootwrap.py", line 169, in execute 2020-01-17 16:05:11.132 6643 ERROR oslo_messaging.rpc.server return execute_root(*cmd, **kwargs) 2020-01-17 16:05:11.132 6643 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/oslo_privsep/priv_context.py", line 207, in _wrap 2020-01-17 16:05:11.132 6643 ERROR oslo_messaging.rpc.server return self.channel.remote_call(name, args, kwargs) 2020-01-17 16:05:11.132 6643 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/oslo_privsep/daemon.py", line 202, in remote_call 2020-01-17 16:05:11.132 6643 ERROR oslo_messaging.rpc.server raise exc_type(*result[2]) 2020-01-17 16:05:11.132 6643 ERROR oslo_messaging.rpc.server ProcessExecutionError: Unexpected error while running command. 2020-01-17 16:05:11.132 6643 ERROR oslo_messaging.rpc.server Command: multipath -f 36006016006e04400d0c4215e3ec55757 2020-01-17 16:05:11.132 6643 ERROR oslo_messaging.rpc.server Exit code: 1 2020-01-17 16:05:11.132 6643 ERROR oslo_messaging.rpc.server Stdout: u'Jan 17 16:04:30 | 36006016006e04400d0c4215e3ec55757p1: map in use\nJan 17 16:04:31 | failed to remove multipath map 36006016006e04400d0c4215e3ec55757\n' 2020-01-17 16:05:11.132 6643 ERROR oslo_messaging.rpc.server Stderr: u'' 2020-01-17 16:05:11.132 6643 ERROR oslo_messaging.rpc.server Best Regards Ignazio

2 2

[magnum][kolla] etcd wal sync duration issue
by Eric K. Miller 21 Jan '20

21 Jan '20

Hi, We are using the following coe cluster template and cluster create commands on an OpenStack Stein installation that installs Magnum 8.2.0 Kolla containers installed by Kolla-Ansible 8.0.1: openstack coe cluster template create \ --image Fedora-AtomicHost-29-20191126.0.x86_64_raw \ --keypair userkey \ --external-network ext-net \ --dns-nameserver 1.1.1.1 \ --master-flavor c5sd.4xlarge \ --flavor m5sd.4xlarge \ --coe kubernetes \ --network-driver flannel \ --volume-driver cinder \ --docker-storage-driver overlay2 \ --docker-volume-size 100 \ --registry-enabled \ --master-lb-enabled \ --floating-ip-disabled \ --fixed-network KubernetesProjectNetwork001 \ --fixed-subnet KubernetesProjectSubnet001 \ --labels kube_tag=v1.15.7,cloud_provider_tag=v1.15.0,heat_container_agent_tag=ste in-dev,master_lb_floating_ip_enabled=true \ k8s-cluster-template-1.15.7-production-private openstack coe cluster create \ --cluster-template k8s-cluster-template-1.15.7-production-private \ --keypair userkey \ --master-count 3 \ --node-count 3 \ k8s-cluster001 The deploy process works perfectly, however, the cluster health status flips between healthy and unhealthy. The unhealthy status indicates that etcd has an issue. When logged into master-0 (out of 3, as configured above), "systemctl status etcd" shows the stdout from etcd, which shows: Jan 11 17:27:36 k8s-cluster001-4effrc2irvjq-master-0.novalocal runc[2725]: 2020-01-11 17:27:36.548453 W | etcdserver: timed out waiting for read index response Jan 11 17:28:02 k8s-cluster001-4effrc2irvjq-master-0.novalocal runc[2725]: 2020-01-11 17:28:02.960977 W | wal: sync duration of 1.696804699s, expected less than 1s Jan 11 17:28:31 k8s-cluster001-4effrc2irvjq-master-0.novalocal runc[2725]: 2020-01-11 17:28:31.292753 W | wal: sync duration of 2.249722223s, expected less than 1s We also see: Jan 11 17:40:39 k8s-cluster001-4effrc2irvjq-master-0.novalocal runc[2725]: 2020-01-11 17:40:39.132459 I | etcdserver/api/v3rpc: grpc: Server.processUnaryRPC failed to write status: stream error: code = DeadlineExceeded desc = "context deadline exceeded" We initially used relatively small flavors, but increased these to something very large to be sure resources were not constrained in any way. "top" reported no CPU nor memory contention on any nodes in either case. Multiple clusters have been deployed, and they all have this issue, including empty clusters that were just deployed. I see a very large number of reports of similar issues with etcd, but discussions lead to disk performance, which can't be the cause here, not only because persistent storage for etcd isn't configured in Magnum, but also the disks are "very" fast in this environment. Looking at "vmstat -D" from within master-0, the number of writes is minimal. Ceilometer logs about 15 to 20 write IOPS for this VM in Gnocchi. Any ideas? We are finalizing procedures to upgrade to Train, so we wanted to be sure that we weren't running into some common issue with Stein that would immediately be solved with Train. If so, we will simply proceed with the upgrade and avoid diagnosing this issue further. Thanks! Eric

4 6

Galera config values
by Albert Braden 21 Jan '20

21 Jan '20

I'm experimenting with Galera in my Rocky openstack-ansible dev cluster, and I'm finding that the default haproxy config values don't seem to work. Finding the correct values is a lot of work. For example, I spent this morning experimenting with different values for "timeout client" in /etc/haproxy/haproxy.cfg. The default is 1m, and with the default set I see this error in /var/log/nova/nova-scheduler.log on the controllers: 2020-01-17 13:54:26.059 443358 ERROR oslo_db.sqlalchemy.engines DBConnectionError: (pymysql.err.OperationalError) (2013, 'Lost connection to MySQL server during query') [SQL: u'SELECT 1'] (Background on this error at: http://sqlalche.me/e/e3q8) There are several timeout values in /etc/haproxy/haproxy.cfg. These are the values we started with: stats timeout 30s timeout http-request 10s timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout check 10s At first I changed them all to 30m. This stopped the "Lost connection" error in nova-scheduler.log. Then, one at a time, I changed them back to the default. When I got to "timeout client" I found that setting it back to 1m caused the errors to start again. I changed it back and forth and found that 4 minutes causes errors, and 6m stops them, so I left it at 6m. These are my active variables: root@us01odc-dev2-ctrl1:/etc/mysql# mysql -e 'show variables;'|grep timeout connect_timeout 20 deadlock_timeout_long 50000000 deadlock_timeout_short 10000 delayed_insert_timeout 300 idle_readonly_transaction_timeout 0 idle_transaction_timeout 0 idle_write_transaction_timeout 0 innodb_flush_log_at_timeout 1 innodb_lock_wait_timeout 50 innodb_rollback_on_timeout OFF interactive_timeout 28800 lock_wait_timeout 86400 net_read_timeout 30 net_write_timeout 60 rpl_semi_sync_master_timeout 10000 rpl_semi_sync_slave_kill_conn_timeout 5 slave_net_timeout 60 thread_pool_idle_timeout 60 wait_timeout 3600 So it looks like the value of "timeout client" in haproxy.cfg needs to match or exceed the value of "wait_timeout" in mysql. Also in nova.conf I see "#connection_recycle_time = 3600" - I need to experiment to see how that value interacts with the timeouts in the other config files. Is this the best way to find the correct config values? It seems like there should be a document that talks about these timeouts and how to set them (or maybe more generally how the different timeout settings in the various config files interact). Does that document exist? If not, maybe I could write one, since I have to figure out the correct values anyway.

4 5

[openstack-helm] Core Reviewer Nominations
by Pete Birley 21 Jan '20

21 Jan '20

OpenStack-Helm team, Based on their record of quality code review and substantial/meaningful code contributions to the openstack-helm project, at last weeks meeting we proposed the following individuals as core reviewers for openstack-helm: - Gage Hugo - Steven Fitzpatrick All OpenStack-Helm Core Reviewers are invited to reply with a +1/-1 by EOD next Monday (27/1/2020). A lone +1/-1 will apply to both candidates, otherwise please spell out votes individually for the candidates. Cheers, Pete

2 1

[neutron] Bug deputy report for week of January 13th
by Brian Haley 20 Jan '20

20 Jan '20

Hi, I was Neutron bug deputy last week. Below is a short summary about reported bugs. -Brian Critical bugs ------------- * https://bugs.launchpad.net/neutron/+bug/1859988 - neutron-tempest-plugin tests fail for stable/queens - bcafarel picked up, related to below bug * https://bugs.launchpad.net/neutron/+bug/1860033 - neutron tempest jobs broken on rocky due to requirements neutron-lib upgrade - many proposed changes, discussion on ML High bugs --------- * https://bugs.launchpad.net/neutron/+bug/1859977 - [OVN] Update of floatingip creates new row in NBDB NAT table - maciej picked up * https://bugs.launchpad.net/neutron/+bug/1860140 - [OVN] Provider driver sends malformed update to Octavia - https://review.opendev.org/#/c/703097 * https://bugs.launchpad.net/neutron/+bug/1860141 - [OVN] Provider driver fails while LB VIP port already created - https://review.opendev.org/#/c/703110 Medium bugs ----------- * https://bugs.launchpad.net/neutron/+bug/1859832 - L3 HA connectivity to GW port can be broken after reboot of backup node - Issue with MLDv2 packet causing issues with connections - Slawek picked up ownership * https://bugs.launchpad.net/neutron/+bug/1860273 - https://review.opendev.org/#/c/703292/ Low bugs -------- * https://bugs.launchpad.net/neutron/+bug/1859765 - Sgs of device_owner_network port can be update without specifing "device_owner" attr - https://review.opendev.org/#/c/702632/ - discussion in review * https://bugs.launchpad.net/neutron/+bug/1859962 - Sanity checks comparing versions should not use decimal comparison - https://review.opendev.org/#/c/702847/ Wishlist bugs ------------- Invalid bugs ------------ * https://bugs.launchpad.net/neutron/+bug/1859638 - VIP between dvr east-west networks does not work at all - Duplicate of https://bugs.launchpad.net/neutron/+bug/1774459 * https://bugs.launchpad.net/neutron/+bug/1859976 - Removing smart_nic port in openstack will try to delete representor port - os-vif issue Further triage required ----------------------- * https://bugs.launchpad.net/neutron/+bug/1859362 - Neutron accepts arbitrary MTU values for networks - Rodolfo has some questions on the bug * https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1859649 - networking disruption on upgrade from 14.0.0 to 14.0.3 - Rodolfo had question about restart order of services * https://bugs.launchpad.net/neutron/+bug/1859887 - External connectivity broken because of stale FIP rule - Asked for release information, etc * https://bugs.launchpad.net/networking-ovn/+bug/1859965 - networking-ovn's octavia api，how get octavia-api DB use python code? - networking-ovn octavia driver bug? asked for more information

2 1

[release] Python universal wheel support
by Sean McGinnis 20 Jan '20

20 Jan '20

Greetings, We have just merged a change to the release-openstack-python job that changes the wheels we produce to not be universal. For some background - we added an explicit flag of "--universal" to the creation of wheels a while back. For projects that have both Python 2 and 3 support, you want an universal wheel. Not all (probably most) projects did not add this flag to their setup.cfg, so overriding at the release job level was considered a good way to make sure our output was what we wanted at the time. We now have the majority of projects dropping py2 support, so we actually no longer want to create these universal wheels if py2 support has been dropped. That has actually been seen to cause some issues. The downside with this change is that the job is for *all* deliverables we release, including stable releases. So with this change, any new stable branches will no longer get universal wheels if the flag has not been set locally. This was deemed a good tradeoff with the current needs though. The lack of a univeral wheel may just make installation of py2 stable deliverables just slightly slower, but should not cause any real issues. Actions ------ Most likely this won't require any actions on the project team's part. If you have a project that still supports both py2 and py3 and do not have the flag set in setup.cfg, that can be added to still get the universal wheels built. That is done by adding the following: ``` [bdist_wheel] universal = 1 ``` Again, the performance impact is probably very minimal during installation, so this shouldn't be a major concern. If there are any oddities noticed after this change, please bring them up and we can help investigate what is happening. Thanks! Sean

1 0

[Multi-Arch-sig] Meeting this week
by Rico Lin 20 Jan '20

20 Jan '20

Hi all. As reminder, we will host our meeting this week. Tuesday at 0800 UTC in #openstack-meeting-alt and 1500 UTC in #openstack-meeting . Feel free to propose agenda here https://etherpad.openstack.org/p/Multi-Arch-agenda See you all in meeting:) -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

1 0

Cinder snapshot delete successful when expected to fail
by Tony Pearce 20 Jan '20

20 Jan '20

Could anyone help by pointing me where to go to be able to dig into this issue further? I have installed a test Openstack environment using RDO Packstack. I wanted to install the same version that I have in Production (Pike) but it's not listed in the CentOS repo via yum search. So I installed Queens. I am using nimble.py Cinder driver. Nimble Storage is a storage array accessed via iscsi from the Openstack host, and is controlled from Openstack by the driver and API. *What I expected to happen:* 1. create an instance with volume (the volume is created on the storage array successfully and instance boots from it) 2. take a snapshot (snapshot taken on the volume on the array successfully) 3. create a new instance from the snapshot (the api tells the array to clone the snapshot into a new volume on the array and use that volume for the instance) 4. try and delete the snapshot Expected Result - Openstack gives the user a message like "you're not allowed to do that". Note: Step 3 above creates a child volume from the parent snapshot. It's impossible to delete the parent snapshot because IO READ is sent to that part of the original volume (as I understand it). *My production problem is this: * 1. create an instance with volume (the volume is created on the storage array successfully) 2. take a snapshot (snapshot taken on the volume on the array successfully) 3. create a new instance from the snapshot (the api tells the array to clone the snapshot into a new volume on the array and use that volume for the instance) 4. try and delete the snapshot Result - snapshot goes into error state and later, all Cinder operations fail such as new instance/create volume etc. until the correct service is restarted. Then everything works once again. To troubleshoot the above, I installed the RDP Packstack Queens (because I couldnt get Pike). I tested the above and now, the result is the snapshot is successfully deleted from openstack but not deleted on the array. The log is below for reference. But I can see the in the log that the array sends back info to openstack saying the snapshot has a clone and the delete cannot be done because of that. Also response code 409. *Some info about why the problem with Pike started in the first place* 1. Vendor is Nimble Storage which HPE purchased 2. HPE/Nimble have dropped support for openstack. Latest supported version is Queens and Nimble array version v4.x. The current Array version is v5.x. Nimble say there are no guarantees with openstack, the driver and the array version v5.x 3. I was previously advised by Nimble that the array version v5.x will work fine and so left our DR array on v5.x with a pending upgrade that had a blocker due to an issue. This issue was resolved in December and the pending upgrade completed to match the DR array took place around 30 days ago. With regards to the production issue, I assumed that the array API has some changes between v4.x and v5.x and it's causing an issue with Cinder due to the API response. Although I have not been able to find out if or what changes there are that may have occurred after the array upgrade, as the documentation for this is Nimble internal-only. *So with that - some questions if I may:* When Openstack got the 409 error response from the API (as seen in the log below), why would Openstack then proceed to delete the snapshot on the Openstack side? How could I debug this further? I'm not sure what Openstack Cinder is acting on in terns of the response as yet. Maybe Openstack is not specifically looking for the error code in the response? The snapshot that got deleted on the openstack side is a problem. Would this be related to the driver? Could it be possible that the driver did not pass the error response to Cinder? Thanks in advance. Just for reference, the log snippet is below. ==> volume.log <== > 2020-01-17 16:53:23.718 24723 WARNING py.warnings > [req-60fe4335-af66-4c46-9bbd-2408bf4d6f07 df7548ecad684f26b8bc802ba63a9814 > 87e34c89e6fb41d2af25085b64011a55 - default default] > /usr/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py:852: > InsecureRequestWarning: Unverified HTTPS request is being made. Adding > certificate verification is strongly advised. See: > https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings > InsecureRequestWarning) > : NimbleAPIException: Failed to execute api > snapshots/0464a5fd65d75fcfe1000000000000011100001a41: Error Code: 409 > Message: Snapshot snapshot-3806efc5-65ca-495a-a87a-baaddc9607d9 for volume > volume-5b02db35-8d5c-4ef6-b0e7-2f9b62cac57e has a clone. > ==> api.log <== > 2020-01-17 16:53:23.769 25242 INFO cinder.api.openstack.wsgi > [req-bfcbff34-134b-497e-82b1-082d48f8767f df7548ecad684f26b8bc802ba63a9814 > 87e34c89e6fb41d2af25085b64011a55 - default default] > http://192.168.53.45:8776/v3/87e34c89e6fb41d2af25085b64011a55/volumes/detail > returned with HTTP 200 > 2020-01-17 16:53:23.770 25242 INFO eventlet.wsgi.server > [req-bfcbff34-134b-497e-82b1-082d48f8767f df7548ecad684f26b8bc802ba63a9814 > 87e34c89e6fb41d2af25085b64011a55 - default default] 192.168.53.45 "GET > /v3/87e34c89e6fb41d2af25085b64011a55/volumes/detail HTTP/1.1" status: 200 > len: 4657 time: 0.1152730 > ==> volume.log <== > 2020-01-17 16:53:23.811 24723 WARNING py.warnings > [req-60fe4335-af66-4c46-9bbd-2408bf4d6f07 df7548ecad684f26b8bc802ba63a9814 > 87e34c89e6fb41d2af25085b64011a55 - default default] > /usr/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py:852: > InsecureRequestWarning: Unverified HTTPS request is being made. Adding > certificate verification is strongly advised. See: > https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings > InsecureRequestWarning) > : NimbleAPIException: Failed to execute api > snapshots/0464a5fd65d75fcfe1000000000000011100001a41: Error Code: 409 > Message: Snapshot snapshot-3806efc5-65ca-495a-a87a-baaddc9607d9 for volume > volume-5b02db35-8d5c-4ef6-b0e7-2f9b62cac57e has a clone. > 2020-01-17 16:53:23.902 24723 ERROR cinder.volume.drivers.nimble > [req-60fe4335-af66-4c46-9bbd-2408bf4d6f07 df7548ecad684f26b8bc802ba63a9814 > 87e34c89e6fb41d2af25085b64011a55 - default default] Re-throwing Exception > Failed to execute api snapshots/0464a5fd65d75fcfe1000000000000011100001a41: > Error Code: 409 Message: Snapshot > snapshot-3806efc5-65ca-495a-a87a-baaddc9607d9 for volume > volume-5b02db35-8d5c-4ef6-b0e7-2f9b62cac57e has a clone.: > NimbleAPIException: Failed to execute api > snapshots/0464a5fd65d75fcfe1000000000000011100001a41: Error Code: 409 > Message: Snapshot snapshot-3806efc5-65ca-495a-a87a-baaddc9607d9 for volume > volume-5b02db35-8d5c-4ef6-b0e7-2f9b62cac57e has a clone. > 2020-01-17 16:53:23.903 24723 WARNING cinder.volume.drivers.nimble > [req-60fe4335-af66-4c46-9bbd-2408bf4d6f07 df7548ecad684f26b8bc802ba63a9814 > 87e34c89e6fb41d2af25085b64011a55 - default default] Snapshot > snapshot-3806efc5-65ca-495a-a87a-baaddc9607d9 : has a clone: > NimbleAPIException: Failed to execute api > snapshots/0464a5fd65d75fcfe1000000000000011100001a41: Error Code: 409 > Message: Snapshot snapshot-3806efc5-65ca-495a-a87a-baaddc9607d9 for volume > volume-5b02db35-8d5c-4ef6-b0e7-2f9b62cac57e has a clone. > 2020-01-17 16:53:23.964 24723 WARNING cinder.quota > [req-60fe4335-af66-4c46-9bbd-2408bf4d6f07 df7548ecad684f26b8bc802ba63a9814 > 87e34c89e6fb41d2af25085b64011a55 - default default] Deprecated: Default > quota for resource: snapshots_Nimble-DR is set by the default quota flag: > quota_snapshots_Nimble-DR, it is now deprecated. Please use the default > quota class for default quota. > 2020-01-17 16:53:24.054 24723 INFO cinder.volume.manager > [req-60fe4335-af66-4c46-9bbd-2408bf4d6f07 df7548ecad684f26b8bc802ba63a9814 > 87e34c89e6fb41d2af25085b64011a55 - default default] Delete snapshot > completed successfully. Regards, *Tony Pearce* | *Senior Network Engineer / Infrastructure Lead**Cinglevue International <https://www.cinglevue.com>* Email: tony.pearce(a)cinglevue.com Web: http://www.cinglevue.com *Australia* 1 Walsh Loop, Joondalup, WA 6027 Australia. Direct: +61 8 6202 0036 | Main: +61 8 6202 0024 Note: This email and all attachments are the sole property of Cinglevue International Pty Ltd. (or any of its subsidiary entities), and the information contained herein must be considered confidential, unless specified otherwise. If you are not the intended recipient, you must not use or forward the information contained in these documents. If you have received this message in error, please delete the email and notify the sender.

3 4

[nova] Nova CI busted, please hold rechecks
by Eric Fried 19 Jan '20

19 Jan '20

The nova-live-migration job is failing 100% since yesterday morning [1]. Your rechecks won't work until that's resolved. I'll send an all-clear message when we're green again. Thanks, efried [1] https://bugs.launchpad.net/nova/+bug/1860021

3 3

DR options with openstack
by Tony Pearce 19 Jan '20

19 Jan '20

7 13

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

17 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 16 Jan '20

16 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