@Samhita Alla following on that topic, we've been going back and forth on how to organize our Flyte code. How to think of projects is at the center of it. We can see things easily ending up hard to manage if we go down the wrong path. I think an example the easiest way to communicate different choices. Say we organize our local code ("workflow sets") by server-side project. That might look like this.

flyte-{server-side-project-name}/
  README.md
  domains/                <-- code/tools for per-namespace resources.
    development/
       sync-resources.sh
       do-some-admin-thing.sh
       rsrcs/
          default-pod-template.yaml
          something-else.yaml
    staging/
    production/
  workflowsets/          <-- projects created with pyflyte init
    register-all.sh
    app-x-workflows/
    model-y-workflows/

Here, the per-project+domain resources are managed in code alongside the workflows. And, we assume two things: it makes sense for workflow sets to be bound to a single project and a project should expect multiple workflow sets. This also promotes a master-branch-only development style for workflows due to layout. Another approach is to lay code out like like above, but without the

workflowsets

directory. Instead, each workflow set gets it's own repository (maybe a naming convention would be

flyte-ws-{purpose}

). The assumption being made in this case is that workflows are not bound to a project (just like software projects are not bound to a deployment). Here, the workflow sets get branches and typical development flows. The second approach feels similar to what is implied in the flytesnacks example directory, but that's a special case and may not be a good reference for this. The last option we've considered is to assume a server-side project should have a single workflow set. In this case, the project structure would look like this.

flyte-{server-side-project-name}/
  README.md
  Dockerfile
  domains/
    development/
       sync-all.sh
    staging/
    production/
  workflows/
     some-workflow.py

This promotes the creation of more server-side projects and moves back to the master-only branching approach.

All that back story leads to a short question: What is the intended path for mapping local code projects (containing workflow sets) to flyte server-side projects? Is there some documentation about best practices (or at least the intentions) there?

are you guys on a mono repo? typically people use different flyte projects for different teams.

some users use the cluster resource controller to create k8s resources on the cluster.

the “code/tools for per-namespace resources” what are those? could you give us more examples of what these are?

the cluster resource controller is good at creating and updating k8s resources by project/domain, but I don’t think it has the capability to not run something for certain combinations of project/domain.

with respect to the initial question btw, I think lots of people do do one repo = one flyte project.

sorry was slammed today.

maybe samhita can give you the details?

if not i’ll respond tomorrow, so sorry

Trying to sum up this thread (so it doesn't end up too off-topic): 1. The general convention is a single client-side project (created with

pyflyte

) per server-side project. That means it's probably going to be the use case considered as the project evolves. 2. Managing boilerplate resources in each project+domain namespace is best to do with the

clusterresource-template

feature (this guy). That's very helpful! The only left over thing is the language to disambiguate between the two things both called a "flyte project".