On Sun, Aug 28, 2016 at 9:28 PM, Mike Jumper <mike.jum...@guac-dev.org> wrote:
>
> On Sun, Aug 28, 2016 at 6:49 PM, Mike Jumper <mike.jum...@guac-dev.org> wrote:
> > On Aug 28, 2016 5:58 PM, "Roman Shaposhnik" <ro...@shaposhnik.org> wrote:
> >>
> >> First of all, the way apache org is setup on GitHub make me 99% sure
> >> that the only artifacts allowed there would be release ones.
> >>
> >> If we agree on that, I see no problem with
> >> apache/incubator-foo
> >> naming of your *released* Docker images.
> >>
> >
> > I definitely have no problem with adopting a "incubator-" prefix in
> > principle.
> >
> > That said, released Maven artifacts for incubating projects are normally
> > named without the "incubator-" prefix, instead requiring "-incubating" as a
> > suffix for the version of the artifact.
> >
> > Would that convention make sense here as well, with the incubating status
> > being given via the Docker image tag?
> >
> > ie:
> >
> > apache/foo:0.1.0-incubating
> >
> > rather than:
> >
> > apache/incubator-foo:0.1.0
> >
> > ?
> >
> >> Note that there was a separate discussion focused on where is the right
> >> place for nightly/snapshot Docker builds to be deposited to.
> >>
> >> Sadly, that discussion bore no fruit :-(
> >>
> >
> > That is unfortunate. Perhaps this one will?
> >
> > The Incubator's release management guide has recommendations for version
> > numbering of non-release artifacts:
> >
> > http://incubator.apache.org/guides/releasemanagement.html#notes-numbering-between-releases
> >
> > Given that, wouldn't some explicit snapshot naming for the image tag be
> > sufficient for non-release automated builds from git?
> >
> > I'd even argue that Docker Hub's automated build system is a third party
> > hosted CI, and that images produced through that system are no more
> > inherently release-specific than the artifacts of a Jenkins build. Release
> > vs. non-release should be declared through image tags, not its presence on
> > Docker Hub alone.
> >
> > - Mike
>
> Scrounging around for precedent, and assuming that not all ASF
> projects are under "apache/*" due to the relative lack of activity, I
> have found at least:
>
> https://hub.docker.com/r/cloudstack/cloudstack-cloudmonkey/
>
> Which is a project-specific Docker Hub organization ("cloudstack") for
> Apache Cloudstack which builds against the Apache GitHub mirror
> (https://github.com/apache/cloudstack-cloudmonkey). The image has only
> the "latest" tag, and after looking through the Dockerfile, it is
> written to simply build itself against the latest git.
>
> Setting up the linkage between the "cloudstack" organization and the
> Apache GitHub mirror must have involved intervention from Infra.
> Searching through JIRA, I've found that, too:
>
> https://issues.apache.org/jira/browse/INFRA-9915
>
> That isn't an incubating project, of course, and examples of practice
> can't be assumed to be examples of *good* practice or of policy, but
> it does seem that project-specific Docker Hub organizations for
> projects under the ASF are at least possible and arguably beneficial.
>
> What about doing similar with an incubating project?
>
> Specifically:
>
> 1) Using a project-specific organization of which Infra is a member.
> 2) Not using the "incubator-" prefix for the organization or image
> names, for compatibility's sake.
> 3) Using the "-incubating" suffix in the tags of images of releases
> while the project is incubating.
>
> Thanks,
>
> - Mike
All, setting aside the Docker Hub vs. Apache-hosted hub vs. bintray
discussion for the moment, are there any specific opinions regarding
the original issue: the actual namespacing of the podling images
themselves?
It seems we, Apache Guacamole (incubating), have three possible
choices for the images related to a release. Again, we have two
specific applications within the Guacamole project as a whole which
have their own images: "guacamole", the web application, and "guacd",
the backend daemon with which it communicates.
(A)
apache/incubator-guacamole:0.9.10-incubating
apache/incubator-guacd:0.9.10-incubating
- Seems redundant (incubator, incubating), graduation would break
compatibility (see Maven best practices [1])
- "Apache Guacd" is not an incubating project, thus perhaps
apache/incubator-guacd is problematic
(B)
apache/guacamole:0.9.10-incubating
apache/guacd:0.9.10-incubating
- Less redundant, better compatibility with future
- Again, "Apache Guacd" is not its own project. Not sure if this
is a problem.
(C)
guacamole/guacamole:0.9.10-incubating
guacamole/guacd:0.9.10-incubating
- Lacks the issues related to A and B above, but does not
explicitly say "Apache"
For projects with a single self-named image, this all seems
straightforward, but I would really like to iron out the details for
the sake of our multi-image project, especially since only one of
those images is self-named.
With image coordinates being organization, name, and tag, I personally
like the Maven-like mapping of C above (seems analogous to groupId,
artifactId, and version), but the lack of "Apache" is an obvious
issue. Maven groupIds for ASF projects start with "org.apache", but
Docker Hub's size and content limitations for organization names would
prevent such things.
Thanks,
- Mike
[1] http://incubator.apache.org/guides/release-java.html#best-practice-maven
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
