This also changes docker2aci's interface. We now require the prefix
"docker://" to get images from a Docker registry and assume that if it's
not present the user means a local file.

I'm 50/50 on this (vs. having a --from-file flag or so). Is your thinking that we should have the same syntax as Rocket? Or that converting from local images will be the more common use case?

This also changes docker2aci's interface. We now require the prefix
"docker://" to get images from a Docker registry and assume that if it's
not present the user means a local file.

I'm 50/50 on this (vs. having a --from-file flag or so). Is your thinking that we should have the same syntax as Rocket? Or that converting from local images will be the more common use case?

Yeah, I'm also on the fence about that. I implemented it this way to keep it simple: adding a --from-file is less convenient for what I think would be a pretty common use case. Since we're already using this syntax in Rocket it seemed a pretty good choice. I don't really know if converting from local images will be the most common use case, probably not.

We also have to think whether we want rocket to support converting files generated by docker save and how to expose it...

Thanks a lot for the review!

We also have to think whether we want rocket to support converting files generated by docker save and how to expose it...

I don't think this is necessary, if people really have exported Docker images around it seems reasonable to expect them to use docker2aci (it's just one more command). My feeling is that the Rocket auto-Docker stuff is mostly useful for referencing images from repositories.

Yeah, I'm also on the fence about that. I implemented it this way to keep it simple: adding a --from-file is less convenient for what I think would be a pretty common use case. Since we're already using this syntax in Rocket it seemed a pretty good choice. I don't really know if converting from local images will be the most common use case, probably not.

@philips any feelings on this?

@jonboulle @iaguis Can you provide a CLI example. I am having a hard time following.

@philips

docker2aci quay.io/coreos/etcd
docker2aci --from-file ./etcd

vs. (like rkt)

docker2aci docker://quay.io/coreos/etcd
docker2aci ./etcd

I see. The other option is to just always make it a url like file://etcd

Sure, I consider ./ a minor optimisation over that

Yea, we just need to be explicit. The current state in rkt bothers and we need to fix it because the rules are ambiguous and can lead to mistakes or confusion.

This is a stupid example:

cd $HOME/src
./github.com/coreos/rocket/bin/rkt run github.com/coreos/etcd
github.com/coreos/etcd: error reading image header: read github.com/coreos/etcd: is a directory

@philips agreed, it just hasn't bothered me personally enough yet to
prioritise it. Do you want to file another readme-driven-development issue
on coreos/rkt?

On Tue, Mar 31, 2015 at 10:20 PM, Brandon Philips [email protected]
wrote:

Yea, we just need to be explicit. The current state in rkt bothers and we
need to fix it because the rules are ambiguous and can lead to mistakes or
confusion.

This is a stupid example:

cd $HOME/src
./github.com/coreos/rocket/bin/rkt run github.com/coreos/etcdgithub.com/coreos/etcd: error reading image header: read github.com/coreos/etcd: is a directory

—
Reply to this email directly or view it on GitHub
#37 (comment).

@jonboulle Yes: rkt/rkt#715

danke!

On Tue, Mar 31, 2015 at 10:37 PM, Brandon Philips [email protected]
wrote:

@jonboulle https://github.com/jonboulle Yes: rkt/rkt#715
rkt/rkt#715

—
Reply to this email directly or view it on GitHub
#37 (comment).

I propose we land this as-is and can revisit the exact UX after we sort it out in rkt, @philips that sound reasonable to you?

@jonboulle Sure, go for it.