Jump to content

Wikimedia Release Engineering Team/Checkin archive/2023-01-25

From mediawiki.org


2023-01-25[edit]

πŸ“… Vacations/Important dates[edit]

https://office.wikimedia.org/wiki/HR_Corner/Holiday_List#2023
https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar
https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/Time_off

January 2023[edit]

  • 2 Mon Jan: New Year's day observed
  • 16 Mon Jan: Martin Luther King Jr Day
  • 1-15 Jan: Jaime
  • 20 Fri Jan: Dan πŸŽ‚
  • 20 Fri Jan: Brennen Β½ day

February 2023[edit]

  • 20 Mon Feb: U.S. Presidents' Day

March 2023[edit]

πŸ”₯πŸš‚ Train[edit]

https://tools.wmflabs.org/versions/
https://train-blockers.toolforge.org/
https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar


  • 2 Jan - wmf.17 - Dan + Antoine (Jaime out)
  • 9 Jan - wmf.18 - Jeena + Dan (Jaime out)
  • 16 Jan - wmf.19 - Jaime + Jeena
  • 23 Jan - wmf.20 - Brennen + Jaime
  • 30 Jan - wmf.21 - Ahmon + Brennen
  • 6 Feb - wmf.22 - Chad + Ahmon
  • 13 Feb - wmf.23 - Antoine + Chad (todo move antoine to week after)

Team discussions[edit]

Quickies[edit]

  • Chad demo of harbor
    • Harbor evaluated 5 years ago
    • GC with younggen
    • Helm chart repo
    • OIDC
    • Preseeding with dragonfly
    • Stable + mature
    • Terraform provider as well
    • Webhooks for events
    • Prometheus endpoint
    • Running on test k8s in DO
    • Questions:
      • Configurable outside GUI? Yep, full API, programatic managment

Backport forbidden patch types[edit]

GitLab Migrations[edit]

Discussion[edit]

  • We have to do itΒ :)
  • In between time: useful to have master branch in gerrit, have two branches in gitlab, then change default upstream
  • Moving over to main a pre-req for gitlab?
  • Zuul will only work with master in gerrit
  • Leave master branch for a while? Create new refs/heads/main?
  • TODO: create a "main" on repos/releng/release, leave master for now, deal with fallout later -- thcipriani

Shared runners[edit]

  • One of our goals: Launch instance-wide runners
  • Same sprint as scaling buildkitd
  • Interest in IRC/Slack in using Kokkuri, blocked on runner availability
  • Talked to a few of you in 1-on-1s about ideas for this, better to talk together

Discussion[edit]

  • FInish out the sprint, it's the last thing, then we'll be done
  • Value in getting kokkuri usage
  • Let's let people use WMCS with the knowlege that they'll run into space issue?
  • Better to let people have early access knowing their jobs will be slower?
  • We can continue to promise things will get better'
    • Plus things get better magically
  • Approach: have instance-wide runners pick them up (which would be WMCS), then after sprint have scalable buildkitd, then what do with WMCS runners?
    • Leave around for special cases or retire?
    • Alternative: up replicaset and make DO available now and continue working on autoscaling seperately?
  • Proposal: Enable WMCS runners site-wide, continue hacking on buildkitd hacking, reassess
  • TODO: dancy to make wmcs instance-wide/work with brennen
    • May be a matter of changing the registration token for the runners