Description
Currently, when a user wants to use the DragonLauncher, we stand up a ZMQ-backed client-server infrastructure, where the server executes dragon and then serves requests from the client, which is launched through python.
We should now switch to demanding that the user launches the workflow driver script through dragon and execute requests locally. This will eliminate a large portion of code which was thought to support workflows which are not in scope anymore.
Justification
The codebase will be easier to maintain, and users will not risk having ZMQ-related issues when launching SmartSim.
Implementation Strategy
The whole DragonConnector part should be removed and the DragonLauncher should simply have an instance of DragonServer running locally.
Description
Currently, when a user wants to use the
DragonLauncher, we stand up a ZMQ-backed client-server infrastructure, where the server executesdragonand then serves requests from the client, which is launched throughpython.We should now switch to demanding that the user launches the workflow driver script through
dragonand execute requests locally. This will eliminate a large portion of code which was thought to support workflows which are not in scope anymore.Justification
The codebase will be easier to maintain, and users will not risk having ZMQ-related issues when launching SmartSim.
Implementation Strategy
The whole
DragonConnectorpart should be removed and theDragonLaunchershould simply have an instance ofDragonServerrunning locally.