As part of the official support model, we need to figure out what use cases the docker images are intended for. This will bleed over into the testing and documentation effort and should be done first.
Examples
1 - is this intended only for short term testing, or is it suitable for longer term testing (one implication is perm or transient storage in docker), maybe separate docs for each
2 - what tools should be container-ized? testpoint seems obvious starting point but maybe others
3 - do we need to figure out what OSes we know this will run on just to establish limits? for example, you can run a docker container under Windows so we may need to figure out how far we plan to support it.
4 - does it make sense to write "wrappers" that let you do things like run commands natively that proxy them over to say pscheduler inside the docker container, other small tools / utilities that might help with this?
As part of the official support model, we need to figure out what use cases the docker images are intended for. This will bleed over into the testing and documentation effort and should be done first.
Examples 1 - is this intended only for short term testing, or is it suitable for longer term testing (one implication is perm or transient storage in docker), maybe separate docs for each
2 - what tools should be container-ized? testpoint seems obvious starting point but maybe others
3 - do we need to figure out what OSes we know this will run on just to establish limits? for example, you can run a docker container under Windows so we may need to figure out how far we plan to support it.
4 - does it make sense to write "wrappers" that let you do things like run commands natively that proxy them over to say pscheduler inside the docker container, other small tools / utilities that might help with this?