I think this could greatly benefit from the decision making process + tech discussion (still on the works): https://docs.google.com/document/d/1x8OQdYud1ruhRLw8tiKuE9gozycfHO7lkMp81WYC...
Even if it's just for it's more asynchronous nature.
On 03/01 12:15, Arturo Borrero Gonzalez wrote:
Hi there!
(explicit CC to Komla in case he is not included in the other aliases)
I would like to propose we restart this conversation. I'm writing a blog post about Toolforge's future. Just remembered that we left some unfinished conversations here.
See comments inline for the 3 main topics we discussed last time.
On 12/14/21 18:18, Andrew Bogott wrote:
This meeting coalesced around a few major topics:
- Why not just bring-your-own-container?
** We turn out to have fairly different ideas about what user experiences we want to support.
** General agreement that we could use more research and/or documentation about current and future workflows (although some of that already exists at https://www.mediawiki.org/wiki/Wikimedia_Cloud_Services_team/Our_audiences
** This question hinges on how sophisticated our users are or aren't.
** Komla suggests that many public cloud platforms provide simple deployment that don't require users to understand about container or k8s details; there's general agreement that we would also like to be like that
** Andrew thinks that push-to-deploy should be our 'main priority' and byo doesn't really address that.
I still have some doubts about this point. I have the feeling we're missing an opportunity here.
- How/When will we kill off the grid engine?
** We tend to think of this as blocked by push-to-deploy, but perhaps we should be open to other non-blocking options (e.g. the 'one big container' migration path)
This could greatly benefit from the previous point.
- What to do about the Stretch->Buster migration?
** Nicholas isn't convinced that we should migrate to Buster if we're just going to kill the grid eventually anyway. Andrew and Arturo mostly disagree.
** Probably the migration to Buster isn't a lot of hard mental work, just building things and throwing pre-existing switches.
** Main blocker for this is allocating time and tasking someone with doing the work
Congratulations, this point is now solved!
-- Arturo Borrero Gonzalez Site Reliability Engineer Wikimedia Cloud Services Wikimedia Foundation