April 2019 - openstack-discuss - lists.openstack.org

[goals][upgrade-checkers] Retrospective
by Matt Riedemann 27 Apr '19

27 Apr '19

Now that Stein is GA I figured I'd write up a quick retrospective for the upgrade-checkers goal [1]. Statistics ---------- From the tasks in the story [2]: - There were 52 total tasks. - Merged: 40 - Review: 4 (still open) - Invalid: 8* (not applicable or opted out) Excluding Invalid tasks, the overall completion percentage of the goal was 91% which is pretty good. Granted, the majority of projects just added the placeholder framework for the upgrade check command which is not very useful for operators, but it's a start for those projects to build in real checks later. *5 of the Invalid tasks were for deployment projects which were not a target for the goal [3]. The others were for swift, telemetry and panko. oslo library ------------ To ease development, Ben Nemec extracted the framework of the nova check code into the oslo.upgradecheck library [4]. This made getting the framework in place for all projects much easier and ensures a high level of consistency in the command structure which is really important with this type of thing. Thanks again Ben! Not universal ------------- As mentioned above, not all projects implemented the command since it maybe didn't make sense for those projects (swift, mistral and adjutant are good examples) and other projects just aren't in a place development-wise to put much priority in the goal (telemetry and panko). Extension points ---------------- Neutron created an extension point for their upgrade checks to support stadium projects and have already been using it. This was not something I thought about when we started the goal so it was cool that the neutron team embraced this and put their own spin on it. Contributions from NEC developers --------------------------------- Akhil Jain and Rajat Dhasmana from NEC volunteered to add the framework of the command in most projects which was extremely helpful. Thank you Akhil and Rajat, and NEC for providing development resources to work on a cross-community goal like this. Next ---- While most projects have the framework in place for upgrade checks, a lot of projects released Stein with a simple placeholder check. A few projects have started adding real checks to aid in upgrades to Stein, which is great. I'm hopeful that other projects will add real checks as they encounter upgrade issues during Train development and need a way to signal those changes to operators in an automated way. Remember: if you're adding an upgrades release note, consider if you can automate that note. Another next step is to get deployment projects to build in a call to each project's upgrade check command because without deployment projects using the tool it doesn't serve much purpose. Let me note that this does not need to be driven by the deployment projects either - developers from each project can integrate their check into a deployment project of choice, like I did for OpenStack-Ansible [5]. I'm sure the deployment project dev teams would appreciate the service project teams driving this work. [1] https://governance.openstack.org/tc/goals/stein/upgrade-checkers.html [2] https://storyboard.openstack.org/#!/story/2003657 [3] See the note: https://governance.openstack.org/tc/goals/stein/upgrade-checkers.html#compl… [4] https://docs.openstack.org/oslo.upgradecheck/latest/ [5] https://review.openstack.org/#/c/575125/ -- Thanks, Matt

6 8

[PTG][Docs][I18n] Planning and time schedule
by Frank Kloeker 26 Apr '19

26 Apr '19

Dear fellow stackers, PTG for Train will held next week in Denver. I'm alredy here and I wouldn't say, I miss the train from Stapleton Station with all the noice. But I wouldn't miss the Train PTG in this lovely town in the U.S. It reminds me that diversity is still the greatest strength of our community. Well, for the different reasons I do not expect many team members to attend onsite, but some should be still there. The scheduled Docs/I18n day is regarding timetable [1] Thursday, May 02 2019. Weather forecast says sunny with 16 degrees - so no snow do expect. I've created an Etherpd and linked it on the main list [2]. Please feel free to add your name there and propose your topic. I spotted two things so far: - Documentation PDF support which is an official main goal for train - Migrate I18n translation platform back from Zanata There is no full planned timetable yet. Maybe we have during the day an onsite discussion and want to sync with remote guys at 16:00? EU is 8 hours ahead and Korea/Japan 15 hours [3]. Let me know your thoughts and ideas or write it to the Etherpad. many thanks Frank (previous PTL I18n) [1] https://www.openstack.org/ptg/#tab_schedule [2] https://wiki.openstack.org/wiki/PTG/Train/Etherpads [3] https://www.timezones.de/time_conference_planner_timeszone/v2/1850147%2C295…

1 0

[tc][all] Github mirroring (or lack thereof) for unofficial projects
by Jim Rollenhagen 26 Apr '19

26 Apr '19

Hi, Now that the great OpenDev migration is done, we have a number of projects on Github which are no longer mirroring and becoming stale. This includes: - most repositories at https://github.com/openstack-infra - any repository in https://github.com/openstack which is no longer in https://opendev.org/openstack - I think that's it, but there could be others. The OpenDev and OpenStack teams have no plans to continue mirroring these projects to Github; primarily because we don't have a corresponding Github organization to put them in. However, teams can easily set up a mirror to any location they like on Github: http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005007.ht… The remaining question is what to do with the stale repos in the OpenStack organization on Github. Right now, we plan to just archive them. This means that the repository will be read-only, with a banner at the top saying it's archived. If a project owner wants to transfer the project to another Github organization, we can unarchive the project to do so, and they can maintain the mirroring via Zuul. If there's no wild objections to this plan, we'll go ahead with it soon. Maybe the week after the Summit, unless someone in the OpenDev team has spare cycles before that. // jim

5 4

Re: [placement][nova][ptg] Protecting driver-provided traits
by Chris Dent 26 Apr '19

26 Apr '19

On Thu, 11 Apr 2019, Adam Spiers wrote: > Ed Leafe <ed(a)leafe.com> wrote: >> The concept of “owning” particular traits isn’t in Placement. Rather, it is >> in the domain of the service that is using Placement. So any enforcement >> regarding which traits are acceptable has to be on the calling end, not in >> the Placement API. > > That feels like a slight jump in logic to me: the API can enforce ownership > without being the authoritative source of truth for that ownership. For > example, as I just suggested elsewhere in this thread, (static) ownership of > driver-provided traits could be tracked in os_traits. Maybe that's a dumb > idea; I'm not sure. It's not a dumb idea, but it's not really an idea we want to pursue. We've made an effort to keep both os-traits and os-resource-classes as dumb and "symbol only" as possible, minimizing code and metadata. Indicating ownership would require metadata. Enforcing it would require some form of code. > Having said that ... >> So yeah, “do nothing”. > > I'm totally fine with this too ;-) I only raised it because when I was > developing the driver-owned capability traits code, people seemed somewhat > concerned with the possibility of admins screwing things up. If the concern > is minimal then I'm certainly not religious about adding extra safeguards. Seeing as there's no huge drive for action on this topic, I've marked this topic as decided ("do nothing") on the etherpad [1] and we can ignore this thread henceforth. If people have additional ideas and thoughts please feel free to keep it alive. [1] https://etherpad.openstack.org/p/placement-ptg-train -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

4 7

[nova][dev] Pike Extended Maintenance coming soon
by melanie witt 26 Apr '19

26 Apr '19

Hi all, As mentioned in the nova meeting today, Pike Extended Maintenance is coming soon. The date shown on the release page says 2019-03-03 but it's predicted to occur after the Stein release (2019-04-10): http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003745.ht… We are currently in the process of flushing the stable/pike review queue for a final release of stable/pike: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:… Please be sure you get your backports proposed that you'd like to land in the final Pike release. After Pike is put into extended maintenance, there will be no more releases, but patches will still be accepted to the branch: https://docs.openstack.org/project-team-guide/stable-branches.html#maintena… Cheers, -melanie

2 3

[tripleo] TripleO CI Summary: Sprint 29
by Rafael Folco 26 Apr '19

26 Apr '19

Greetings, The TripleO CI team has just completed Sprint 29 / Unified Sprint 8 (Apr 04 thru Apr 24). The following is a summary of completed work during this sprint cycle: - Bootstrapped RDO and OSP jobs in the internal Software Factory instance. - Monitored stable/stein jobs for TripleO projects and added missing branchful job for stein. - Switched to buildah on containers build jobs upstream in check pipeline. - Improved docs and code comments in emit_releases file for upgrade jobs. - Moved the periodic standalone, standalone scenario 1-4 jobs to os-tempest - Promotion status: green on all branches The planned work for the next sprint [1] are: - Continue testing and defining jobs in the internal instance of Software Factory to run RDO and OSP on RHEL as an attempt to approximate upstream and downstream config/tooling used in the promotion pipeline. - Create a separate repository for collect-logs role and move code for being reused from other projects. - Schedule a test day for the zuul reproducer to fix deployment issues, usability and upgrade use cases. - Onboarded performance baremetal hardware to the internal Software Factory in order to run jobs of the promotion pipeline. - Noting lower capacity due to Summit / PTG The Ruck and Rover for this sprint are Rafael Folco (rfolco) 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-9 [2] https://etherpad.openstack.org/p/ruckroversprint9

1 0

[qa] Canceling QA office hour for next 3 weeks
by Ghanshyam Mann 26 Apr '19

26 Apr '19

Hello Everyone, Most of us will be in Summit and PTG next week and I will be on leave after PTG for 2 weeks to visit India. Due to that, I am cancelling the QA office hour for the next 3 weeks. -gmann

1 0

[placement][ptg] Enabling other projects to continue with placement or get started
by Chris Dent 26 Apr '19

26 Apr '19

>From the etherpad [1] * blazar * cinder * cyborg * ironic * neutron Who else? This is a bit of a catch-many topic. Despite being birthed in Nova, Placement is designed to be useful to lots of different services. There's already some time defined at the PTG to talk about the interaction of Ironic, Blazar, and Placement. What are the issues with that? What are the issues other services are experiencing with Placement? Preventing people from using Placement? What services are using Placement and the team doesn't know about it? [1] https://etherpad.openstack.org/p/placement-ptg-train -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

9 19

[horizon] No meetings next two weeks
by Ivan Kolodyazhny 26 Apr '19

26 Apr '19

Hi all, During the last IRC meeting [1] we agreed to skip the next two meetings. I hope to see you in Denver next week. [1] http://eavesdrop.openstack.org/meetings/horizon/2019/horizon.2019-04-24-15.… Regards, Ivan Kolodyazhny, http://blog.e0ne.info/

1 0

[octavia] Octavia 4.x for Rocky?
by Volodymyr Litovka 26 Apr '19

26 Apr '19

Dear colleagues, whether Octavia 4.x can be used with Rocky? Whether it makes sense (I mean, whether Octavia's new features are tied to Stein's features)? Thank you. -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

2 1