Consider switching to docker api for LWPR implementations about docker HOT 7 CLOSED

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.

from docker.

How are we feeling about this approach @jcrobak / @ryandub?

from docker.

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 options parameter.

from docker.

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.

from docker.

@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:

• Having the attributes available allows us to abstract away the underlying Docker implementation, whether we're talking to CLI or API as well as any syntax changes in either case
• There's nothing currently forcing you to use a specific Docker CLI/API version unless there's a new CLI argument that's not yet available in the cookbook or newer Docker requires a different CLI syntax
  • One thing we can do for "missing" attributes is add a generic "catch all" attribute such as additional_args (CLI) or additional_json (API) for these scenarios
  • If there is removed functionality in Docker, it just requires removing those attributes from your cookbook (you'd have to update your workflow for the updated CLI/API version anyways)
  • As mentioned in #142, if we want to support the syntax nuances between Docker versions, I'm open to a PR with a clean implementation (regardless this would be required for both CLI and API backends) - seems like yak shaving to me though; just don't upgrade the cookbook until you're ready for the versions the newer cookbook works with? Could probably use COMPATIBILITY.md a little more here.

In reference to using the API directly:

• Usability? Constructing JSON objects is harder IMO than CLI arguments, especially if we'd force the users to do that in their cookbooks
• Comparison? I'm not seeing how you'd avoid inspecting each value one-by-one regardless of implementation, what if Docker adds information to their JSON or changes the keys between versions? Same thing as #142 point above.
• Advanced features? Are there API features that are not available via CLI?

Please let me know what you all are thinking.

from docker.

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 tag attribute available, I can move it behind the scenes from being a CLI arg (--tag=FOO) to being part of the image name (IMAGE:FOO) to match the syntax Docker now wants.

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.

from docker.

Done!

from docker.