https://dagster.io/ logo
#deployment-kubernetes
Title
# deployment-kubernetes
z

Zack D.

03/22/2023, 4:20 AM
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.
p

prha

03/22/2023, 4:22 PM
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.
❤️ 1
z

Zack D.

03/22/2023, 6:06 PM
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?
p

prha

03/22/2023, 7:05 PM
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.
z

Zack D.

03/23/2023, 7:53 PM
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.
p

prha

03/23/2023, 10:37 PM
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?
k

Keith Gross

03/24/2023, 2:41 PM
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?
p

prha

03/24/2023, 3:31 PM
Yes, that is the default behavior. The top-level run view is tied to the instance and displays all the runs in the instance.
I think to achieve what you want, you will need separate logical databases / separate instances per deployment.
Apologies for misunderstanding the question before
k

Keith Gross

03/24/2023, 4:22 PM
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.
p

prha

03/24/2023, 4:26 PM
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…
👍 2
k

Keith Gross

03/24/2023, 4:26 PM
Thank you!
p

prha

03/24/2023, 4:29 PM
For now, it will work to apply
tag:.dagster/repository=<repository_name>@<location_name>
in the search filter
👍 1
As fair warning, we may change this in the future for performance reasons
k

Keith Gross

03/24/2023, 4:31 PM
Excellent, we will give it a shot! Thanks again!
z

Zack D.

03/24/2023, 5:55 PM
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?
p

prha

03/24/2023, 9:15 PM
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.
k

Keith Gross

03/29/2023, 1:53 PM
@prha
would it be possible to include something like this code (obviously it should be properly abstracted behind however graphql handles configuration). Ideally we would be able to filter the repo list to the ones that are registered with that particular instance of dagit, instead of configuring the name as an environment variable. This would bring the jobs page more inline with other pages like the timeline, that shows the timeline view filtered by repository. The nice thing about this, is that the filter is hidden from the UI so the user doesn't have the option to remove it.
p

prha

03/29/2023, 8:02 PM
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.
k

Keith Gross

03/29/2023, 8:30 PM
We will explore this thanks
3 Views