- Zuul-discuss - lists.opendev.org

retire x/pbrx
by Andreas Jaeger 11 May '20

11 May '20

I'll start the retiring process for the repo x/pbrx, it was created as tools for pbrx but is not used anymore, Andreas -- Andreas Jaeger aj(a)suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg (HRB 36809, AG Nürnberg) GF: Felix Imendörffer GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB

2 2

Feedback on StarlingX pilot project
by Ildiko Vancsa 07 May '20

07 May '20

Hi Zuul Community, I’m reaching out to you about the StarlingX project as they will start their confirmation process with the OSF staff and Board of Directors next week with a few pre-review and early feedback calls to prepare for their confirmation review on the next Board meeting in early June. A draft of the slide deck[1] they plan to present is available for reference. Per the confirmation guidelines[2], the OSF Board of directors will take into account the feedback from representative bodies of existing confirmed Open Infrastructure Projects (Airship, Kata, OpenStack and Zuul) when evaluating StarlingX for confirmation. You may recall this process from when the Zuul Community went through it last year. Particularly worth calling out, guideline #4 "Open collaboration” asserts the following: Project behaves as a good neighbor to other confirmed and pilot projects. If you have any observations/interactions with the StarlingX project which could serve as useful examples for how this project does or does not meet this and other guidelines, please provide them on the etherpad[3] ASAP. If possible, include a citation with links to substantiate your feedback. I'll assemble this feedback and send it to the Board (via the public foundation mailing list) for consideration before their meeting next week. If you could give your feedback till the end of this week that would be highly appreciated. Thanks and Best Regards, Ildikó Váncsa [1] https://drive.google.com/file/d/16FPqzLT_3UH5AbZQJGg5Y9g4CN6AsRmx/view?usp=… [2] https://wiki.openstack.org/wiki/Governance/Foundation/OSFProjectConfirmatio… [3] https://etherpad.opendev.org/p/zuul-community-starlingx-confirmation-feedba…

1 1

Fwd: [openstack-community] OpenDev Events Update - we need your feedback!
by Jimmy McArthur 05 May '20

05 May '20

Check it! -------- Forwarded Message -------- Subject: [openstack-community] OpenDev Events Update - we need your feedback! Date: Tue, 5 May 2020 12:35:07 -0500 From: Ashlee Ferguson <ashlee(a)openstack.org> To: community(a)lists.openstack.org, foundation(a)lists.openstack.org Hi everyone, Thanks so much for your feedback that’s continually helping us shape these virtual OpenDev events[1]. Keep reading this email for some important updates on all three events! 1. OpenDev: Large-scale Usage of Open Infrastructure SoftwareJune 29 - * July 1 (1300 - 1600 UTC each day) * Registration is open[2]! * High-level schedule coming soon; Find a brief topic summary and more information here[1] 2. OpenDev: Hardware Automation * July 20 - 22 * Help us pick a time - visit this etherpad[3] and +1 the times you’re available and the topics you would like to cover - please provide your input by this Thursday, March 7. 3. OpenDev: Containers in Production * August 10 - 12 * Help us pick a time - visit this etherpad[4] and +1 the times you’re available and the topics you would like to cover - please provide your input by this Thursday, March 7. Find more information and updates on all of these events here[1]. [1] https://www.openstack.org/events/opendev-2020 [2] https://opendev_largescale.eventbrite.com [3] https://etherpad.opendev.org/p/OpenDev_HardwareAutomation [4] https://etherpad.opendev.org/p/OpenDev_ContainersInProduction Thanks! Ashlee Ashlee Ferguson Community & Events Coordinator OpenStack Foundation

1 0

Consider dropping support for python 3.5 in v4
by Monty Taylor 05 May '20

05 May '20

Hey all, I’d like to propose that we drop support for python 3.5 as part of Zuul v4. With the Python 2.7 EOL, more people are dropping support for 3.5 as well, since one of the main benefits of python3.5 was that it was easier to write code compatible between 2.7 and 3.5. OpenStack in particular, as part of its EOL of python 2.7 support chose python 3.6 as the new minimum. We use OpenStackSDK and keystoneauth from OpenStack in Nodepool - so I’ve made sure OpenStackSDK and keystoneauth retain 3.5 support … but I get the impression it’s only going to be a matter of time before more and more of our dependencies start dropping 3.5 support. Since we have a v4 coming up, I was thinking it would be a good time to raise our minimum as well. Our docker images are currently being built with python 3.8. Ubuntu Bionic (old-its) has python 3.6 and python 3.7 Ubuntu Focal (new-its) has python 3.8 Centos 8 has 3.6 Debian Buster has 3.7 The argument for keeping 3.6 support would be to keep support for CentOS without needing additional repos - but since zookeeper isn’t in CentOS people have to add repos anyway. I believe our Software Factory friends are running on CentOS and are running either 3.7 or 3.8 already? BUT - BMW are running in containers and are running on 3.6 - so while I *would* suggest dropping 3.6 too and just jumping straight to 3.7 as a minimum, I think until BMW are not on 3.6 we should consider that a non-starter. As another impact, we currently have to consider the old version of git that’s in Xenial when doing things, and if we drop 3.5 we will be effectively dropping Xenial which means our min git version we have to consider would also be more recent. We could also wait for v5 - which would be closer to the Xenial’s April 2021 End of Standard Support time. And maybe by then we could also drop 3.6? Or maybe we drop 3.5 for v4 and drop 3.6 for v5 - but we still people about both now so that they can work on getting ready for it? What do people think? Monty

3 3

Fwd: [all][PTL][TC] PTG Signup Last Call
by Kendall Nelson 05 May '20

05 May '20

Hello! In an effort to get a schedule set and posted on the website and so that you can all block your calendars for the event, we ask that *teams finish signing up for time by Sunday, May 10th at 7:00 UTC*. We have done some consolidation to save room resources (as we will have to set up/pay for rooms ahead of time) so if you are in the list below, please note that your room may have changed, but the timing should be the same. Also note, some teams may be set to switch rooms throughout the week. Currently Signed Up Teams: Airship Automation SIG Cinder Edge Computing Group First Contact SIG Interop WG Ironic Glance Heat Horizon Kata Containers Kolla Manila Monasca Multi-Arch SIG Neutron Nova Octavia OpenDev OpenStackAnsible OpenStackAnsibleModules OpenStack-Helm Oslo QA Scientific SIG Security SIG Tacker TripleO Thanks! -The Kendalls(diablo_rojo & wendallkaters)

1 0

Fwd: [all] Virtual PTG Tooling Requirements & Suggestions
by Kendall Nelson 27 Apr '20

27 Apr '20

Hello Everyone :) We want to get your input on tooling for the PTG. We have a general idea of what we have for requirements, but wanted to get the community's input- i.e. make sure we aren't missing any. Here is the list of requirements we have right now[1]. Also, if anyone has suggestions of tools that meet these criteria, we would love to hear them! We are gathering and vetting options for the event and want to make sure nothing gets overlooked. -the Kendalls (diablo_rojo & wendallkaters) [1] https://etherpad.opendev.org/p/virt-ptg-requirements

1 0

Fwd: [all] [PTL][TC] PTG Signup Reminder & PTG Registration
by Kendall Nelson 22 Apr '20

22 Apr '20

Hello! ==Virtual PTG Signup== Wanted to take a second to remind teams about the process for signing up for virtual PTG slots. 0. Look at the slots available and talk to your contributors and team members to find out the best times to signup for. 1. Sign up in the ethercalc [1] for the time slots your team needs. You can sign up for up to 4 hours/day and 16 hours/ the week (restrictions in place until *April 28th at 7:00 UTC*). If you are a SIG or WG, try to keep your conversations at the start of the week wherever possible. Vertical teams, try to focus your conversations towards the latter part of the week (Wednesday-Friday). *AND* 2. Fill out the survey [2] to give us the other team information we need to help facilitate the event. We NEED you to do both steps! I can see a number of teams that have signed up for time, but haven't filled out the survey so please do so ASAP. There are still a lot of slots left! Original thread[3]. ==Registration== After a lot of discussion, we have decided to have registration. It is free but its still extremely important that you register as this is primarily so we have a way to contact attendees with information about the event as we figure the rest of the details out. We will have the registration live next week. -the Kendalls (diablo_rojo & wendallkaters) [1] Ethercalc:https://ethercalc.openstack.org/126u8ek25noy [2] Survey: https://openstackfoundation.formstack.com/forms/june2020_virtual_ptg_survey [3] PTG Layout & Signup Thread: http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014126.ht…

1 0

Virtual PTG Layout & Signup
by Kendall Nelson 14 Apr '20

14 Apr '20

Greetings! I am sure you have all been anxiously awaiting more details on how we are going to virtualize the PTG :) After the community meetings we had last week/the week before to understand the key challenges and ideate on solutions, we have a plan! The virtual event will be held from Monday June 1 to Friday June 5. We set up available times in 3 different time windows where each window is a cross over time between at least 2 regions (Window A - Americas/Europe, Window B - Europe/APAC, and Window C - APAC/Americas). Here is an ethercalc[1]. We ask that the PTL/SIG Chair/Team lead sign up for time to have their discussions in with 4 rules/guidelines. 1. Cross project discussions (i.e. SIGs and horizonal teams), try to schedule yourselves towards the start of the week so that any discussions that might shape those of vertical teams might happen first. 2. Vertical teams (ex. Nova, Cyborg, Manila) should wait till April 6th at 7:00 UTC to start signing up for slots to help prioritize the scheduling of cross project conversations. 3. No team (SIG, horizonal project, vertical project, etc) can sign up for more than 4 hours per UTC day to help keep participants actively engaged. 4. No team (SIG, horizonal project, vertical project, etc) can sign up for more than 16 hours across all time slots to avoid burning out our contributors and to enable participation in multiple teams discussions. Once every team has had a chance to sign up (lets say two weeks from today April 28th at 7:00 UTC) if signing up for more time makes sense, it will be possible. We want to encourage ANY team to sign up, even those that had originally said no to the initial outreach when the PTG was supposed to be in person. The more the merrier! Once you have signed up for time slots, please also fill out this survey[2] with your team information. We need this additional information to help shape other decisions down the road and coordinate other details closer to the event. If you have any issues with signing up your team, due to conflict or otherwise, please let me know! While we are trying to empower you to make your own decisions as to when you meet and for how long (after all, you know your needs and teams timezones better than we do), we are here to help! Continue to check back for updates at openstack.org/ptg. -the Kendalls (diablo_rojo & wendallkaters) [1] https://ethercalc.openstack.org/126u8ek25noy [2] https://openstackfoundation.formstack.com/forms/june2020_virtual_ptg_survey

1 0

Code coverage testing
by Jan Kundrát 14 Apr '20

14 Apr '20

Hi, I'm looking at possible ways of showing how a change in Gerrit affects code coverage. In the end, I would like to show this info for two kinds of projects: - a Python project that is already using the stock tox-py* jobs, - our custom C++ jobs which just call a simple playbok that includes a role which uses Ansible's `command` for execution [1] (and we're only using the existing jobs for basic preparation and log upload). Note that "difference of coverage" is something else than "coverage of the actual diff". Coverage of the diff can be generated by e.g. diff_cover [2]. It shows which lines of the change (patch) were executed. This won't catch this example where all diff lines are covered, but suddenly there's nothing left to execute other_func(): def my_func(): return 666 def other_func(x): return 123 def test_foo(): assert(my_func() == 666) - assert(other_func() == 123) It looks to me that pycobertura [3] can catch this by comparing "previous" and "current" coverage. The catch is that this comparison requires building and running the test suite twice -- once in the usual manner, and then once more for the "previous version". How to determine the previous version? It might not be HEAD~1 because of Zuul's merges into the target branch. Is there a Zuul ref that I can rely on from a context of a job? I think I can use something like HEAD^1 + plus a merge of that into the target branch, but it would be awesome if I could get it from Zuul and not have to duplicate its merge settings in my job. Here's how a simple ad-hoc job which handles my use case for our "custom C++ jobs" might look like: # original content goes here ... git-new-workdir ... pushd workdir-of-previous-version git reset --hard HEAD^1 git merge {{ zuul.branch }} make all make test popd pycobertura diff \ coverage.xml workdir-of-previous-version/coverage.xml \ --source1 . --source2 workdir-of-previous-version However, this is something that is totally non-reusable. Given that I'm already using standard tox-* jobs for our Python jobs, I would prefer to create a reusable job for coverage changes. Ideally, this job would run after my "main" build job, so I think I'm looking for a child job [4]. This job can look at two different artifacts, "previous-coverage" and "current-coverage", run a comparison, generate a nice HTML report, and (possibly) fail if a certain threshold is not met. However, I am not sure if current Zuul artifacts really fully get me there. If this is a "first change in the check pipeline with no parents", i.e., head of the queue, there's no previous change to fetch the results from, so I have to consult some external artifact provider for "latest thing that got merged" version of "coverage". This brings some requirements: - Use of the "gate" pipeline. When there's no "gate", just "check", there's no guarantee that the current state of my destination branch was built as-is. (Possible workaround: a fast-forward-only merge policy in Gerrit and a "promote" pipeline which picks the latest jobs results from "check", see [5] and [6] for how it might look in a slightly different use case...) - A custom artifact registry, or a well-known naming scheme for artifact naming, or Zuul keeping artifact locations persistent when a change merges. Since I don't want to maintain ad-hoc code, I don't want to run my custom image registry per site. Let the gate job upload artifacts with storage URLs such as: /t/{{ zuul.tenant }}/artifacts/{{ zuul.project }}/{{ zuul.newrev }} Suppose my "check" job has no preceding items (no Depends-On, and it's based on something that has been already merged into the target branch). The job.artifacts[] variable is therefore empty, so I have to infer my artifact location. The easieast way is just looking at the current SHA1 of the destination branch, and wget that. Alternative: let Zuul pass artifact location from the "promote" pipeline to "gate" jobs, somehow. That's not all. There are two proposed changes, #2 depends on #1. The child job of #2 depends on the build job of #2, and is correctly executed only after #2's build job succeeds. However, #2's child job also has to wait for artifacts from #1's build job. Can I hold a child job of the second change until not only its parent job completes, but also for the duration of the parent job of the preceding change in the queue? With kind regards, Jan [1] https://gerrit.cesnet.cz/plugins/gitiles/ci/zuul-jobs-cesnet/+/refs/heads/m… [2] https://github.com/Bachmann1234/diff_cover [3] https://pypi.org/project/pycobertura/#command-diff [4] https://zuul-ci.org/docs/zuul/reference/jobs.html#var-zuul.child_jobs [5] https://gerrit.cesnet.cz/plugins/gitiles/ci/zuul-jobs-cesnet/+/refs/heads/m… [6] https://gerrit.cesnet.cz/plugins/gitiles/CzechLight/netconf-cli/+/refs/head…

4 7

Etherpad and Gerrit maintenance on 2020-04-10
by corvus＠inaugust.com 10 Apr '20

10 Apr '20

Hi, Tomorrow, April 10, 2020, the OpenDev team will be performing minor updates to two services. * Gerrit restart for https://review.opendev.org/ at 16:00 UTC. This should be a momentary outage to restart the service in a container. We will maintain the same version in the same configuration; this is a preparatory step in order to perform future version upgrades more easily. Other than a short outage of about a minute, there should be no service impact or visible changes, but since the environment is changing, we wanted to announce this in case any problems are detected. * Etherpad migration and domain change at 17:00 UTC. We will migrate the data currently hosted on etherpad.openstack.org to a new server, also running in a container, on etherpad.opendev.org. We will set up redirects so that on completion of the migration, all etherpad.openstack.org URLs will redirect to the same pages on etherpad.opendev.org. https://etherpad.opendev.org/ will become the new canonical service URL. This also includes an upgrade to the latest release of Etherpad Lite (1.8.0). This involves a database migration as well. The service will be unavailable for the duration of this migration (expected to be about 30 minutes). Please report any issues in #opendev on Freenode or to the service-discuss(a)lists.opendev.org mailing list. Note that this message is being sent to service-announce and several other lists. Future announcements of this type will only be sent to service-announce, so please sign up[1] for that list if you haven't already. [1] http://lists.opendev.org/cgi-bin/mailman/listinfo/service-announce -Jim

1 0