Implement the API version of the Docker containers interface #5861
Conversation
natefoo
added
kind/enhancement
status/WIP
kind/refactoring
|
This would require adding galaxy.containers to galaxy-lib since that DockerVolume class is used outside the project. I looked over the source and it looks like you are conditionally importing everything that isn't in galaxy-lib or a hard dependency - so that should be fine. |
|
Yes, good, my library shall become the standard. ;D |
docker-py param mapping. Plus some cleanup.
wrapper will call on certain types of expected failures. If the function returns a truthy value, it is returned instead. This is useful for state-altering changes where the request may have succeeded but the response failed.
natefoo
changed the title
natefoo
changed the title
natefoo
changed the title
| sys.path.remove(os.path.dirname(__file__)) | ||
| except ValueError: | ||
| pass | ||
|
|
||
| try: | ||
| import galaxy # noqa: F401 this is a test import | ||
| except ImportError: |
There was a problem hiding this comment.
Can you do this without the sys.path edit stuff? I don't think importing things from galaxy-lib should be modifying the path like this - the whole library should be importable without side effects.
Can you keep this script clean, even define a main, but then place something in scripts/ that messes with the sys.path and then just calls out the main here? Like this (https://github.com/galaxyproject/galaxy/blob/dev/scripts/create_db.py) maybe?
natefoo
changed the title
|
@jmchilton how about e651b34? Unrelated, back in WIP due to the DockerAPIClient class still not working as intended: failover doesn't work properly because bound APIClient instancemethods are passed around in the handler staticmethod, so making new APIClients in DockerAPIClient does nothing for a single call. A class var with the APIClient instance and then passing the method name to the handler rather than the method itself might work. |
class vars, since we only ever want callers to use one APIClient.
better job of catching them in the application, but this is good enough for the moment.
natefoo
changed the title
@natefoo If you prefer that approach that is fine with me. Seems like the script might be useful as a stand-alone thing installable through pip if we placed it cleanly in galaxy-lib but if that isn't a concern for you I'm fine. |
|
I think it's useful, but probably nobody but me is going to use it... I really am surprised something doesn't already exist for this purpose and I expect something better to come along at some point. |
Initially when I'd started work on adding Docker Swarm support for GIEs, I was just augmenting the existing (command line) docker calls in the GIE module. Before long, the this grew in to creating a library for interacting with containerization systems. I moved the command line work over to the new library and expanded it, adding a generalized parser for the command line's column output, among other things.
Although this worked at the time, the correct route would've been to use the Docker API, but I fell a bit for the sunk cost fallacy and finished things up using the command line. The command line stuff is now incompatible with at least some commands in the latest docker versions.
Soooooo, I've finally implemented the API versions of the Docker and Docker Swarm interfaces and deprecated the command line interfaces, to be removed in the release after 18.05.
This also includes some general stability improvements for the swarm manager, and it touches the tool dependency docker util slightly, as there was already a model for a docker volume in there. Rather than duplicate, I moved that model over to the containers lib.