Hey all, we're moving forward with our migration to flyte and are making sure that various end-user workflows are at parity w/ our current Kubeflow deployment. A couple of topics that have come up include the best ways to support multi-tenancy/projects for experimentation. 1. We currently group runs submitted by various users as "experiments" in Kubeflow. I notice in Flyte there is an option in the UI to filter down to only workflows submitted by the currently-authenticated user, but more broadly what's the best way to group different sets of experiments that multiple users are running 2. Does having a project per user make sense (ie. for a user's dev workspace)? I noticed in the docs that a common pattern is having one project per repo, but in our current setup we run everything out of one monorepo.

So projects are very light weight, though I do not think project per user make sense. At a point at lyft we had 400 projects, and I think Spotify has around that number

@elegant-australia-91422 = Yes, we infamously use

monorepo

and each sub-folder (each of our autonomy teams) are grouped into a flyte project with their iam/s3/ml permissions.. . Let me know how I can help 🙏

@sticky-art-97180 that makes sense for sub-folders in the monorepo to correspond to projects; with a little refactoring I think we could achieve this. For projects where multiple users are running experiments w/ many executions, how do the navigate the UI/find executions, etc? There didn't immediately seem to be a way to tag executions so that they'd be discoverable in the UI

You can name them, but yes there is no tagging today. I think that is a fair feature request

@elegant-australia-91422 - So in our mono-repo : has bazel integration .. So when users want to register/build a wf, they run a

bazel

command - while doing that, we generate an

exec id

and share the link to users. Something like this:

Got it, we're using

bazel

as well so that approach makes a lot of sense. Do you have users commit the workflows before running typically, & if so do you segment the monorepo between research workflows vs core development?

have users commit the workflows before running typically,

Yes, we made it a pre-req in bazel builds.. If someone wants to “push” their wf code to artifactory, they have to commit it.