Docker Advisory Board First Meeting Notes 28 October 2014

docker_advisory_board_notes_28_october_2014

    

Docker Governance Advisory Board First Meeting
Notes 28 October 2014

Interim Chair: Van Lindberg (VL)



Attendees/Acronyms table:

BG. Ben Golub ([email protected])
SH. Solomon Hykes ([email protected])
VV. Victor Vieux ([email protected])
MC. Michael Crosby ([email protected])

AT. Andrew Tianon Page (tianon) ([email protected])
BP. Brandon Phillips ([email protected])
DC. David Calavera ([email protected])
JR. Jonathan Rudenberg ([email protected])--via Phone

DI. IBM (Dave Ings) ([email protected])
VL. Rackspace (Van Lindberg) ([email protected])  
DW. Red Hat (Dan Walsh) ([email protected])
MP. Red Hat (Mrunal Patel) ([email protected])
JB. Google (Joe Beda)

NP. Atlassian (Nicola Paolucci)([email protected])
RS. Spotify (Rohan Singh) ([email protected])
MB. Ebay (Meghdoot Bhattacharya) ([email protected])-via phone
BB. Tutum (Borja Burgos) ([email protected])

## Materials incorporated by reference
-DGAB charter: DockerGovernanceAdvisoryBoard_octoberversion
-Presentation 1: DockerGovernanceIntro6wsuggestedchagnes.pptx
-Presentation 2: DGAB 2014-10-28 - Docker Project Governance & Proposals v0.3.pptx
-Presentation 3: DockerProjectStatement of Direction v.01.pptx

## Introduction Round, Initial Statements

Dan Walsh
- has concerns around patching and getting patching upstreams
- Some patches may be too specific and they want to be able to distribute Docker with patches

Dave Ing
- IBM is a recent member of the community
- IBM has extensive experience of Open Governance and Open technology
- They support OpenStack / Cloud Foundry, see recent announcements
- They don't have specific technical concerns, 
- So far they have 44 approved pull requests and growing.

Rohan Singh
- His interest is in Orchestration and tools
- Spotify is heavily invested in using Docker
- Interested in seeing where the community is going
- Maintainer of Helios

Andrew Tianon Page
- Excited for this meeting
- Hopes to get feedback on the governance process

Nicola Paolucci
- Here as enthusiastic user of Docker.
- Excited to hear about the roadmap and interested in point of view how Docker can help developers.
- Atlassian is embedding Docker support into their product suite.

Michael Crosby
- He is interested in improving the governance processes

Solomon Hykes
- Chief Maintainer BFDL
- Interested in processes what can be improved
- He wants to be less a BDFL
- He does not want to make decision calls every day
- He wants to push ownership to more and more people

Ben Golub
- CEO of Docker is only an invited guest
- He wants to make sure Docker is honest in running the project as an open project
- The advisory board will help keep Docker honest
- 650 contributors
- 4500 pull requests and it's only going to increase
- There are now some interesting questions that need to be resolved

Van Lindberg
- Heavily involved in various communities
- He was at PyCon UK recently and after he spoke to them they were inspired to learn Golang.
- He wants to make Docker a

Representative from Ebay on the phone
- They are working to get Docker in Production in all their data centers
- He would like to see some extra capabilities added.

Jonathan Rudenberg
- lead developer of Flynn, an open source platform as a service
- He has a lot of experience in handling open source communities

The materials of this meeting will be made public

Joined later and had no initial statement:

- Joe Beda from Google
- Borja Burgos
- Brandon Philips

## Opening comments to Charter and Goals

VL: one helpful thing is to throw questions and get the most concerns answered. Are there initial thoughts about the charter?

SH: Interested in a snapshot of feedback and criticism for the maintainers.

DW: standardisation on some of the protocols, more upfront discussion on how to talk to docker registry, registry compatible system of top of xxx, wants to be involved on the protocols. Working on the v2 format of the image.

DI: IBM looking for ways in which they can contribute.

BG: hopes that this establishes a good model for users and contributors making sure the technology is not owned by a single company.

VL: he likes the idea that someone who uses Docker has a consistent experience.

DI: IBM they have layers with experience of governance, their lawyers thought the document was well written the minor comment want some elaboration on when the dgab meetings are

RS: the charter says that anyone can propose topics to the board but it didn't specify which email address to use.

BG: Can we put the document on GH and accept pull requests?

DI: paragraph 4.1 Chairman of the board limited to 2 terms, do we mean the company or the individual? 
MP: He interprets it as "human beings/individuals".
SH: The number of companies contributing to Docker will not be huge so if we limit this to companies this will create problems. So it makes sense to keep this as "humans".
SH: A "reward" for major contributions should be a place on the board.
VL: The recommendation is "individuals are limited but companies are not".

PROPOSED ACTION: BG to add proposal on GitHub, including clarification on term limit (individuals, not companies),  how to dissolve board, that topics are suggested via pull request or email to chair). (UPDATE: Proposed changes reflected in DGAB charter)
## ROADMAP

BG
-By DockerCon, we had large numbers of web companies (EBay, Gilt, Groupon, etc.) talkin gabout their use of Docker 
-Now, Large investment banking firms, government agencies, pharma companies, & other traditional enterprises are  using Docker

-Showed slides
SH
- The data shows how much of a community project Docker really is. 
It is hard to avoid some sort of difference in contributions between internal employees and external. 
- They asked external contributors what is their experience in getting patches approved.
- 94% of PR are closed within 30 days. Pretty healthy.
- There is a difference between how fast PRs are closed for employee/non employees. 5 days average for employee / 9 days non employee.
-Median time to close for both employees and non employees is 1 day
- They anticipated differences but it's what they expect. The numbers are very reasonable 

VL: One topic mentioned in the opening statements was process improvement, let's pause here and note: here are the outputs. Are there places we need to improve our processes here? Are there concrete places where we should have more defined metrics?

JB (Google): you make a distinction on trivial/non trivial patches. Can we see those numbers removing the trivial patches? 
SH: There is a difficulty to gather that data but he is convinced that the patches numbers for non-trivial patches would be low.
SH: Patches that have some pre-design work tend to be approved faster.
SH: we want to improve the process for pre-design work.
SH: The charts (see slides) shows they are saying NO more and more over time. In the cumulative.
SH: Also the chart includes (or not?) the situation that happens where it's easier to close a PR and reopen.
SH: Sometimes maintainers will carry patches to reduce friction while in the past they used to say - please rebase - when they do that the stat reports that the PR has been rejected. They want to get better at tracking those numbers.
DW: number of lines changed would be interesting to see. Less than 5 lines change could be considered trivial.

XX the majority of PR are approved in the short term.
- Design upfront discussion and a clear design roadmap would help a lot complex changes.

SH: The long tail of pending PRS is comprised of proposals that have merit but they come in the form of a very large patches that require a lot of discussion. the PR paralyzes between the desire to accept the contribution and also from the desire to start and go step by step, from step 1. Please first do design. The effort that it takes to wrap your head around a contribution is huge, but they do not want to turn people away. This process becomes paralyzing and there is a lot of churn.

DH we see 3 classes of patches:
- Patches like: dash dash change patch and similar ones (NOTE TAKER NOTE: need help here...)
- Or like patch that allows you to set environmental variables and the maintainer from the CLI (NOTE TAKER NOTE: need help here...)
- For those categories we need someone from Docker to say: "yes the design looks good go ahead and finish it".
- Second group of patches is: Something which works around the docker registry and the commercial entity Docker Inc.
- Third category: Distribution specific patches. RH wants to get systemd to run properly inside the containers. They'd like to change Docker to influence the application that runs inside a container. Docker guys don't want things to work differently on different distributions.
- Every patch gets attention 1-10 days and then falls off.

VL: What about a periodic roll up of old patches?
BG: would it help to classify those long forgotten patches?

SH: (Answering about the commercial concern of Docker Inc.) The maintainers are not interested in the commercial viability of patches, they care about design. Nobody as a maintainer should pause to consider their employer business model. What's in the interest of the project will benefit Docker Inc. the company. There is a lot to fix in tools, and we want to focus on transparency in design so that people are not concerned with business model considerations.

JB (google): why not reset the public registry? If I do domicocker pull golang it will go to docker hub. 

SH: They are putting a lot of work in making sure hosting registries can exist outside of the DockerHub.
SH: dockerhub is not a profit center.
SH: he would like a bit torrrent like transport

JB (Google): Are you in favor of federation of the registry
SH: everyone should benefit from a single name space.
SH: he wants to make sure that the experience stays consistent (pulling from Ubuntu registry could have a completely different result than pulling from RedHat registry).
SH: If you are a RHEL user you might get some extra users on those images. ACL is done by custom certificates. IPv6 vs IPv4
SH: he wants a global namespace address

JB: (Google) take the DNS model. Does Docker Inc. own the federated namespace?

SH: The model that they are pushing is a new model, it's not the usual model, he thinks is sorely needed. Docker is not a collection of OS bits attached to a global infrastructure. You need a global name space otherwise it's not Docker anymore. A global federated name space and to accomplish this someone needs to run servers and operate them. The classical model of PyPI had big flaws. At Dotcloud when they were 12 employees , 45% of their application was depending on PyPI. So the current model (of the Docker Registry) avoids that problem. They run that global name-space infrastructure.

You need an account on the DockerHub, how do we make sure that Docker Inc does not lock up that global namespace?

JB (Google): Docker is both a project and a global namespace. He'd like to see a firewall between service component and the commercial entity Docker Inc.

SH: The model works because by running that infrastructure they have a healthy business. Docker does not sell an elaborate unrelated platform, they offer a free infrastructure and you can pay for a premium private host if you want.

JB (Google): we recognize the power to monetize the people attention. He is worried that they are supporting an OS project that might have ads to competitors. The integral part of experience is some commercial offering and that creates some problematic situations.

DW: For some of their partners they can't have any Docker command hit the registry. They want to split the registry naming.

SH: the currently single largest effort (top 3) is to reduce the implicit dependency of storing stuff on the Hub and decentralizing as much as possible.

JB (Google): Would you support other parties mirroring the index?
SH: We need to go into more details on this topic but the main question is "does it fragment the global namespace?"

JR: why not use existing decentralized infrastructure like URLs?

SH: The goal of Docker is: you can receive a bundle of bits by any transport, from anywhere and you can run it into the Docker runtime and validate that it is from a trusted provider. He acknowledges that there is more coupling than necessary right now, you should not be forced to downloading that image from Docker registry.

VL: Some feature languish because of the business model of Docker Inc.,can we make a statement about the policy of which patches are accepted or not related to this?
Explain some of the rationale of how these issues (like the global name-space) have been thought about.

SH: A lot of registry patches have been closed because they want to involve the participating companies in the design upfront. They close issues when they have a fitting design.

DW: The concern is that you don't want orchestration to be easy on the command line.
SH: I am not aware of any concern related to that.

DW: Forcing people to always type the full URL is a pain, everyone wants to have a config file, just to type less characters. And you can go and look what you have in there, I might have redhat.com/ubuntu and not something else.

SH: URL vs canonical short name is a legitimate discussion that already happened several times. I appreciate the argument for URLs but we prefer the package rpm style install without URLs. A flat name-space has many pros.

JB (Google): As long as there is the ability to replace the whole name space with some configuration.
SH: Future versions of Docker will enforce name-spaces using crypto.

JR: How can you enforce a name-space using crypto?
SH: By using a CA
JR: Oh, so it’s still centralized?
SH: Correct, just the minimum necessary centralized

BG: There is a general concern that PRs might be rejected for commercial reasons. They want to put a process in place to answer to these concerns.
ACTION: BG recommends putting in place an escalation process, so those who feel that a decision is made for Docker, Inc. commercial rather than project level concern can raise the issue and get a formal response from both Docker Project Leadership and Docker, Inc. (UPDATED: Suggestion for escalation procedure. Step 1, send an email to [email protected] outlining the suspected issue. Maintainers have 1 week to respond. If not satisfied by answer, create an issue on GitHub and copy DGAB chair.)
VL: Confirms this would be helpful.
BG: Wants to go the extra mile to establish trust on this.
SH: Fixing underlying problems of processing PRs and getting clarity on their design will solve a lot of these problems.
VL: very helpful to surface these concerns.
SH: 30/60/90 days roll up of PRs? Good idea.
ACTION: Docker Project Leadership to do a periodic report, with an explanation for any PRs older than 60 days
DW Distribution issue is about perspective. (NOTE TAKER NOTE: need help here...)
DW More important to us is they put patches for upstream but they can't wait for Ubuntu to support some packages. They will not be waiting for Canonical.
SH: he agrees with that as long as it does not break if it's not there. And that's the point DW: some of these patches break things.

XX: Their official system is based on Ubuntu. He would like to see the patch being merged but the problem is they can't build it in their default image.

MP: What about having Docker Distro specific builds?
SH: Yes please. Every single contribution should be tested on all distributions.
VL: work with community people is needed to setup a gating build process, a QA process that the community can participate in. So that RedHat is not being held up by Ubuntu package decisions.
SH: There is extreme openness for people to contribute in any aspect of this. By far the easier way to contribute is to send a patch. But there is an enormous demand for anything else. Becoming a reviewer/maintainer, dig into the nasty bugs that are hard to reproduce.  

DI: (IBM) What do you guys need and how do we help? 
SH: They need to better communicate what help they need. 

VL: Roadmap you showed is largely a technical roadmap but maybe we want a roadmap on the infrastructure?
SH: they have follow up slides on it

AT: We recognize there is no clear guidance on how to contribute. The current Docker structure is not very well known.

VL: What about a few blog posts on the current structure: state of tooling?
SH: The contribution and design process on one hand, the recruiting and onboarding and guiding, and third the tooling. Those don't have dedicated maintainers for these areas yet.

## PROPOSAL

JB (Google): Docker is an anchor of a large ecosystem of projects. Docker Inc bought Fig, is it a separate project or is it going to be in Docker?

SH: it should be explicit. The Fig guys make proposals and those are reviewed as every body else's.

JB (Google): The idea is we will be more comfortable if we know how to contribute both to Docker and the larger ecosystem. 

SH: The day after Docker Inc. acquired Fig nothing changed at all, everything is still in the Open. The reason for the acquisition was to make Docker more user friendly. The experience should be awesome. The more people we can throw at the problem the better.

VL: Understanding what is off limits or at least where the limits are would be helpful. This is entirely driven by technology? We can collaborate "here" but maybe we can compete "there".

BG: It's absolutely right, there is a large number of projects competing with Docker Inc. and that's fine. Some folks want Docker to remain a packaging format. We should add a statement there on clarifying this.
ACTION/Ben to add line clarifying Docker project as center of eco-system of project (UPDATE: Done in ppt)

VL: Relationship between Docker Inc. and Docker the project have prevented some parties from contributing?

SH: In reality the decisions are made for design reasons and not commercial reasons. We need to be more clear about those decisions. More crisp. We want to make clear those principles. For example the name-space decisions.

JB (Google): Systemd is polarizing for the scope creep. There is a danger that the same thing would happen to Docker. That it eats the ecosystem.

SH: I can speak in broad lines on the design guidelines. Docker does not want to be a single component. But it does not want to become Systemd. Composability has to be a core criteria.

JB(Google) Example: One of the goals is to move to a container centric programming model. The consistency of user experience is at odds with some of the requirements. There is Docker core and then there are some extra modules that would be more palatable for us.

SH: I agree and the intention is in doing that. A lot of his work is making things modular. That is the goal. But he wants to avoid allowing people to hack things apart in an unproductive way. It's very hard to get the stuff right.

VL: Outcome: Maybe we could make a statement of ambitions: if Docker was complete what would it look like? What would be the core things that would always be true?

SH: We should have a very detailed up to date visible set of design principles.
SH :lib-container was a clear step in the direction to facilitate abstracting low level image part of Docker and the index for example. 

## Proposal: Process Improvements

SH:
Right now there is a core group of 4: Tianon, Victor, Solomon, Michael
The authority should be explicit. Someone should be able to make a final call.

We need a "roadmap" maintainer that owns coordinating the process of design and contribution and roadmap. Does not decide what it's in the roadmap but makes sure that the roadmap is clear, on time, referencing decisions being made.

We need a maintainer that helps people help the project. Onboarding/mentoring/tools.

There should be a maintainer for tooling, even more than one person if necessary.

JB(Google) Roadmap maintainer would be very useful and document decisions via email and not IRC.
SH: Agree completely.
SH: weekly digest of key design decisions for example would be useful. This could be achievable if we had a roadmap maintainer.

BG: Docker Inc is making a large amount of resources available to make the project run well, build infrastructure,  and take care of part of "Process Improvements". These resources are largely autonomous, and are measured on project results, rather than Docker, Inc. results.

VL: What about having a PEP like process?
SH: we have already DEPs, we have a process like that and it's good but it's difficult for many reasons.
SH: They are going to ditch GH issues, and build a better system PEP-like. Don't create a PEP issues on GH. A proposal is a first version of the feature.
SH: Send a PR with the Docs related to the proposal and then have a conversation on the proposal.

VL 1. it's helpful to have an explicit rationale. 
VL 2. what if that change can't be adequately covered in docs?
SH: Agree and they are working on making sure there are ways to embed the rationale in PRs.
SH: Second point there should be a part of the documentation that always covers those changes, otherwise there is a lack of Architecture documentation.
SH: Notion of merge not as implementation merge but as "Approving proposal" merge. They need ways to distinguish those two. Allows people to be involved in the design process.
SH: You have an idea, start a PR changing the docs and then we'll have a process to drive that change through.

BG: Safety valve to prevent influence from Docker Inc.
BG: Will tackle incorporate concerns about separating Docker the project and Docker Inc.

## Governance Overview

BG walks through the overview.

## Docker Project Core

BG: walks through the overview. They are creating a "Team Meta", separate team from Docker Inc.
JB (Google): would like a different naming to differentiate the open source project and the commercial entity.
VL: That would be a great idea. It's great for trademark protection too.
BG: Docker Inc. will protect the Open Source Docker trademark from abuse.
VL: Some of the CI could be done in collaboration with the community. The community could run a build farm.
SH: The project itself could make those decisions. As employee of "Team Meta" you'll be evaluated on your contribution to the Open Source project and nothing else.

## Functional Diagram

## Team Meta

## Statement Direction and Long Term Roadmap

SH: A lot of it is driven by proposals. A lot of the design is in reaction to proposals. Today you have to go to the proposals and look for comments by me.The Networking design is now loosely known as "links v2", making it more dynamic more IP centric.  

BB: You provide a free service now you get to monetize it. How is dockerhub tied into these levels, networking/compositing/orchestrating?

SH: We're pushing towards a design where you CAN change the default registry. It should be possible not to use DockerHub even though it could help there. There needs to be a pluggable backend interface. There should be network drivers, discovery drivers, clustering drivers. Those should not be token drivers but real fully fledged solutions. 

XX: Some of these services might rely on a free service. What if someone offers the same registry for free or what if you guys start charging for it?

SH: Docker specific introspection APIs will happen. Applications should only rely on Docker the engine and never rely on DockerHub. DockerHub should be a pluggable backend that you can replace with something else. The same will happen for networking, service discovery etc.

JB(Google): Do you think there is an opportunity to expose Compute Engine VM? We serve authentication tokens without having to distribute secrets. We would love to be more nuanced to expose that to Docker. Do you think there is room to expose services inside the Docker engine? 

SH: The answer is kind of organic. Just because you run an application inside Docker the application is free do decide its dependency.

JB (Google): Another example name resolution. What if we want to provided enhanced locality aware name resolutions?
SH: To some degree it is not up to me what applications do with Docker.
SH: If you want to do today multi-host resolution you can't because it does not exist. Some people use the ambassador pattern but it's not a great experience.
SH: To some degree we don't have a saying in what applications want to do.
SH: But you might be able to replace transparently parts of the low level system like the name resolution system. If it does not fit your needs you can always explicitly roll your own. 

JB(Google): The devil is in the details. Docker core open source apis ... (NOTE TAKER NOTE: need help here...)
SH: Ideally the core will be if the APIs are good enough  they will allow this service extension.
SH: You want the benefits of an abstraction but if you go too high level you lose its utility and you have to start adding special cases.
SH: The fact that your application takes advantage of this Google service and that particular Zookeper server discovery implementation, [...] at some point you have an inception moment where you always have a way to make your service shine through. The value add part is encapsulated in your code anyway.

## Storage

DW network shared objects are 

## Microsoft Windows

DW: Concern is is the CLI going to be the same?
SH: No decision has been made. But we are not going to extend the service area if it will mean lowering the quality of the Linux version. We didn't commit to shipping anything.
VL: Rackspace would like to step in and help because this cross operating system capability is very very interesting to us.
SH: Every development on our list will go through the same process as before. If Rackspace engineers want to contribute to the Windows effort, they should be able to learn the process and same level of access as Microsoft engineers. None of that work is happening behind closed doors.
SH: Microsoft from now on has to show up on our public forums there is no back channel. They have no more rights than anybody else.

## Provenance

SH: Why can't I sign my own images? 
SH: Explanation of how it works currently: [When you docker pull an official image, that calls a separate code path which triggers a verification of the signature....] and the complexity of the issue is huge (NOTE TAKER NOTE: need help here...). The intent is to progress to a point where individuals can sign their own images. This is simply a matter of sequencing.
SH: so we have started from the verification bit.
SH: Tianon is the maintainer of the Docker Library
SH: Docker 1.4 will have the signing piece in place. We'll need a key management bit: "Docker key add" and all those commands
SH: You should be able to use your own CA. And you should be able to avoid CA all together.
SH: They are thinking of reserving 'local' (as IP 127.0.0.1 in concept) and it's completely configurable.
Less centralisation. Enforcing of namespace through crypto.

## Plugin API

JB(Google): Will these plugins out of process or compiled in? How do you maintain them?
SH: The more is in the plugins the happier I am. Including the default batteries included Docker.
SH: We want a really thin core with a small selection of disabled by default plugins. Non controversial.
SH: We don't want an ever expanding list of included plugins.
SH: A basic solid curated set of bundled in plugins.
SH: Expanding universe of out of process plugins.

JB(Google): Plugins to surface new API? volume storage driver for example I need special options...
SH: Yes absolutely in an hypothetical future api.
SH: I like a command oriented model.

## Multi-Architecture Support

Tianon: There are a lot of Arm images on the Hub
BB: How are decisions are being made related to this?
SH: Start from the design proposal and a roadmap maintainer will keep track of decisions.

BP (CoreOS): Adding removing keys should be done before anybody can launch anything
JB(Google): might be time for a docker.conf?
SH: I like the command oriented model. Listening on a given port for the API is a command.
SH: THere is an ongoing redesign.

BB: Can we have a priority list? All of these things are amazing.
VL: One of the proposals is about asynchronous communication. How does get slotted into priorities?
SH: Project maintainers are reactive. What they work on is based on what patches are being sent. Will provenance come first? That depends on how many people contribute to which. A part of it is outside of the maintainers hands. If I publish a list of priorities some of it will be misleading.
SH: Roadmap maintainer role is the person that should refine and publish this list of priorities with all its nuances.

DW I'd like to see something related to role based access. I only want to be allowing starting and stopping a container.
SH: lib-trust guys are working to use the same key management system used to sign images to also be used to enable authentication by default across the board. And then the daemon will look the public keys and make that mandatory.
JB(Google): would like to see that pluggable because it's very complex and nuanced.
SH Agree.
ACTION: Docker project to prepare a list of priorities and showing where design proposals exist (if any) to address those priorities

## Elect Chair and Vice Chair

Ballots are casted for Chair position: 
- Van Lindberg: 8
- Brandon Philips: 5
- IBM: 1

Chair elected is Van Lindberg.
Vice Chair is Brandon.

ACTION: Van Lindberg to finalize minutes, schedule next meeting
ACTION: By Monday, all items from meeting (including minutes) will be published
ACTION: Nicola to produce gues blog post on DGAB

Test for Nicola.