-
-
Notifications
You must be signed in to change notification settings - Fork 795
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider switching to docker api for LWPR implementations #76
Comments
I started a first pass at updating the container provider to do this here, but have run into some snags getting all the tests to pass. So far my pace has been slow, so I'm posting this here in case anyone else is working on this - maybe they can use some of the work I have already done. |
Something to consider is how to manage the mapping of attributes to API values. Instead of having LWRP attributes for every API value, if we just let people pass in the same objects they would use in the API it would make things a lot easier because then the LWRP would not be tied to a specific version of Docker / Docker API. I think we can/should keep common options like image, command, name, etc but some of the more complex attributes I think would be better served being passed in through an |
It would also make managing the state of the containers so much easier since we could just compare json objects instead of inspecting each value one-by-one. |
@tduffield I spent a little time thinking about this. I'll think out loud here, but definitely would appreciate feedback and guidance! In reference to not having LWRP attribute mappings for all CLI behavior:
In reference to using the API directly:
Please let me know what you all are thinking. |
For an example of abstracting the implementation with the extra attributes, take the use case I'm fixing right now with pull/push. Since we have a How would we draw a line for what the correct attributes to leave while trimming them? Without having tag available, this seems like it'd be an undue burden for cookbook users here to now change their syntax from: docker_image 'ubuntu' do
tag '12.02'
end To: docker_image 'ubuntu:12.02' For no benefit. Same would be true if the Docker API moved it to a different spot. |
Done! |
I've found that several edge cases in the current LWRPs are caused by failures in parsing or handling the output from
docker
shell commands. Docker has a REST API, which should be much more reliable for communicating without issue. There's even a ruby client implementing the api: https://github.com/swipely/docker-apiThe major drawback of such an approach, AFAIK, is that the docker api sometimes makes breaking changes. We might have to handle various versions of docker differently (although hopefully this is stabilizing as we're approaching docker 1.0)
The text was updated successfully, but these errors were encountered: