Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Op that runs a kubernetes job #8161

Merged
merged 2 commits into from Jul 6, 2022
Merged

Op that runs a kubernetes job #8161

merged 2 commits into from Jul 6, 2022

Conversation

gibsondan
Copy link
Member

Summary:
This introduces a more direct analogue to a 'pod that manages a k8s container' - to handle cases where you want to stitch together a mixture of ops, or orchestrate non-Python languages.

A nice thing is that we can use container_context to still pass config through to ops like this (so you can set up a default set of secrets to include in all ops even when you're not launching the run in k8s, for example). And we can expose raw job_config on the op as well to give you access to the full k8s api for the job.

Summary & Motivation

How I Tested These Changes

@vercel
Copy link

vercel bot commented Jun 2, 2022

The latest updates on your projects. Learn more about Vercel for Git ↗︎

3 Ignored Deployments
Name Status Preview Updated
dagit-storybook ⬜️ Ignored (Inspect) Jul 6, 2022 at 6:14PM (UTC)
dagster ⬜️ Ignored (Inspect) Jul 6, 2022 at 6:14PM (UTC)
dagster-oss-cloud-consolidated ⬜️ Ignored (Inspect) Jul 6, 2022 at 6:14PM (UTC)

@gibsondan gibsondan force-pushed the createk8sop branch 3 times, most recently from 9d38608 to 1f7db88 Compare June 2, 2022 17:59
@gibsondan
Copy link
Member Author

will add some more tests / termination support etc. but curious for any initial thoughts

@johannkm
Copy link
Member

johannkm commented Jun 2, 2022

Sweet. One q is should it be an op or a resource (that basically just wraps our client methods). I think @OwenKephart had mentioned that leaning towards resources can be preferred? It simplifies unit testing I suppose

@gibsondan
Copy link
Member Author

Yeah I was talking with @sryza about this a bit yesterday too. I'm not totally opposed to pulling the k8s-specific part of this into a resource and making this a "run an arbitrary container op" that depends on a particular resource (almost like a steplauncher, sort of... ) but I also think this there might just be people out there looking for the same KubernetesPodOperator experience, but in Dagster?

@gibsondan
Copy link
Member Author

I don't think it should just be a resource though, in case that's what you're proposing. If we only provided the resource I think you'd end up with a lot of boilerplate every time you wanted to use it to run a container.

@OwenKephart
Copy link
Contributor

late to the party, but I'm not concerned about the lack of resource-y ness for this particular integration. There are basically two reasons that I tend to push lots of implementation details into resources when writing integrations:

  1. There's a reasonable chance that someone will want to have multiple ops that share a ton of config between them, so it's nice to factor all that config into a resource which in turn does the heavy lifting.
  2. We're interfacing with some service that is impossible to call in a different mode (e.g. local mode), and so we want to give an easy entry point for mocking out behavior.

Because it seems like most of the config here is unique per-op, and it's possible to run k8s locally, this setup seems ok to me.

Copy link
Member

@johannkm johannkm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe check on the containers in the test, but this lgtm

Summary:
This introduces a more direct analogue to a 'pod that manages a k8s container' - to handle cases where you want to stitch together a mixture of ops, or orchestrate non-Python languages.

A nice thing is that we can use container_context to still pass config through to ops like this (so you can set up a default set of secrets to include in all ops even when you're not launching the run in k8s, for example). And we can expose raw job_config on the op as well to give you access to the full k8s api for the job.
@johannkm johannkm merged commit b4fa57e into master Jul 6, 2022
@johannkm johannkm deleted the createk8sop branch July 6, 2022 19:33
prha pushed a commit that referenced this pull request Jul 6, 2022
* WIP: Op that runs a kubernetes job

Summary:
This introduces a more direct analogue to a 'pod that manages a k8s container' - to handle cases where you want to stitch together a mixture of ops, or orchestrate non-Python languages.

A nice thing is that we can use container_context to still pass config through to ops like this (so you can set up a default set of secrets to include in all ops even when you're not launching the run in k8s, for example). And we can expose raw job_config on the op as well to give you access to the full k8s api for the job.

* Make wait_for_pod disable timeout on 0

Co-authored-by: Johann Miller <johann@elementl.com>
Jiafi pushed a commit to Jiafi/dagster that referenced this pull request Jul 11, 2022
* WIP: Op that runs a kubernetes job

Summary:
This introduces a more direct analogue to a 'pod that manages a k8s container' - to handle cases where you want to stitch together a mixture of ops, or orchestrate non-Python languages.

A nice thing is that we can use container_context to still pass config through to ops like this (so you can set up a default set of secrets to include in all ops even when you're not launching the run in k8s, for example). And we can expose raw job_config on the op as well to give you access to the full k8s api for the job.

* Make wait_for_pod disable timeout on 0

Co-authored-by: Johann Miller <johann@elementl.com>
gibsondan added a commit that referenced this pull request Jul 26, 2022
Summary:
Overriding the command in container_config changed in #8161 - we override the passed in command to the function, even if it is empty. Instead, fall back to the user-provided container_config if it is set.

Test Plan: BK
gibsondan added a commit that referenced this pull request Jul 26, 2022
Summary:
Overriding the command in container_config changed in #8161 - we override the passed in command to the function, even if it is empty. Instead, fall back to the user-provided container_config if it is set.

Test Plan: BK
gibsondan added a commit that referenced this pull request Jul 26, 2022
Summary:
Overriding the command in container_config changed in #8161 - we override the passed in command to the function, even if it is empty. Instead, fall back to the user-provided container_config if it is set.

Test Plan: BK
gibsondan added a commit that referenced this pull request Jul 26, 2022
Summary:
Overriding the command in container_config changed in #8161 - we override the passed in command to the function, even if it is empty. Instead, fall back to the user-provided container_config if it is set.

Test Plan: BK
gibsondan added a commit that referenced this pull request Jul 26, 2022
Summary:
Overriding the command in container_config changed in #8161 - we override the passed in command to the function, even if it is empty. Instead, fall back to the user-provided container_config if it is set.

Test Plan: BK
@johannkm
Copy link
Member

johannkm commented Oct 11, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants