- User Since
- Mar 20 2019, 8:25 PM (44 w, 1 d)
Exposing a configurable priority key is actually pretty risky and will result in a lot of replicated config.
So the crux of it is:
- we do dagster/priority and it works for the core executors but (probably?) none of the others which leads to an unfortunate expectation mis-match in a not clearly communicated way (keys just ignored)
- we do separate keys for each executor to align expectations ie dagster/in-process/priority, dagster-in-process/priority, whatever but thats aesthetically unfortunate and leads to having to set all keys to support different execution modes
what should the predefined keys be for the in process and multi process engines? I wasn't happy with what I came up with which motivated me to punt it out to config
move sorting out to individual engines. use config to drive what key to use for prioirty on default engines
changes here all seem reasonable to me
I think this is better
dont have strong feelings - but the complexity cost of warn here feels pretty minimal so i maybe lean that way
can you explain automated comment. i think i am missing something
flipping the bool does make the change not quite automated - not sure where that nets out on hard break vs deprecate
personal opinion: the blue color is a bit agro i would try to tone it down a bit
revert change to other code
fix old code and add comments to tests
different approach to handle mock issue
I'm cool with this if 'handle-like' names are actually the same as the handles - if not it would be good to get an explanation of what exactly is going on there
more ordered dict
cant repro locally add some logging for BK
proper way to test this? This error only comes up at either schedule page load time or schedule execution time because that's when we run environment_dict_fn.
Tue, Jan 21
set mock to None when not found
does the non-slim have gcc?
back to debugging
seems fine, although isn't this a slightly different fix than the warning text indicates?
Sat, Jan 18
set service account name
I would just look through the other tests in dagster_graphql - python_modules/dagster-graphql/dagster_graphql_tests/graphql/test_run_cancellation.py is probably a relevant example
god damn yaml templates
Fri, Jan 17
just spitballing ideas one thing we could do is keep the box pinned but to the left but change where the shading starts? What i want visually communicated when these things are waiting on eachother for not-data reasons is:
from use - if you execute the sleepy toy pipeline with the default config which uses inprocess engine - the four parallel steps happen sequentially which is not communicated in the waterfall timed view at all since we pin no the left alignment. Is this something worth addressing now or in a subsequent diff?
Thu, Jan 16
this seems fine, double check if you need to add the check stuff
special case singurlar input_def
update serdes and seven to better handle py2
nice - just make sure to cleanup unused stuff
rebase + comment
Wed, Jan 15
it seems like something bad is happening in changed.md thats causing the autoformatter to go nuts