#docker-dev

nope... it's legal

I just tagged something as '-'

jlhawn: well, let's forbid it :)

should not start with -

I don't know why anyone would ever do it... but yeah

yeah

alright problem solved

next!

next on the docker docket

duglin: what do you think of a docker build --step (heavily borrowing from docker commit --change)

tibor: processed before dockerfile processing

so we could technically do it

duglin: we would need a way of saying "start a build", and "end the build"

duglin: and what happens if there are errors, or no more docker build commands?

maybe commit --change makes sense with an empty container

I think it'd be confusing though

I really liked DOCKER-VERSION

or something similar. less confusion that way.

erikh: that's a differnet thing :)

we're trying to determine whether or not we're working with a v2 file, right?

right, in this case it's not mutually exclusive

FROM vs BASE

duglin: could be

I don't think inferring this is the right approach

being explicit, POLS, etc.

i actually said in the comments, that we could just use commit --change (or similar), AND fix the quoting in a v3

v2*

I think forcing people to put a version string _forever_ is kind of annoying

vagrant does it

and if they jumped off a bridge…. :-)

erikh: argument of authority :)

think of it as our little shebang

yes yes yes

DIAF, all of you :P

lol noo

[13docker] 15jfrazelle closed pull request #8669: Use dual-stack Dialer when talking to registy (06master...068668-dualstack-registry) 02http://git.io/4m2Mug

you know what, i'll just use that commit --change PR and come up with a PoC and show it to you guys

as for commit --change I think that's a great way to solve the same problem much less safely

erikh: why??

because the tools need to execute on the client

explain

I would love to see a PoC to get my head around this commit —change stuff better

so we'd have a shell/ruby/perl/etc script to call commit --change?

which initiates from teh client, not the daemon

also, there are context issues there

I think.

I assume it would copy the build context to the server each time?

erikh: all we'd have is commit --change (or equivalent), and then people (and for the PoC, that'll be me) write libraries to wrap commit --change

not each time

right, but those libraries, and the tools that consume them can break out of the context

just at creation of the initial container

that will be the image

how long does the daemon need to hang on to it?

right..

the context? for the lifetime of the build

duglin: that was my question earlier

and some contexts are very large.

build context is in the daemon not the container so we need to remove it eventually.

duglin: we could remove it from the container

And can you run “build —commit” from a machine that doesn’t have the context at all?

good questions

:)

im writing them down

should we allow that? I don't think that's a good idea.

man sorry to be so stubborn, but I think the toolkit approach is the best one still

erikh: that's what i'm trying to prove :)

it effectively makes docker a CMDB and the toolkits can be consumed by any language.

toolkit == “convert Dockerfile commands into stand-alone exe’s”, right?

more or less, yeah

erikh: what i'm trying to do with this --change thing is to see where it breaks, and where introspection could help, because right now for me it's not 100% clear

tibor: write a tool that breaks out of the context

that should break it.

erikh: i'll have to think and code

sure

don't try to do those at the same time though

it'll make you go blind

hahaha

lol

erikh: would the toolkit have the same issues? ie. does need to copy the context over each time?

darn - landing soon so I’ll lose my connection soon

someone likes to merge this? https://github.com/docker/docker/pull/8390

erikh: if we assumed that we’d eventually figure out a way to know if we’re doing v1 vs v2 parsing…. are you saying that even so, you’d want us to consider getting rid of Dockerfiles entirely (ignoring backwards compat) and use the toolkit approach?

MalteJ: jessfraz today merging everything :)

:)

fingers crossed

oh ya I was just worried about the flag and if we needed design approval

duglin: I'm suggesting we amend the dockerfile in a way to render it merely as a bootstrapping mechanism for the build toolkit

1) preserves backwards compat 2) maximum flexibility

and if we sum the script used to build, we still get caching.

MalteJ: actually I think test could be more cool if you'd check real macaddr in container

but IIRC ip segfaults in busybox now :/

can't netlink do this?

oh heh

actually ip link list working

MalteJ: you shouldn't show me this PR :D

does ip link show veth1234 work?

actually duh, I can test it

yeah, it works.

ip link show eth0 | tail -1 | awk '{ print $3 }' I think

erikh: lk4d4_ MalteJ and jessfraz all have the same color on irccloud lol

$2

not $3

[12] erikh@docker ~% docker run busybox sh -c "ip link show eth0 | tail -1 | awk '{ print \$2 }'"

02:42:ac:11:00:31

fwiw

great, thanks :)

Folks, can anyone explain something to me? When I compile a docker binary (inside a container) with `hack/make.sh binary` and run it with the `-h` flag, it shows me a big list of flags supported by the daemon. However, when I compile multiple binaries with `hack/make.sh cross`, it has a much shorter list (--api-enable-cors, -D, -d, -G, -H, --tls-* and -v).

It also doesn't support any of the missing flags.

cross is the client IIRC, where binary is the daemon

at least that's what I seem to recall, but I'm probably wrong

aanand: from which dir in bundles you get binary?

lk4d4_: in the case of cross, ./bundles/1.3.0-dev/cross/linux/386/docker

erikh: Really? I had no idea we built two separate binaries for client and daemon.

aanand: only supported arch for daemon is amd64

well, I think we control this with a build tag

all other is client-only binaries

+build linux or something like that.

lk4d4_: ah, I see.

aanand: you can see this in hack/make/cross