This diff attempts a complete system-execution-context naming and structure revamp, such that we distinguish between "orchestration" (coordination of processes to perform actual execution of steps) and "execution" (actual execution of steps). As a side-effect, resources and intermediate storage are no longer initialized in the run process.
A ton of unit tests changes, integration
definitely loving this direction - I think we can trim even further as highlighted with some inline comments
this is surprising to me - what case caused this to get added?
feel like we should just delete this and move to having comments on the classes - this file just isnt natural to open to find this imo
I don't think this class needs to exist - we should just push the impl down to SolidExecutionContext
this inheritance feels a little weird since we cant do the same on the Step context classes - just makes the inheritance tree a little odd
This happens if there is a failure during resource initialization when booting up the PlanExecutionContext. Previously was a pipeline init failure, changed it to a pipeline failure.
get this stuff back in the host mode file
|130 ↗||(On Diff #35271)|
is the solid name available instead?
I don't think I can do that because I enter alternate entrypoints on PlanOrchestrationManager based on whether I am in host mode
well even if you do that - you can import the function to use here even if it lives in that file
That said - unless I am missing something - doing the host_mode bool thing doesn't seem substantially better than just having a different context manager like the current approach 
 maybe rename to Host Orchestration
instead of adding these args to this public API just for use in the in process executor - lets just dupe this small block of code in the in process executor
doc block 
mention presence / absence of access to user code