- User Since
- Jun 15 2020, 1:38 PM (69 w, 6 d)
Aug 6 2021
Aug 3 2021
Should dedup the the lists? Or at least test behavior with duplicates (I think that's already happening in the integration test?)
Jul 30 2021
Jul 28 2021
Jul 27 2021
Jul 21 2021
Do we support termination? Dagit makes that api call if so
Jul 15 2021
users might still run into this issue when their image contains an ENTRYPOINT.
Jul 14 2021
Jul 8 2021
remove config defaults
Would make sense to move to the DagsterKubernetesClient, that said we don't currently use it directly in either of the k8s launchers or the celery k8s executor. So I think it's a general refactor to move our classes away from using the k8s lib directly
Excellent. Could consider mentioning 3rd party solutions, e.g.
Jul 7 2021
Changed approach to log from the step_delegating_executor rather than the step handlers, because the executor has the step contexts and can log correctly. this also means you don't have to remember to log the individual events.
Wow I had forgotten this was necessary
Jul 6 2021
Awesome! Could move description from the diff to code comments
Jul 2 2021
Jun 28 2021
Jun 25 2021
Read only dagit would be an example of a second dagit (with a new url) pointed at the same instance
Jun 24 2021
If this happened enough on k8s via CD or something, k8s might go into crashloopbackoff. Looks like that's not tunable https://github.com/kubernetes/kubernetes/issues/57291. But users probably shouldn't hit it...
If they do, it's an exponential backoff capped at 5 min and clears after 10 min of successful running. Seems ok
Jun 21 2021
Jun 18 2021
Jun 16 2021
Jun 15 2021
Going to discuss offline
Jun 10 2021
Awesome! I think this will deserve at least a callout in the #dagster-kubernetes channel, it's a decent quality-of-life improvement.
Jun 9 2021
I like this direction too.
Jun 7 2021
Jun 4 2021
Should we consider raising an error when .get is called outside of a context manager? Something like https://stackoverflow.com/a/54514410/14656695