Hi team. On Dagit UI, can we show the jobs based on the workspace or deployment only? We have deployed Dagit and tied it out to our multitenancy application. Now each tenant has its own deployment/workspace. We would like to have dagit UI show the jobs for different tenants, and each tenant shouldn't see the jobs from others. We did a PoC spinning up two Dagits - one is pointing to tenantA's workspace and the other to tenantB's workspace. We are able to see their own deployment under their Dagit UI, but for jobs, we can still see all the jobs across all the tenants on the UI.

Hi Zack. If the two deployments share the same instance configuration, then to distinguish the runs for each deployment, they will need to have unique code location names.

Thanks prha. Sounds like it will work. Currently, we are on Dagit 1.0.17 using repository, and the concept of code location was released on 1.1.7. Is there a way we can quickly convert the repository to code location?

Location names existed in

1.0

, but were more hidden. In your

workspace.yaml

file, you can specify a

location_name

for each of the

load_from

targets. This should enable you to distinguish runs for two repositories that are named the same across different deployments.

Hi prha, thanks for your info. I have added the location_name in the tenant's workspace yaml file. Then on its Dagit UI, I can see the location_name I gave reflects under the deployment. However, when I triggered the job from other tenants which have their own Dagit and workspace, I can still see the job pop up under this tenant's Dagit UI Job Run. Would be much appreciated if you have any ideas about it.

Just so that I’m sure what the issue is here. When two deployments, each with its own uniquely named code location are sharing

DagsterInstance

storage, I would expect that the top-level

Runs

view (i.e.

<domain>/runs

) for both deployments to look identical. However, when I navigate via the left nav to a specific job in that code location, and click the

Runs

sub menu (i.e. next to

Launchpad

,

<domain>/locations/<repo_name>@<location_name>/jobs/<job_name>/runs

), I would expect those runs to be specific to that particular location-scoped job. Is that what you’re seeing, or are you seeing both sets of runs in that job-scoped runs view?

We were hoping that the main “run view” (when you click runs in the top nav) would only show the jobs that were related to the jobs inside of the code location that is registered with that instance of digit. It is showing runs from any workspace, regardless of whether or not that workspace is part digit. So for this test, we have 3 instances, one dagit, whose workspace is configured to point to code in two different GRPC locations (lets call them tenant a and tenant b). We setup a dagit for tenant a with 1 grpc code location, and a dagit for tenant b with 1 grpc code location. We used the location_name (instead of a converting our repository to a definition). We were hoping that when we view the dagit for tenant a, we would not see the jobs initiated by tenant b on the runs page. Is the default behavior to always show all runs that have been persisted to the underlying Postgres instance?

Yes, that is the default behavior. The top-level run view is tied to the instance and displays all the runs in the instance.

Is there a way the team can add a filter on the runs page, that would allow someone to filter by code location name? There is no filter for repository that I’ve seen.

We do have hidden tags, but they’re kind of an internal implementation. Let me verify if it works to specify them in the frontend as a hacky workaround…

Thank you!

For now, it will work to apply

tag:.dagster/repository=<repository_name>@<location_name>

in the search filter

Excellent, we will give it a shot! Thanks again!

Thanks a lot prha! The

RepositoryLabelTag

filter works. Do you have any plans like adding a flag for the repository in the Kubernetes dagit deployment, and it will apply the filter by default in the dagit UI?

I don’t think we have any plans to, no. We’re really focused on code location management / observability, but not necessarily on multi-deployment support. I think spinning up a different instance (pointing at a different logical database) is probably your best bet for what you want. You’ll then get separation at the storage layer for your different deployments.

I think it’s unlikely that we support this type of env-based filtering in our graphql layer. We do support custom storage classes, if you wanted to write your own

RunStorage

class. It could extend the appropriate official variant class and then override all the run queries by adding the appropriate tags. You’d then just have to point your

dagster.yaml

at your custom storage class.

We will explore this thanks