#docker-dev meetings are held twice a week in the #docker-dev irc group on Freenode. This irc channel is logged all the time, so you can always refer to it.
Please remember that there are now 2 meetings, one in an Asia-Pacific timezone, and this one in the SF timezone.
proppy was commenting on shykes's proposal, but it started to deviate into
'why don't you do this different thing', so forked to a separate Proposal.
And so asked the Question: when should one fork,and when is it best to stay with divergent comments?
shykes:
-At the moment, if your comment becomes the subject for other comments, rather than the TLDR,
it makes sense to fork.
- we can try using PR's and markdown files as proposals, to facilitate reviews and responses.
And then discussing proppy's version of the Proposal, yes, it looks like forking is
a little excessive, as its a tweak of initial proposal to use the IN /dir {} /dir as
the context of the inner build.
Discussion will continue in the issues and the proposals will get merged.
So volume snapshotting... basically the idea is to create an actual fs/volume when a volume is created so we can do snapshotting for the purposes of backups
And provide the API to perform that snapshot
claytonc wondered if making volumes a container would make this easier.
cpuguy83 indicates the only thing holding this back is that volumes use vfs-driver
This is something I was trying to resolve around the weirdness of volumes during build. I don't think this is a complete solution.... My original thought was to provide an option on commit to allow committing volumes back into an image, and we'd turn this option on by default during build. But shykes mentioned we'd rather just not create the volume during build, but as it turns out this is really hard to do. This PR essentially defers volume creation to the last build step, but it still gets applied, so anytime you use "FROM" where "FROM" has a volume specified, you still have the weirdness It seems like the daemon needs to be aware if the container is for an intermediate build or not and handle the volumes there Or I think the original plan (commit volume data back into the image) is probably the easiest route. And then we aren't modifying the behavior of the daemon just for builds. And I think there are those who would like to be able to commit volume data in their prod containers too.
The problem with this patch is that it busts the cache, for everybody it's technically a correct patch though, and fixes real issues in the parsing of the dockerfile
massive discussion continues
TODAY IS THE DAY prepare yourselves
the repo is moving
all comments, PRs, issues, etc etc etc will be retained
Some further updates happened afterwards:
we are working on a proposal and prototype of trust using json web signatures.
There is currently some prototyping being done to continue to use the current image format, but include JWS for image signin
We're also prototyping a way to authenticate with the registry using JWT, rather than HTTP basic auth The underlying design theme is to switch everything over to pubkey auth, instead of login/pass So you don't have to store base64 passwords in your home directory
we're also working on a new design for the index-registry workflow described here https://docs.docker.com/reference/api/hub_regis...
At this point we're moving ahead on having detached signatures, as a stop gap we don't have a design spec ready to release at the moment, much like this, it's still a collection of notes and IRC logs the redesign of workflow, is API conversation going to be an open one? one of my questions to dmp42 this morning was whether we should, as a community, further 'docker-registry' or the "the registry API Spec" because there are requirements that we are already running in to, that have us wondering whether we shouldn't have its own registry implementation the workflow changes I alluded to above only concert the API between the docker registry and docker-hub, so it doesn't affect the open source registry in standalone
next step is a design proposal from jlhawn and dmcg actually it's finishing gh#6805 Self-describing images
This discussion continues in the irc logs