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 14 May '20

14 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 07 May '20

07 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 04 Feb '20

04 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 02 Feb '20

02 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 01 Feb '20

01 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