Register new project "vmtp" into Docker Hub

[yicwang]

Register new project "vmtp" into Docker Hub

[tianon]

Can you provide a bit more information about what VMTP is and why it's a good candidate for the official images? It seems like it solves a very, very specific niche, and an OpenStack specific one at that.

I'm also very concerned about the age of the project -- why not start with an automated build for now, so that you can work out all the kinks in a way that gives you the flexibility to change things around without formal review?

[ahothan]

I am curious to know what the criteria are for being an official image in Docker Hub as this does not seem to be documented anywhere. Do you avoid having too domain specific official images (and that can sometimes be very subjective).
Our main rationale for being an official image is to allow other people to load our image without having a user id attached to it (johndoe/ubuntu).
Or are you suggesting we should create a dummy userid (e.g. ubuntu/ubuntu)?
For now we can use automated builds but would appreciate your comment for the above question.

[ahothan]

FYI this component has been incubating at Cisco for almost a year with over 300 commits, so what you see in Github is only the tail of the commit history.

[md5]

What would be wrong with using cisco/vmtp? It looks like someone at Cisco has already registered the cisco username/organization on Docker Hub: https://registry.hub.docker.com/repos/cisco/

[tianon]

Indeed, avoiding "some random user" is exactly what organizations are for -- see https://docs.docker.com/docker-hub/accounts/#organizations-groups for more information.

[ahothan]

Mike,

That would be fine I guess but the whole point about going to Stackforge is that this tool ultimately becomes truly open source and no longer associated to any vendor. It is currently used by other people than Cisco and it is irritating they have to stick my username in front of the image name to do so today.
I think sticking a vendor name will not encourage adoption by other vendors. So we may end playing the game of wording and maybe use "stackforge/vmtp" but then who should owns the "stackforge" ID in DockerHub? Are the Stackforge folks even interested to get into DockerHub like this? I do not even know who owns the "cisco" user ID , especially when there is zero repositories associated to it (there are 70,000 employees at Cisco).
I think this is a more profound problem for the DockerHub ecosystem, how do you address the situation of many similar open source projects that are domain specific but can potentially be used by lots of other people. You'd' have to admit that forcing a userID in front of an image name is not always best. And having a vendor name is not terribly practical as well.
If the plan is to limit the number of official images in DockerHub for whatever reason (disk space, CPU or funding) then I'm totally fine with it but it would be nice to clarify the message to avoid frustration.
For now we'll use automated builds, until this is sorted out (or not).

Thanks

Alec

From: Mike Dillon <notifications@github.commailto:notifications@github.com>
Reply-To: docker-library/official-images <reply@reply.github.commailto:reply@reply.github.com>
Date: Monday, February 23, 2015 at 7:07 PM
To: docker-library/official-images <official-images@noreply.github.commailto:official-images@noreply.github.com>
Cc: Alec Hothan <ahothan@cisco.commailto:ahothan@cisco.com>
Subject: Re: [official-images] Register new project "vmtp" into Docker Hub (#517)

What would be wrong with using cisco/vmtp? It looks like someone at Cisco has already registered the Docker Hub username/organization: https://registry.hub.docker.com/repos/cisco/

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/517#issuecomment-75690527.

[psftw]

@ahothan Thank you very much for the great feedback. Hopefully my comments will address your concerns, even if my conclusion is to not recommend vmtp becoming an Official Repo. Full disclosure: I work for Docker, Inc and respond to all of the partners@docker.com emails related to Official Repos. Most of the time, my role is to 1. briefly review the Dockerfile, 2. check identity of who proposed it, and potential licensing issues 3. see if there are potential business relationships that should be explored, 4. provide suggestions and offer any assistance with the process for those that may not want to jump into our IRC channel or engage on GitHub right away. Ultimately, it is @tianon (and his amazing team) who have the final say in the matter since they are responsible for the actual execution of the program, which is a big commitment.

I am curious to know what the criteria are for being an official image in Docker Hub as this does not seem to be documented anywhere. Do you avoid having too domain specific official images (and that can sometimes be very subjective).

It is worth taking a step back to see how the Official Repos program has evolved over time, before responding directly: Since the early days of Docker as an open source project, it has been important to provide some key base images for users so that they don't need to build their own from a blank slate. Back in June of 2014 when DockerHub and Official Repos were announced, there were only about a dozen or so available, representing the most important base images such as debian, ubuntu, centos, and popular data stores such as redis and mongo. These had already existed in DockerHub for some time, but now there was an "Official Repos" program designed to get more people in the community involved, and the relationship with @tianon and his team was solidified such that they could sustain a dedicated effort on it. Later on in Sept. 2014, a big push was made to add common programming language stacks which have been wildly popular. I think there is now a good comparison between DockerHub Official Repos and what is offered in a traditional PaaS, and as we are pushing past 65 in number, a non-Docker PaaS is looking more and more restrictive in comparison.
We are still figuring out where to draw the line on what is accepted as an Official Repo and what isn't. There will always be a strict set of objective requirements for quality, which are mostly codified in the docs. Since packing software into a Docker image is frankly an art form, it's impossible to have completely objective requirements. So far we've done our best to strike a balance that leans towards objectivity, and have accepted some quite domain-specific repos (i.e. odoo or sentry come to mind). We've also rejected some such as datadog due to requiring a --privileged flag in order to function. More recently, we've seen a number of new requests such as vmtp, biicode and others in the pre-PR phase, which are very domain specific or heavily tied to a particular service provider/platform. I've been thinking about this and what kind of policy we should shoot for. Yes, you are correct that the documentation isn't clear and there will need to be some kind of subjectivity to it. I would prefer to err on the side of saying "No" to more proposals, and following up with documentation improvements.

In the case of vmtp, I think this would be a good image for an automated build, since it is a tool for a very specific task. In my mind, not a lot of people are in the market for an OpenStack performance testing tool, even though I think this is a really cool creation and I'll probably use it at some point myself. I agree that publishing the image under a particular user's namespace does not make sense here because it is a larger project maintained by a team and the open community now. I would suggest you check with other Stackforge projects to see if an organization could be created and shared among members who are interested in publishing Docker images. I can assure you that the reasoning for restricting the set of Official Repos has nothing to do with the underlying technology -- DockerHub operates at huge scale today.

Hopefully the above gives you a sense of where I'm coming from and we will definitely have more explicit documentation on what will be accepted once we've sorted it all out. I should also note that we (Docker, Inc) are in the process of hiring someone to help run this program and be responsible for helping us figure out issues like this and communicate better. Helping out with the program up to this point has only been one part of my responsibilities.

Thank you for understanding. I would be curious to get your take on the documentation after we've taken a pass to revamp it to address your (and other) concerns that have come up recently.

[daghack]

I'm going to go ahead and close this. If anything changes, we can reopen as needed.