September 2019 - openstack-discuss

Long, Slow Zuul Queues and Why They Happen
by Clark Boylan 23 Sep '19

23 Sep '19

Hello, We've been fielding a fair bit of questions and suggestions around Zuul's long change (and job) queues over the last week or so. As a result I tried to put a quick FAQ type document [0] on how we schedule jobs, why we schedule that way, and how we can improve the long queues. Hoping that gives us all a better understanding of why were are in the current situation and ideas on how we can help to improve things. [0] https://docs.openstack.org/infra/manual/testing.html#why-are-jobs-for-chang… Thanks, Clark

3 4

[neutron][drivers][ironic] FFE request - Use openstacksdk for ironic notifiers
by Riccardo Pittau 23 Sep '19

23 Sep '19

Hello fellow openstackers, I'd like to open an FFE request to convert the ironic events notifier from the current ironicclient to openstacksdk with the change https://review.opendev.org/682040 This requires also a bump of the versions of mock and openstacksdk in lower-constraints, included in the CR. The change has been tested in a devstack environment and passes the zuul checks. Thank you! Riccardo Pittau rpittau||elfosardo

4 5

[goals][IPv6-Only Deployments and Testing] Week R-3 Update
by Ghanshyam Mann 23 Sep '19

23 Sep '19

Hello Everyone, Below is the latest updated on IPv6 goal. All the projects have the ipv6 job patch proposed now. Next step is to review then as per mentioned guidelines below or help in debugging the failure. I saw tests are failing for the few projects which need debugging and help from the project team. Summary: The projects still need to prepare the IPv6 job: * None The projects waiting for IPv6 job patch to merge: If patch is failing, help me to debug that otherwise review and merge. * Barbican * Blazar * Cyborg * Tricircle * Vitrage * Zaqar * Glance * Monasca * Neutron * Qinling * Sahara * Searchlight * Senlin * Tacker * Ec2-Api * Freezer * Heat * Ironic * Karbor * Kuryr * Magnum * Masakari * Mistral * Murano * Octavia (johnsom is working on this and will take over the base patch) The projects have merged the IPv6 jobs: * Designate * Murano * Trove * Cloudkitty * Congress * Horizon * Keystone * Nova * Placement * Solum * Telemetry * Watcher * Zun * Cinder * Manila * Swift The projects do not need the IPv6 job (CLI, lib, deployment projects etc ): I have marked the tasks for below project as invalid. * Adjutant * Documentation * I18n * Infrastructure * Kolla * Loci * Openstack Charms * Openstack-Chef * Openstack-Helm * Openstackansible * Openstackclient * Openstacksdk * Oslo * Packaging-Rpm * Powervmstackers * Puppet Openstack * Rally * Release Management * Requirements * Storlets * Tripleo * Winstackers Storyboard: ========= - https://storyboard.openstack.org/#!/story/2005477 IPv6 missing support found: ===================== 1. https://review.opendev.org/#/c/673397/ 2. https://review.opendev.org/#/c/673449/ 3. https://review.opendev.org/#/c/677524/ There are few more but need to be tracked. How you can help: ============== - Each project needs to look for and review the ipv6 job patch. - Verify it works fine on ipv6 and no ipv4 used in conf etc - Any other specific scenario needs to be added as part of project IPv6 verification. - Help on debugging and fix the bug in IPv6 job is failing. Everything related to this goal can be found under this topic: Topic: https://review.opendev.org/#/q/topic:ipv6-only-deployment-and-testing+(stat… How to define and run new IPv6 Job on project side: ======================================= - I prepared a wiki page to describe this section - https://wiki.openstack.org/wiki/Goal-IPv6-only-deployments-and-testing Review suggestion: ============== - Main goal of these jobs will be whether your service is able to listen on IPv6 and can communicate to any other services either OpenStack or DB or rabbitmq etc on IPv6 or not. So check your proposed job with that point of view. If anything missing, comment on patch. - One example was - I missed to configure novnc address to IPv6- https://review.opendev.org/#/c/672493/ - base script as part of 'devstack-tempest-ipv6' will do basic checks for endpoints on IPv6 and some devstack var setting. But if your project needs more specific verification then it can be added in project side job as post-run playbooks as described in wiki page[1]. [1] https://wiki.openstack.org/wiki/Goal-IPv6-only-deployments-and-testing

1 0

[neutron] bug deputy report (the week of 2019-09-16)
by Takashi Yamamoto 23 Sep '19

23 Sep '19

here's the list of what we got reported in the week. features (nova bp follow-up) https://bugs.launchpad.net/neutron/+bug/1844131 Boot a VM with an unaddressed port High https://bugs.launchpad.net/neutron/+bug/1844168 [L3] TooManyExternalNetworks: More than one external network exists. A proposed fix: https://review.opendev.org/#/c/682418/ Medium https://bugs.launchpad.net/neutron/+bug/1844124 Not possible to change fixed-ips if port is on routed provider network A proposed fix: https://review.opendev.org/#/c/682489/ https://bugs.launchpad.net/neutron/+bug/1844516 [neutron-tempest-plugin] SSH timeout exceptions when executing remote commands A proposed fix: https://review.opendev.org/#/c/682864/ https://bugs.launchpad.net/neutron/+bug/1844688 "radvd" daemon does not work by default in some containers A proposed fix: https://review.opendev.org/#/c/683207/ Low https://bugs.launchpad.net/neutron/+bug/1844171 Configuration parameter missing at "Configure the layer-3 agent" A merged fix: https://review.opendev.org/#/c/682645/ https://bugs.launchpad.net/neutron/+bug/1844607 log error when create neutron port with wrong subnet A proposed fix: https://review.opendev.org/#/c/683273/ Incomplete https://bugs.launchpad.net/neutron/+bug/1844123 Unable to trigger IPv6 Prefix Delegation https://bugs.launchpad.net/neutron/+bug/1844595 openstackNova(Rocky)--chinese incorrect codes for db character error https://bugs.launchpad.net/neutron/+bug/1844915 Duplicate packets with two networks connected by router Invalid https://bugs.launchpad.net/neutron/+bug/1844097 Redundant ipv6 address(SLAAC/DHCPv6 stateless) created for port It was an intended behavior and the rationale was explained to the submitter.

1 0

zun-ui 4.0.0.0rc1 (train)
by no-reply＠openstack.org 23 Sep '19

23 Sep '19

Hello everyone, A new release candidate for zun-ui for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/zun-ui/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/zun-ui/log/?h=stable/train Release notes for zun-ui can be found at: https://docs.openstack.org/releasenotes/zun-ui/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/zun-ui/+bugs and tag it *train-rc-potential* to bring it to the zun-ui release crew's attention.

1 0

kuryr-libnetwork 4.0.0.0rc1 (train)
by no-reply＠openstack.org 23 Sep '19

23 Sep '19

Hello everyone, A new release candidate for kuryr-libnetwork for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/kuryr-libnetwork/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/kuryr-libnetwork/log/?h=stable/train Release notes for kuryr-libnetwork can be found at: https://docs.openstack.org/releasenotes/kuryr-libnetwork/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/kuryr-libnetwork/+bugs and tag it *train-rc-potential* to bring it to the kuryr-libnetwork release crew's attention.

1 0

Outreachy Application Deadline - Call for mentors and projects
by Samuel de Medeiros Queiroz 21 Sep '19

21 Sep '19

Hi everyone! Outreachy <https://www.outreachy.org/> helps people from underrepresented groups get involved in free and open source software by matching interns with established mentors in the upstream communities. OpenStack is a participating organization in the Outreachy Dec 2019 to Mar 2020 round. If you're interested to be a mentor, please register as a mentor in the Outreachy website and publish your project ideas. According to this round's schedule <https://www.outreachy.org/docs/applicant/#outreachy-schedule>, the initial application is due next week: - *Sept. 24, 2019 at 4pm UTC Initial application deadline * - *Nov. 5, 2019 at 4pm UTC Final application deadline* It is important to get projects submitted *as soon as possible* so that applicants can sign up before the *Sept. 24 deadline*. Once signed up, they will have between *Oct. 1, 2019 to Nov. 5, 2019 to contribute to the projects*. If you have any questions about becoming a mentor or want to sponsor an intern, please contact me (samueldmq(a)gmail.com) or Mahati Chamarthy ( mahati.chamarthy(a)gmail.com) Thank you, Samuel de Medeiros Queiroz

3 2

[keystone] Keystone Team Update - Week of 16 September 2019
by Colleen Murphy 21 Sep '19

21 Sep '19

# Keystone Team Update - Week of 16 September 2019 ## News ### RC1 Status Even after discovering some gaps in our policy migrations we managed to quickly cover them and are on track to close all our RC1-targeted bugs[1] on time! [1] https://launchpad.net/keystone/+milestone/train-rc1 ## Office Hours When there are topics to cover, the keystone team holds office hours on Tuesdays at 17:00 UTC. No office hours next week due to lack of topics. Add topics you would like to see covered during office hours to the etherpad: https://etherpad.openstack.org/p/keystone-office-hours-topics ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 32 changes this week. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 58 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ## Milestone Outlook https://releases.openstack.org/train/schedule.html We're on target to release RC1 next week. ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter

1 0

[ironic] Tips on testing custom hardware manager?
by Jason Anderson 21 Sep '19

21 Sep '19

Hi all, I am hoping to get some tips on how to test out a custom hardware manager. One of my colleagues is working on a project that involves implementing a custom in-band cleaning step, which we are implementing by creating our own ramdisk image that includes an extra library, which is necessary for the clean step. We already have created the image and ensured it has IPA installed and that all seems to work fine (in that, it executes on the node and we see our code running--and failing!) The issue we are having is that we encounter some issues in our fully integrated environment (such as the provisioning network having different networking rules) and replicating this environment in some local development context is very difficult. Right now our workflow is really onerous as a result: my colleague has to rebuild the ramdisk image, re-upload it to Glance, update the test Ironic node to reference that image, then perform a rebuild. One cycle of this takes a while as you can imagine. I was wondering: is it possible to somehow interrupt or give a larger window for some interactive debugging? The amount of time we have to run some quick tests/debugging is small because the deploy will time out and cancel itself or it will proceed and fail. Thusfar I haven't found any documentation or written experience on this admittedly niche task. Perhaps somebody has already gone down this road and can advise on some tips? It would be much appreciated! Cheers, -- Jason Anderson Chameleon DevOps Lead Consortium for Advanced Science and Engineering, The University of Chicago Mathematics & Computer Science Division, Argonne National Laboratory

2 2

[i18n][tc] The future of I18n
by Thierry Carrez 21 Sep '19

21 Sep '19

Hi! The I18n project team had no PTL candidates for Ussuri, so the TC needs to decide what to do with it. It just happens that Ian kindly volunteered to be an election official, and therefore could not technically run for I18n PTL. So if Ian is still up for taking it, we could just go and appoint him. That said, I18n evolved a lot, to the point where it might fit the SIG profile better than the project team profile. As a reminder, project teams are responsible for producing OpenStack-the-software, and since they are all integral in the production of the software that we want to release on a time-based schedule, they come with a number of mandatory tasks (like designating a PTL every 6 months). SIGs (special interest groups) are OpenStack teams that work on a mission that is not directly producing a piece of the OpenStack release. SIG members are bound by their mission, rather than by a specific OpenStack release deliverable. There is no mandatory task, as it is OK if the group goes dormant for a while. The I18n team regroups translators, with an interest of making OpenStack (in general, not just the software) more accessible to non-English speakers. They currently try to translate the OpenStack user survey, the Horizon dashboard messages, and key documentation. It could still continue as a project team (since it still produces Horizon translations), but I'd argue that at this point it is not what defines them. The fact that they are translators is what defines them, which IMHO makes them fit the SIG profile better than the project team profile. They can totally continue proposing translation files for Horizon as a I18n SIG, so there would be no technical difference. Just less mandatory tasks for the team. Thoughts ? -- Thierry Carrez (ttx)

4 4

Re: [Release-job-failures] release-post job for openstack/releases for ref refs/heads/master failed
by Sean McGinnis 21 Sep '19

21 Sep '19

On Fri, Sep 20, 2019 at 04:46:49PM +0000, zuul(a)openstack.org wrote: > Build failed. > > - tag-releases https://zuul.opendev.org/t/openstack/build/9413e62eae174733a7f577c6090c3059 : TIMED_OUT in 30m 56s > - publish-tox-docs-static https://zuul.opendev.org/t/openstack/build/None : SKIPPED > The tagging job failed here because I tried to include too many new branch creation requests in one patch. This job will be reenqueued so the processing runs again. The automation is smart enough to skip over the ones that have already been branched, so it should be able to just pick up where it left off. This was half way through processing the python-designateclient branching. The branch was created, and one of the two automatic stable patches were submitted before the job was killed. I have manually submitted the one that was missed here: https://review.opendev.org/#/c/683592/ Sean

1 0

[RelMgmt] Moving release team meeting for the week of Sept 23
by Sean McGinnis 21 Sep '19

21 Sep '19

Hey everyone, Due to travel conflicts next week, rather than cancelling the weekly meeting during the RC week we will be moving it to Friday at 15:00 UTC. This is a one time change of the meeting time. Afterwards we will return to our normal schedule of Thursday, 16:00 UTC. Let me know if there are any questions or concerns. Sean

1 0

A reminder about our upstream backport policy
by Matt Riedemann 20 Sep '19

20 Sep '19

I have noticed several stable/rocky-only docs fixes proposed lately across several projects and when I review them I find that what is being fixed is still broken on master and stable/stein, meaning once someone upgrades from rocky to stein or train they are just going to have to re-fix that same issue. All of the developers are from the same vendor who is targeting a rocky-based release, and while it's great that they put an emphasis on using the upstream docs for product code and work on fixing those docs upstream, we do have backport processes in place for working on stable branches, in this case specifically: https://docs.openstack.org/project-team-guide/stable-branches.html#processes So let's please follow the upstream process so we don't have to continue to fix the same things each release because backports weren't done properly the first time. -- Thanks, Matt

1 0

[sahara] Sahara meeting frequency change
by Jeremy Freudberg 20 Sep '19

20 Sep '19

For any interested parties not already aware, the Sahara meeting now takes place every two weeks instead of every week. The next meeting will take place October 3, 2019. More information and the latest ICS file reflecting this change are found here: http://eavesdrop.openstack.org/#OpenStack_Data_Processing_(Sahara)_Team_Mee… Thanks, Jeremy

1 0

[ops] Shanghai Forum / Ops Day sessions
by Erik McCormick 20 Sep '19

20 Sep '19

Greetings! We are coming up on the Shanghai Summit and need to plan out a few sessions for forum submissions (yeah I know, late as always). We are also trying to see if there's enough traction to do an Ops day on Thursday after the summit. This is a bit freeform, but if there are enough attendees interested, we can make it happen. Please visit the following etherpad and suggest topics for both. +1 those you like the most. We will submit the forum sessions on Friday so there's not a lot of time for that part. Things for the Ops day can go on being entered until that day. https://etherpad.openstack.org/p/PVG-OPS-Forum-Brainstorming Thanks, Erik

1 1

RE: [cinder][FFE] Feature Freeze Exceptions
by Ryan.Liang＠dell.com 20 Sep '19

20 Sep '19

Sorry. Sending to the mailing list. Hi, I’d like to request FFE for the following Cinder Unity driver review: Unity: Add replication support. https://review.opendev.org/#/c/633451/ This change is limited to our Unity driver. Thanks, -Ryan From: Sean McGinnis <sean.mcginnis(a)gmail.com> Sent: Friday, September 20, 2019 9:02 PM To: Liang, Ryan Cc: Jay Bryant; Sun, Hao; Karthik, Rajini Subject: Re: [cinder][FFE] Feature Freeze Exceptions [EXTERNAL EMAIL] Hey Ryan, I think that should be fine, but you need to post this to the mailing list, not directly to Jay. Sean On Fri, Sep 20, 2019 at 1:13 AM <Ryan.Liang(a)dell.com<mailto:Ryan.Liang@dell.com>> wrote: Hi Jay and Sean, I’d like to request FFE for the following Cinder Unity driver review: Unity: Add replication support. https://review.opendev.org/#/c/633451/ This change is limited to our Unity driver. Thanks, -Ryan

1 0

[kolla] Kayobe Train planning meeting
by Mark Goddard 20 Sep '19

20 Sep '19

Hi, Just as the rest of the world is wrapping up the Train release, we find ourselves having just released Stein and starting on Train development. Given the timing of CentOS 8 which we intend to support in the kolla Train release, we have some time to do some feature development in kayobe. I've set up a Doodle poll [1] with two hour slots next week to plan the next release. [1] https://doodle.com/poll/y7fakbhbkfx5hqyk Cheers, Mark

1 2

[openstack-dev][cinder] question on cinder-volume A/A configuration
by Chen CH Ji 20 Sep '19

20 Sep '19

3 2

[oslo] run outlasted interval
by Ignazio Cassano 20 Sep '19

20 Sep '19

Hello, I have an openstack queens installation on centos 7 and starting from last night I got some warnings in several service: nova conductor reports: 2019-09-19 17:37:54.091 161110 WARNING oslo.service.loopingcall [-] Function 'nova.servicegroup.drivers.db.DbDriver._report_state' run outlasted interval by 29.88 sec 2019-09-19 17:37:54.092 161108 WARNING oslo.service.loopingcall [-] Function 'nova.servicegroup.drivers.db.DbDriver._report_state' run outlasted interval by 29.88 sec 2019-09-19 17:37:54.093 161118 WARNING oslo.service.loopingcall [-] Function 'nova.servicegroup.drivers.db.DbDriver._report_state' run outlasted interval by 29.88 sec 2019-09-19 17:37:54.095 161116 WARNING oslo.service.loopingcall [-] Function 'nova.servicegroup.drivers.db.DbDriver._report_state' run outlasted interval by 29.88 sec 2019-09-19 17:37:54.096 161109 WARNING oslo.service.loopingcall [-] Function 'nova.servicegroup.drivers.db.DbDriver._report_state' run outlasted interval by 29.88 sec 2019-09-19 17:37:54.097 161107 WARNING oslo.service.loopingcall [-] Function 'nova.servicegroup.drivers.db.DbDriver._report_state' run outlasted interval by 29.88 sec openvswitch agent reports: 019-09-19 17:16:14.499 26115 WARNING oslo.service.loopingcall [-] Function 'neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent.OVSNeutronAgent._report_state' run outlasted interval by 3.57 sec 2019-09-19 17:23:44.200 26115 WARNING oslo.service.loopingcall [-] Function 'neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent.OVSNeutronAgent._report_state' run outlasted interval by 29.71 sec 2019-09-19 17:37:54.077 26115 WARNING oslo.service.loopingcall [-] Function 'neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent.OVSNeutronAgent._report_state' run outlasted interval by 9.91 sec Please, anyone could help me ? Regards Ignazio

3 5

[tacker] Feature Freeze Exception Request - Add VNF packages support
by Patil, Tushar 20 Sep '19

20 Sep '19

Hi Dharmendra and all Core reviewers In train cycle ,we are committed to implement spec “VNF packages support for VNF onboarding” [1]. All patches [2] are uploaded on the gerrit and code review is in progress but as we have dependency on tosca-parser library, patches are not yet merged. Now, tosca-parser library new version 1.6.0. is released but we are waiting for patch [3] to merge which will update the constraints of tosca-parser to 1.6.0 in requirements project. Once that happens, we will make changes to the tacker patch [4] to update the lower constraints of tosca-parser to 1.6.0 which will run all functional and unit tests added for this feature successfully on the CI job. I would like to request feature freeze exception for “VNF packages support for VNF onboarding” [1]. We will make sure all the review comments on the patches will be fixed promptly so that we can merge them as soon as possible. [1] : https://review.opendev.org/#/c/582930/ [2] : https://review.opendev.org/#/q/topic:bp/tosca-csar-mgmt-driver+(status:open… [3] : https://review.opendev.org/#/c/681819/ [4]: https://review.opendev.org/#/c/675600/ Thanks, tpatil Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.

2 2

[tripleo][ci] gate jobs killed / reset
by Wesley Hayutin 20 Sep '19

20 Sep '19

Greetings, The zuul jobs in the TripleO gate queue were put out of their misery approximately at 20:14 UTC Sept 17 2019. The TripleO jobs were timing out [1] and causing the gate queue to be delayed about 24 hours [2]. We are hoping a revert [3] will restore TripleO jobs back to their usual run times. Please hold off on any rechecks or workflowing patches until [3] is merged and the status on #tripleo is no longer "RED" We appreciate your patience while we work through this issue, the jobs that were in the gate will be restored once we have confirmed and verified the solution. Thank you [1] https://bugs.launchpad.net/tripleo/+bug/1844446 [2] http://dashboard-ci.tripleo.org/d/YRJtmtNWk/cockpit?orgId=1&fullscreen&pane… [3] https://review.opendev.org/#/c/682729/

2 4

[release] Release countdown for week R-3, September 23-27
by Sean McGinnis 20 Sep '19

20 Sep '19

Development Focus ----------------- The Release Candidate (RC) deadline is next Thursday, September 26th. Work should be focused on fixing any release-critical bugs. General Information ------------------- All deliverables released under a cycle-with-rc model should have a first release candidate by the end of the week, from which a stable/train branch will be cut. This branch will track the Train release. Once stable/train has been created, master will will be ready to switch to Ussuri development. While master will no longer be feature-frozen, please prioritize any work necessary for completing Train plans. Release-critical bugfixes will need to be merged in the master branch first, then backported to the stable/train branch before a new release candidate can be proposed. Actions --------- Early in the week, the release team will be proposing RC1 patches for all cycle-with-rc projects, using the latest commit from master. If your team is ready to go for cutting RC1, please let us know by leaving a +1 on these patches. If there are still a few more patches needed before RC1, you can -1 the patch and update it later in the week with the new commit hash you would like to use. Remember, stable/train branches will be created with this, so you will want to make sure you have what you need included to avoid needing to backport changes from master (which will technically then be Ussuri) to this stable branch for any additional RCs before the final release. The release team will also be proposing releases for any deliverable following a cycle-with-intermediary model that has not produced any Train release so far. Upcoming Deadlines & Dates -------------------------- RC1 deadline: September 26 (R-3 week) Final RC deadline: October 10 (R-1 week) Final Train release: October 16 Forum+PTG at Shanghai summit: November 4

1 0

[tripleo] TripleO CI Summary: Sprint 36
by Rafael Folco 20 Sep '19

20 Sep '19

Greetings, The TripleO CI team has just completed Sprint 36 / Unified Sprint 15 (Aug 29 thru Sep 18). The following is a summary of completed work during this sprint cycle: - Addressed issues for scenario{001,002} jobs for RHEL8 in the periodic pipeline. RHEL 8 scen003, scen004 have CIX issues and are being worked on by the ruck/rovers. - Merged multi-arch container tagging support and implemented changes in the promoter code to push manifests with annotated metadata for architecture in addition to the arch tagged containers strategy. - Implemented the provisioning and staging promoter setup to an RDO job for testing changes in the promoter server. Next sprint will close-out the tests for the staging promotion workflow. The planned work for the next sprint [1] are: - Complete the manifest implementation with a test strategy for not breaking promotion workflow. - Design and implement tests for verifying a full promotion workflow running on the staging environment. - Design CI jobs in zuul to build and run tests against ceph-ansible and podman pull requests in github. - Train release branching preparation work. - Prepare CentOS8 node for upcoming distro release support across TripleO CI jobs. The Ruck and Rover for this sprint are Arx Cruz (arxcruz) and Sorin Sbarnea (zbr). 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 are being tracked in etherpad [2]. Thanks, rfolco [1] https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-16 [2] https://etherpad.openstack.org/p/ruckroversprint16

1 0

[all][release] Proposed release schedule for Ussuri
by Sean McGinnis 20 Sep '19

20 Sep '19

Hey everyone, Now that we have a date for the next event [0], it might be a good time to finalize the release cycle schedule for the Ussuri release. I have put up a proposal for the schedule here: https://review.opendev.org/#/c/679822/ Please take a look and give any feedback if you see any issues with where the milestone dates align with any major holidays or other external factors that we should consider. For your viewing convenience, here is the rendered output from the docs job: https://openstack.fortnebula.com:13808/v1/AUTH_e8fd161dc34c421a979a9e6421f8… Thanks! Sean [0] http://lists.openstack.org/pipermail/foundation/2019-September/002794.html

1 0

[Security] Security SIG Newsletter
by Gage Hugo 20 Sep '19

20 Sep '19

Past couple weeks were a bit slow, but this week has some updates! #Date: 19 Sept 2019 - Security SIG Meeting Info: http://eavesdrop.openstack.org/#Security_SIG_meeting - Weekly on Thursday at 1500 UTC in #openstack-meeting - Agenda: https://etherpad.openstack.org/p/security-agenda - https://security.openstack.org/ - https://wiki.openstack.org/wiki/Security-SIG #Meeting Notes - Summary: http://eavesdrop.openstack.org/meetings/security/2019/security.2019-09-19-1… - Discussed the recently public big here: https://bugs.launchpad.net/horizon/+bug/1842930 - Current path forward is to clear up documentation to warn about this and provide info about caching settings. - nickthetait is currently working on https://bugs.launchpad.net/ossp-security-documentation/+bug/1703353 - Will create a page describing the usage and functionality of the audit middleware & CADF notifications #VMT Reports - A full list of publicly marked security issues can be found here: https://bugs.launchpad.net/ossa/ - Deleted user still can delete volumes in Horizon: https://bugs.launchpad.net/horizon/+bug/1842930

1 0