You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Mike Jumper <mi...@guac-dev.org> on 2016/08/28 23:21:07 UTC
Namespacing of subproject Docker images vs. Incubator policy
Hello all,
We, Apache Guacamole (incubating), would like to migrate our project's
Docker images to something beneath the ASF, but I am unsure how to
proceed, nor the form that this migration would best take.
We currently have two repositories which provide Docker images:
incubator-guacamole-client [1] and incubator-guacamole-server [2].
Prior to acceptance into the Apache Incubator, these repositories were
used to produce the "glyptodon/guacamole" [3] and "glyptodon/guacd"
[4] images respectively.
As there is already an "apache/*" organization defined at Docker Hub
(albeit a virtual desert) [5] and there was positive discussion
regarding including the images of incubating projects under that
organization [6], it seems that would be the logical and
straightforward choice ... but because one of those images ("guacd")
would not be namespaced by the project's own name, I'm unsure if this
is actually possible/allowed.
Ideally we would end up with a mapping like:
incubator-guacamole-client -> apache/guacamole
incubator-guacamole-server -> apache/guacd
Or, since we're incubating, perhaps:
incubator-guacamole-client -> apache/incubator-guacamole
incubator-guacamole-server -> apache/incubator-guacd
But again, I'm not sure if "apache/incubator-guacd" would be a
violation of policy.
Alternatively, a cleaner approach could be to define a Docker Hub
organization specific to the project, as that would provide a nice
analogy to the project/subproject relationship that exists between
Apache Guacamole the "guacamole" and "guacd" applications:
incubator-guacamole-client -> guacamole/guacamole
incubator-guacamole-server -> guacamole/guacd
But I'm not sure if THAT would be a violation of policy. Further,
after creating exactly such an organization for the sake of testing,
I've found that I can't set up the necessary linkage for enabling
automatic builds (the organization would need to be owned by a user
with sufficient access rights to the Apache GitHub mirrors).
Any suggestions?
Thanks,
- Mike
[1] https://github.com/apache/incubator-guacamole-client
[2] https://github.com/apache/incubator-guacamole-server
[3] https://hub.docker.com/r/glyptodon/guacamole/
[4] https://hub.docker.com/r/glyptodon/guacd/
[5] https://hub.docker.com/r/apache/
[6] http://mail-archives.apache.org/mod_mbox/incubator-general/201604.mbox/%3CCANyrgvfAWifLkkvAccAV22Q9uyo8g3so=BJ0JFZ8oV16Bt=kzQ@mail.gmail.com%3E
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Namespacing of subproject Docker images vs. Incubator policy
Posted by Jochen Theodorou <bl...@gmx.org>.
thx
On 01.09.2016 21:04, John D. Ament wrote:
> Reach out to infra. You can create a JIRA ticket.
>
> John
>
> On Thu, Sep 1, 2016 at 2:52 PM Jochen Theodorou <bl...@gmx.org> wrote:
>
>> Only partially related to the namespacing problem...
>>
>> But does somebody here know who to contact if I wanted to have a docker
>> image on https://hub.docker.com/u/apache/ ?
>>
>> bye Jochen
>>
>> On 29.08.2016 01:21, Mike Jumper wrote:
>>> Hello all,
>>>
>>> We, Apache Guacamole (incubating), would like to migrate our project's
>>> Docker images to something beneath the ASF, but I am unsure how to
>>> proceed, nor the form that this migration would best take.
>>>
>>> We currently have two repositories which provide Docker images:
>>> incubator-guacamole-client [1] and incubator-guacamole-server [2].
>>> Prior to acceptance into the Apache Incubator, these repositories were
>>> used to produce the "glyptodon/guacamole" [3] and "glyptodon/guacd"
>>> [4] images respectively.
>>>
>>> As there is already an "apache/*" organization defined at Docker Hub
>>> (albeit a virtual desert) [5] and there was positive discussion
>>> regarding including the images of incubating projects under that
>>> organization [6], it seems that would be the logical and
>>> straightforward choice ... but because one of those images ("guacd")
>>> would not be namespaced by the project's own name, I'm unsure if this
>>> is actually possible/allowed.
>>>
>>> Ideally we would end up with a mapping like:
>>>
>>> incubator-guacamole-client -> apache/guacamole
>>> incubator-guacamole-server -> apache/guacd
>>>
>>> Or, since we're incubating, perhaps:
>>>
>>> incubator-guacamole-client -> apache/incubator-guacamole
>>> incubator-guacamole-server -> apache/incubator-guacd
>>>
>>> But again, I'm not sure if "apache/incubator-guacd" would be a
>>> violation of policy.
>>>
>>> Alternatively, a cleaner approach could be to define a Docker Hub
>>> organization specific to the project, as that would provide a nice
>>> analogy to the project/subproject relationship that exists between
>>> Apache Guacamole the "guacamole" and "guacd" applications:
>>>
>>> incubator-guacamole-client -> guacamole/guacamole
>>> incubator-guacamole-server -> guacamole/guacd
>>>
>>> But I'm not sure if THAT would be a violation of policy. Further,
>>> after creating exactly such an organization for the sake of testing,
>>> I've found that I can't set up the necessary linkage for enabling
>>> automatic builds (the organization would need to be owned by a user
>>> with sufficient access rights to the Apache GitHub mirrors).
>>>
>>> Any suggestions?
>>>
>>> Thanks,
>>>
>>> - Mike
>>>
>>> [1] https://github.com/apache/incubator-guacamole-client
>>> [2] https://github.com/apache/incubator-guacamole-server
>>> [3] https://hub.docker.com/r/glyptodon/guacamole/
>>> [4] https://hub.docker.com/r/glyptodon/guacd/
>>> [5] https://hub.docker.com/r/apache/
>>> [6]
>> http://mail-archives.apache.org/mod_mbox/incubator-general/201604.mbox/%3CCANyrgvfAWifLkkvAccAV22Q9uyo8g3so=BJ0JFZ8oV16Bt=kzQ@mail.gmail.com%3E
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Namespacing of subproject Docker images vs. Incubator policy
Posted by "John D. Ament" <jo...@apache.org>.
Reach out to infra. You can create a JIRA ticket.
John
On Thu, Sep 1, 2016 at 2:52 PM Jochen Theodorou <bl...@gmx.org> wrote:
> Only partially related to the namespacing problem...
>
> But does somebody here know who to contact if I wanted to have a docker
> image on https://hub.docker.com/u/apache/ ?
>
> bye Jochen
>
> On 29.08.2016 01:21, Mike Jumper wrote:
> > Hello all,
> >
> > We, Apache Guacamole (incubating), would like to migrate our project's
> > Docker images to something beneath the ASF, but I am unsure how to
> > proceed, nor the form that this migration would best take.
> >
> > We currently have two repositories which provide Docker images:
> > incubator-guacamole-client [1] and incubator-guacamole-server [2].
> > Prior to acceptance into the Apache Incubator, these repositories were
> > used to produce the "glyptodon/guacamole" [3] and "glyptodon/guacd"
> > [4] images respectively.
> >
> > As there is already an "apache/*" organization defined at Docker Hub
> > (albeit a virtual desert) [5] and there was positive discussion
> > regarding including the images of incubating projects under that
> > organization [6], it seems that would be the logical and
> > straightforward choice ... but because one of those images ("guacd")
> > would not be namespaced by the project's own name, I'm unsure if this
> > is actually possible/allowed.
> >
> > Ideally we would end up with a mapping like:
> >
> > incubator-guacamole-client -> apache/guacamole
> > incubator-guacamole-server -> apache/guacd
> >
> > Or, since we're incubating, perhaps:
> >
> > incubator-guacamole-client -> apache/incubator-guacamole
> > incubator-guacamole-server -> apache/incubator-guacd
> >
> > But again, I'm not sure if "apache/incubator-guacd" would be a
> > violation of policy.
> >
> > Alternatively, a cleaner approach could be to define a Docker Hub
> > organization specific to the project, as that would provide a nice
> > analogy to the project/subproject relationship that exists between
> > Apache Guacamole the "guacamole" and "guacd" applications:
> >
> > incubator-guacamole-client -> guacamole/guacamole
> > incubator-guacamole-server -> guacamole/guacd
> >
> > But I'm not sure if THAT would be a violation of policy. Further,
> > after creating exactly such an organization for the sake of testing,
> > I've found that I can't set up the necessary linkage for enabling
> > automatic builds (the organization would need to be owned by a user
> > with sufficient access rights to the Apache GitHub mirrors).
> >
> > Any suggestions?
> >
> > Thanks,
> >
> > - Mike
> >
> > [1] https://github.com/apache/incubator-guacamole-client
> > [2] https://github.com/apache/incubator-guacamole-server
> > [3] https://hub.docker.com/r/glyptodon/guacamole/
> > [4] https://hub.docker.com/r/glyptodon/guacd/
> > [5] https://hub.docker.com/r/apache/
> > [6]
> http://mail-archives.apache.org/mod_mbox/incubator-general/201604.mbox/%3CCANyrgvfAWifLkkvAccAV22Q9uyo8g3so=BJ0JFZ8oV16Bt=kzQ@mail.gmail.com%3E
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Namespacing of subproject Docker images vs. Incubator policy
Posted by Jochen Theodorou <bl...@gmx.org>.
Only partially related to the namespacing problem...
But does somebody here know who to contact if I wanted to have a docker
image on https://hub.docker.com/u/apache/ ?
bye Jochen
On 29.08.2016 01:21, Mike Jumper wrote:
> Hello all,
>
> We, Apache Guacamole (incubating), would like to migrate our project's
> Docker images to something beneath the ASF, but I am unsure how to
> proceed, nor the form that this migration would best take.
>
> We currently have two repositories which provide Docker images:
> incubator-guacamole-client [1] and incubator-guacamole-server [2].
> Prior to acceptance into the Apache Incubator, these repositories were
> used to produce the "glyptodon/guacamole" [3] and "glyptodon/guacd"
> [4] images respectively.
>
> As there is already an "apache/*" organization defined at Docker Hub
> (albeit a virtual desert) [5] and there was positive discussion
> regarding including the images of incubating projects under that
> organization [6], it seems that would be the logical and
> straightforward choice ... but because one of those images ("guacd")
> would not be namespaced by the project's own name, I'm unsure if this
> is actually possible/allowed.
>
> Ideally we would end up with a mapping like:
>
> incubator-guacamole-client -> apache/guacamole
> incubator-guacamole-server -> apache/guacd
>
> Or, since we're incubating, perhaps:
>
> incubator-guacamole-client -> apache/incubator-guacamole
> incubator-guacamole-server -> apache/incubator-guacd
>
> But again, I'm not sure if "apache/incubator-guacd" would be a
> violation of policy.
>
> Alternatively, a cleaner approach could be to define a Docker Hub
> organization specific to the project, as that would provide a nice
> analogy to the project/subproject relationship that exists between
> Apache Guacamole the "guacamole" and "guacd" applications:
>
> incubator-guacamole-client -> guacamole/guacamole
> incubator-guacamole-server -> guacamole/guacd
>
> But I'm not sure if THAT would be a violation of policy. Further,
> after creating exactly such an organization for the sake of testing,
> I've found that I can't set up the necessary linkage for enabling
> automatic builds (the organization would need to be owned by a user
> with sufficient access rights to the Apache GitHub mirrors).
>
> Any suggestions?
>
> Thanks,
>
> - Mike
>
> [1] https://github.com/apache/incubator-guacamole-client
> [2] https://github.com/apache/incubator-guacamole-server
> [3] https://hub.docker.com/r/glyptodon/guacamole/
> [4] https://hub.docker.com/r/glyptodon/guacd/
> [5] https://hub.docker.com/r/apache/
> [6] http://mail-archives.apache.org/mod_mbox/incubator-general/201604.mbox/%3CCANyrgvfAWifLkkvAccAV22Q9uyo8g3so=BJ0JFZ8oV16Bt=kzQ@mail.gmail.com%3E
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Namespacing of subproject Docker images vs. Incubator policy
Posted by Edward Capriolo <ed...@gmail.com>.
Sorry for a lazy question. Can you point me at the proces you have
ant/maven/shell/jenkins/whatever that builds the dockers. I would be
interested in seeing if I can apply that elsewhere.
On Sun, Aug 28, 2016 at 7:21 PM, Mike Jumper <mi...@guac-dev.org>
wrote:
> Hello all,
>
> We, Apache Guacamole (incubating), would like to migrate our project's
> Docker images to something beneath the ASF, but I am unsure how to
> proceed, nor the form that this migration would best take.
>
> We currently have two repositories which provide Docker images:
> incubator-guacamole-client [1] and incubator-guacamole-server [2].
> Prior to acceptance into the Apache Incubator, these repositories were
> used to produce the "glyptodon/guacamole" [3] and "glyptodon/guacd"
> [4] images respectively.
>
> As there is already an "apache/*" organization defined at Docker Hub
> (albeit a virtual desert) [5] and there was positive discussion
> regarding including the images of incubating projects under that
> organization [6], it seems that would be the logical and
> straightforward choice ... but because one of those images ("guacd")
> would not be namespaced by the project's own name, I'm unsure if this
> is actually possible/allowed.
>
> Ideally we would end up with a mapping like:
>
> incubator-guacamole-client -> apache/guacamole
> incubator-guacamole-server -> apache/guacd
>
> Or, since we're incubating, perhaps:
>
> incubator-guacamole-client -> apache/incubator-guacamole
> incubator-guacamole-server -> apache/incubator-guacd
>
> But again, I'm not sure if "apache/incubator-guacd" would be a
> violation of policy.
>
> Alternatively, a cleaner approach could be to define a Docker Hub
> organization specific to the project, as that would provide a nice
> analogy to the project/subproject relationship that exists between
> Apache Guacamole the "guacamole" and "guacd" applications:
>
> incubator-guacamole-client -> guacamole/guacamole
> incubator-guacamole-server -> guacamole/guacd
>
> But I'm not sure if THAT would be a violation of policy. Further,
> after creating exactly such an organization for the sake of testing,
> I've found that I can't set up the necessary linkage for enabling
> automatic builds (the organization would need to be owned by a user
> with sufficient access rights to the Apache GitHub mirrors).
>
> Any suggestions?
>
> Thanks,
>
> - Mike
>
> [1] https://github.com/apache/incubator-guacamole-client
> [2] https://github.com/apache/incubator-guacamole-server
> [3] https://hub.docker.com/r/glyptodon/guacamole/
> [4] https://hub.docker.com/r/glyptodon/guacd/
> [5] https://hub.docker.com/r/apache/
> [6] http://mail-archives.apache.org/mod_mbox/incubator-
> general/201604.mbox/%3CCANyrgvfAWifLkkvAccAV22Q9uyo
> 8g3so=BJ0JFZ8oV16Bt=kzQ@mail.gmail.com%3E
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Namespacing of subproject Docker images vs. Incubator policy
Posted by "John D. Ament" <jo...@apache.org>.
On Mon, Aug 29, 2016 at 11:30 AM Roman Shaposhnik <ro...@shaposhnik.org>
wrote:
> On Sun, Aug 28, 2016 at 6:28 PM, John D. Ament <jo...@apache.org>
> wrote:
> > On Sun, Aug 28, 2016 at 8: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.
> >>
> >
> > There is from an eventually a TLP stand point. apache/guacd and
> > apache/incubator-guacd are not the same. I wouldn't be able to migrate
> an
> > instance from one to the other. I'd actually recommend the incubating
> part
> > in the version #, similar to what we do for most other artifacts, so that
> > it becomes apache/guacd/1.0.0-incubating
>
> Sure. I was just commenting on the Mike's point of naming an artifact
> with a prefix (which WILL be the most clear way to designate an
> incubating project). That said version should be borderline OK too,
> but I'd like others to chime in first. My problem with version/tag is that
> Docker workflow hides it pretty well for most of the default use cases.
> Thus the notion of advertising an incubation status *may* be not as
> strongly present.
>
>
Well, ok, yes, add a prefix makes it clearer. However, our requirement
today in the incubator is to add -incubating in the source release
artifact. Maven projects have adopted making it part of their version.
i'd be curious why that pattern isn't continued forward here.
> >> 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 :-(
> >>
> >
> > Was there? I would love to get discussing about that. Not for an
> > incubating project but for a TLP. I share concerns about "latest" but
> > also see benefit to developers being able to use a "LATEST" tagged
> > pre-release.
>
> There was:
> https://mail-search.apache.org/members/private-arch/infrastructure/201608.mbox/%3CCA+DCeTG4=yrG8aoj=rvu8o71vjMeUtNDd5cyJKXiaLktxwTBGQ@mail.gmail.com%3E
>
> FWIW, I say that we should just adopt a repository.apache.org approach
> and declare that nightly/snapshot Docker images can only be distributed
> from our own Docker repo. That way there's absolutely 0 chance anybody
> can get them by accident.
>
>
Yes, exactly. Since you can override your dockerhub url, you can point to
our private hub on bintray (at least the marketing makes it sound like that
works). As long as upstream syncing isn't enabled, that would be awesome
to try out.
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Namespacing of subproject Docker images vs. Incubator policy
Posted by Mike Jumper <mi...@guac-dev.org>.
On Aug 29, 2016 8:30 AM, "Roman Shaposhnik" <ro...@shaposhnik.org> wrote:
>
> ...
> >> 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 :-(
> >>
> >
> > Was there? I would love to get discussing about that. Not for an
> > incubating project but for a TLP. I share concerns about "latest" but
> > also see benefit to developers being able to use a "LATEST" tagged
> > pre-release.
>
> There was:
https://mail-search.apache.org/members/private-arch/infrastructure/201608.mbox/%3CCA+DCeTG4=yrG8aoj=rvu8o71vjMeUtNDd5cyJKXiaLktxwTBGQ@mail.gmail.com%3E
>
> FWIW, I say that we should just adopt a repository.apache.org approach
> and declare that nightly/snapshot Docker images can only be distributed
> from our own Docker repo. That way there's absolutely 0 chance anybody
> can get them by accident.
>
If the "latest" tag points only to releases, then that would take care of
this as well.
If only a specific "snapshot" tag ever points to snapshot images, then
getting them would require:
$ sudo docker pull foo:snapshot
Zero chance of a user typing that by accident as well.
- Mike
Re: Namespacing of subproject Docker images vs. Incubator policy
Posted by "John D. Ament" <jo...@apache.org>.
Jake,
I"m definitely interested in hearing more. I've been off and on trying to
get ActiveMQ Artemis builds up on docker. I haven't gotten quite enough of
an answer from infra, and don't know enough myself to get it working right.
I suspect, from my own artifactory experience, the bintray experience is
going to be easier. Do we have docs anywhere that point to how to build?
John
On Mon, Aug 29, 2016 at 3:53 PM Jake Farrell <jf...@apache.org> wrote:
> We have our own docker registry available for projects to use, its hosted
> out of bintray. Access can be granted per project via an infra ticket
> request.
>
> Dockerhub is used in an automated builds capacity, we can set it to only
> build tagged versions.
>
> Happy to answer any questions about either offering
>
> -Jake
>
>
> On Mon, Aug 29, 2016 at 3:27 PM, Marvin Humphrey <ma...@rectangular.com>
> wrote:
>
> > On Mon, Aug 29, 2016 at 8:30 AM, Roman Shaposhnik <ro...@shaposhnik.org>
> > wrote:
> >
> > > FWIW, I say that we should just adopt a repository.apache.org approach
> > > and declare that nightly/snapshot Docker images can only be distributed
> > > from our own Docker repo. That way there's absolutely 0 chance anybody
> > > can get them by accident.
> >
> > Running our own hub a la repository.apache.org would address the
> concerns
> > about distributing unreleased materials outside the development
> > community. It
> > sounds like a worthwhile Infra feature request. +1
> >
> > Having `latest` on the central dockerhub point derive from the last
> > official release sounds like a good move, regardless.
> >
> > For background:
> >
> > http://www.apache.org/legal/release-policy#release-definition
> > http://www.apache.org/legal/release-policy#publication
> >
> > Marvin Humphrey
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
Re: Namespacing of subproject Docker images vs. Incubator policy
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Mon, Aug 29, 2016 at 12:53 PM, Jake Farrell <jf...@apache.org> wrote:
> We have our own docker registry available for projects to use, its hosted
> out of bintray. Access can be granted per project via an infra ticket
> request.
>
> Dockerhub is used in an automated builds capacity, we can set it to only
> build tagged versions.
>
> Happy to answer any questions about either offering.
On the other thread, it was suggested that the Bintray Docker stuff was only
for public releases. Is that not the case? Is it already set up like
repository.apache.org as suggested upthread?
On the other hand, if I type `docker pull apache/nutch` or `docker pull
apache/thrift`, I get unreleased `master`, which is a problem.
Docker images of official releases for distribution to the general public are
an unalloyed good. Docker images of unreleased builds are a nice convenience
for our dev communities, but distribution must be fenced off and outsiders
pointed towards official releases.
It would be great if there can be a strong division between hub.docker.com for
public images and something analogous to repository.apache.org on Bintray or
elsewhere for private builds.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Namespacing of subproject Docker images vs. Incubator policy
Posted by Jake Farrell <jf...@apache.org>.
We have our own docker registry available for projects to use, its hosted
out of bintray. Access can be granted per project via an infra ticket
request.
Dockerhub is used in an automated builds capacity, we can set it to only
build tagged versions.
Happy to answer any questions about either offering
-Jake
On Mon, Aug 29, 2016 at 3:27 PM, Marvin Humphrey <ma...@rectangular.com>
wrote:
> On Mon, Aug 29, 2016 at 8:30 AM, Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
>
> > FWIW, I say that we should just adopt a repository.apache.org approach
> > and declare that nightly/snapshot Docker images can only be distributed
> > from our own Docker repo. That way there's absolutely 0 chance anybody
> > can get them by accident.
>
> Running our own hub a la repository.apache.org would address the concerns
> about distributing unreleased materials outside the development
> community. It
> sounds like a worthwhile Infra feature request. +1
>
> Having `latest` on the central dockerhub point derive from the last
> official release sounds like a good move, regardless.
>
> For background:
>
> http://www.apache.org/legal/release-policy#release-definition
> http://www.apache.org/legal/release-policy#publication
>
> Marvin Humphrey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Namespacing of subproject Docker images vs. Incubator policy
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Mon, Aug 29, 2016 at 8:30 AM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> FWIW, I say that we should just adopt a repository.apache.org approach
> and declare that nightly/snapshot Docker images can only be distributed
> from our own Docker repo. That way there's absolutely 0 chance anybody
> can get them by accident.
Running our own hub a la repository.apache.org would address the concerns
about distributing unreleased materials outside the development community. It
sounds like a worthwhile Infra feature request. +1
Having `latest` on the central dockerhub point derive from the last
official release sounds like a good move, regardless.
For background:
http://www.apache.org/legal/release-policy#release-definition
http://www.apache.org/legal/release-policy#publication
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Namespacing of subproject Docker images vs. Incubator policy
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Sun, Aug 28, 2016 at 6:28 PM, John D. Ament <jo...@apache.org> wrote:
> On Sun, Aug 28, 2016 at 8: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.
>>
>
> There is from an eventually a TLP stand point. apache/guacd and
> apache/incubator-guacd are not the same. I wouldn't be able to migrate an
> instance from one to the other. I'd actually recommend the incubating part
> in the version #, similar to what we do for most other artifacts, so that
> it becomes apache/guacd/1.0.0-incubating
Sure. I was just commenting on the Mike's point of naming an artifact
with a prefix (which WILL be the most clear way to designate an
incubating project). That said version should be borderline OK too,
but I'd like others to chime in first. My problem with version/tag is that
Docker workflow hides it pretty well for most of the default use cases.
Thus the notion of advertising an incubation status *may* be not as
strongly present.
>> 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 :-(
>>
>
> Was there? I would love to get discussing about that. Not for an
> incubating project but for a TLP. I share concerns about "latest" but
> also see benefit to developers being able to use a "LATEST" tagged
> pre-release.
There was: https://mail-search.apache.org/members/private-arch/infrastructure/201608.mbox/%3CCA+DCeTG4=yrG8aoj=rvu8o71vjMeUtNDd5cyJKXiaLktxwTBGQ@mail.gmail.com%3E
FWIW, I say that we should just adopt a repository.apache.org approach
and declare that nightly/snapshot Docker images can only be distributed
from our own Docker repo. That way there's absolutely 0 chance anybody
can get them by accident.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Namespacing of subproject Docker images vs. Incubator policy
Posted by "John D. Ament" <jo...@apache.org>.
On Sun, Aug 28, 2016 at 8: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.
>
There is from an eventually a TLP stand point. apache/guacd and
apache/incubator-guacd are not the same. I wouldn't be able to migrate an
instance from one to the other. I'd actually recommend the incubating part
in the version #, similar to what we do for most other artifacts, so that
it becomes apache/guacd/1.0.0-incubating
>
> 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 :-(
>
Was there? I would love to get discussing about that. Not for an
incubating project but for a TLP. I share concerns about "latest" but
also see benefit to developers being able to use a "LATEST" tagged
pre-release.
>
> Thanks,
> Roman.
>
> On Sun, Aug 28, 2016 at 4:21 PM, Mike Jumper <mi...@guac-dev.org>
> wrote:
> > Hello all,
> >
> > We, Apache Guacamole (incubating), would like to migrate our project's
> > Docker images to something beneath the ASF, but I am unsure how to
> > proceed, nor the form that this migration would best take.
> >
> > We currently have two repositories which provide Docker images:
> > incubator-guacamole-client [1] and incubator-guacamole-server [2].
> > Prior to acceptance into the Apache Incubator, these repositories were
> > used to produce the "glyptodon/guacamole" [3] and "glyptodon/guacd"
> > [4] images respectively.
> >
> > As there is already an "apache/*" organization defined at Docker Hub
> > (albeit a virtual desert) [5] and there was positive discussion
> > regarding including the images of incubating projects under that
> > organization [6], it seems that would be the logical and
> > straightforward choice ... but because one of those images ("guacd")
> > would not be namespaced by the project's own name, I'm unsure if this
> > is actually possible/allowed.
> >
> > Ideally we would end up with a mapping like:
> >
> > incubator-guacamole-client -> apache/guacamole
> > incubator-guacamole-server -> apache/guacd
> >
> > Or, since we're incubating, perhaps:
> >
> > incubator-guacamole-client -> apache/incubator-guacamole
> > incubator-guacamole-server -> apache/incubator-guacd
> >
> > But again, I'm not sure if "apache/incubator-guacd" would be a
> > violation of policy.
> >
> > Alternatively, a cleaner approach could be to define a Docker Hub
> > organization specific to the project, as that would provide a nice
> > analogy to the project/subproject relationship that exists between
> > Apache Guacamole the "guacamole" and "guacd" applications:
> >
> > incubator-guacamole-client -> guacamole/guacamole
> > incubator-guacamole-server -> guacamole/guacd
> >
> > But I'm not sure if THAT would be a violation of policy. Further,
> > after creating exactly such an organization for the sake of testing,
> > I've found that I can't set up the necessary linkage for enabling
> > automatic builds (the organization would need to be owned by a user
> > with sufficient access rights to the Apache GitHub mirrors).
> >
> > Any suggestions?
> >
> > Thanks,
> >
> > - Mike
> >
> > [1] https://github.com/apache/incubator-guacamole-client
> > [2] https://github.com/apache/incubator-guacamole-server
> > [3] https://hub.docker.com/r/glyptodon/guacamole/
> > [4] https://hub.docker.com/r/glyptodon/guacd/
> > [5] https://hub.docker.com/r/apache/
> > [6]
> http://mail-archives.apache.org/mod_mbox/incubator-general/201604.mbox/%3CCANyrgvfAWifLkkvAccAV22Q9uyo8g3so=BJ0JFZ8oV16Bt=kzQ@mail.gmail.com%3E
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Namespacing of subproject Docker images vs. Incubator policy
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
See my reply to John if you're curious to know my take on both questions.
Thanks,
Roman.
On Sun, Aug 28, 2016 at 6:49 PM, Mike Jumper <mi...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Namespacing of subproject Docker images vs. Incubator policy
Posted by Mike Jumper <mi...@guac-dev.org>.
On Wed, Sep 7, 2016 at 6:31 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
> On Wed, Sep 7, 2016 at 9:44 AM, Mike Jumper <mi...@guac-dev.org> wrote:
>
>> Is the project-specific organization option not really an option at all
>> then? Frowned upon for a TLP, and not to be considered by a podling?
>
> My chief concern so far has been assuring that our nascent Infra-supported
> offerings do not conflict with policy. Now that this has been achieved (in
> planning, if not yet in implementation), it's easier to speak to your issue.
>
> The main Docker Hub at hub.docker.com is a public-facing downstream
> distribution channel -- similar to Maven Central, PyPI, Debian package
> management, etc.
>
> It is appropriate to distribute official releases through downstream channels,
> but inappropriate to distribute unreleased materials through them. (That's
> why having `latest` on hub.docker.com point to git `master` is problematic.)
> See Apache's formal Release Policy and Release Distribution Policy documents:
>
> http://www.apache.org/legal/release-policy#policy
> http://www.apache.org/dev/release-distribution#policy
>
> There are an unbounded number of such downstream channels, and there is no way
> we are going to formulate specific policies for all of them. Instead, we
> primarily rely on people respecting our trademarks: that "Apache Foo", when
> obtained from one of these channels, is what the consumer expects.
>
> http://www.apache.org/foundation/marks
>
> One implication is that if you're using the project name for that Docker
> Hub account, we'd expect the entire PMC to have access.
>
> Incubating podlings operate under additional constraints, in that the "Apache"
> brand needs to be tempered with "incubating" and appropriate disclaimers.
>
> http://incubator.apache.org/guides/branding.html
>
> But within those guidelines, the answer is: yes, go ahead. If Infra's
> offering is not to your taste, that is.
>
> Marvin Humphrey
>
Excellent. Thanks, Marvin.
This addresses absolutely all my questions quite nicely.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Namespacing of subproject Docker images vs. Incubator policy
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Wed, Sep 7, 2016 at 9:44 AM, Mike Jumper <mi...@guac-dev.org> wrote:
> Is the project-specific organization option not really an option at all
> then? Frowned upon for a TLP, and not to be considered by a podling?
My chief concern so far has been assuring that our nascent Infra-supported
offerings do not conflict with policy. Now that this has been achieved (in
planning, if not yet in implementation), it's easier to speak to your issue.
The main Docker Hub at hub.docker.com is a public-facing downstream
distribution channel -- similar to Maven Central, PyPI, Debian package
management, etc.
It is appropriate to distribute official releases through downstream channels,
but inappropriate to distribute unreleased materials through them. (That's
why having `latest` on hub.docker.com point to git `master` is problematic.)
See Apache's formal Release Policy and Release Distribution Policy documents:
http://www.apache.org/legal/release-policy#policy
http://www.apache.org/dev/release-distribution#policy
There are an unbounded number of such downstream channels, and there is no way
we are going to formulate specific policies for all of them. Instead, we
primarily rely on people respecting our trademarks: that "Apache Foo", when
obtained from one of these channels, is what the consumer expects.
http://www.apache.org/foundation/marks
One implication is that if you're using the project name for that Docker
Hub account, we'd expect the entire PMC to have access.
Incubating podlings operate under additional constraints, in that the "Apache"
brand needs to be tempered with "incubating" and appropriate disclaimers.
http://incubator.apache.org/guides/branding.html
But within those guidelines, the answer is: yes, go ahead. If Infra's
offering is not to your taste, that is.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Namespacing of subproject Docker images vs. Incubator policy
Posted by Mike Jumper <mi...@guac-dev.org>.
On Sep 6, 2016 5:38 PM, "Marvin Humphrey" <ma...@rectangular.com> wrote:
>
> ...
>
> Or, matching up with our (post-graduation) Git repo naming
> convention again:
>
> apache/guacamole
> apache/guacamole-guacd
>
> apache/guacamole:0.9.10-incubating
> apache/guacamole-guacd:0.9.10-incubating
>
> I think this is best. However, it bugs me that users are not provided
with
> adequate disclaimers for the common case that fetches `latest` as the
default
> tag:
>
> docker pull apache/guacamole
>
A necessary evil, perhaps. Even with Maven (at least older versions of
Maven), omitting the version while keeping only the groupId and artifactId
were legal coordinates.
Is the project-specific organization option not really an option at all
then? Frowned upon for a TLP, and not to be considered by a podling?
Thanks,
- Mike
Re: Namespacing of subproject Docker images vs. Incubator policy
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Thu, Sep 1, 2016 at 7:47 PM, Mike Jumper <mi...@guac-dev.org> wrote:
> All, setting aside the Docker Hub vs. Apache-hosted hub vs. bintray
> discussion for the moment,
The issue of hub.docker.com/r/apache/* has been worked out in principle with
Infra. Only official releases will be be built, and `latest` will point to
an image based on the last official release. The plan has not yet been
implemented, but now you know what to expect in the future.
See the infrastructure@apache thread (login required):
https://s.apache.org/euyI
> are there any specific opinions regarding
> the original issue: the actual namespacing of the podling images
> themselves?
> apache/incubator-guacamole:0.9.10-incubating
> apache/incubator-guacd:0.9.10-incubating
Using how we name Git repos as precedent, the image address would be:
apache/incubator-guacamole
apache/incubator-guacamole-guacd
... and with tags:
apache/incubator-guacamole:0.9.10-incubating
apache/incubator-guacamole-guacd:0.9.10-incubating
> - Seems redundant (incubator, incubating), graduation would break
> compatibility (see Maven best practices [1])
I agree that it would be best not to break compat on graduation.
> apache/guacamole:0.9.10-incubating
> apache/guacd:0.9.10-incubating
Or, matching up with our (post-graduation) Git repo naming
convention again:
apache/guacamole
apache/guacamole-guacd
apache/guacamole:0.9.10-incubating
apache/guacamole-guacd:0.9.10-incubating
I think this is best. However, it bugs me that users are not provided with
adequate disclaimers for the common case that fetches `latest` as the default
tag:
docker pull apache/guacamole
I don't have any ideas beyond requiring a prominent incubation disclaimer on
the repo info page at https://hub.docker.com/r/apache/$REPO/ .
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Namespacing of subproject Docker images vs. Incubator policy
Posted by Mike Jumper <mi...@guac-dev.org>.
On Sun, Aug 28, 2016 at 9:28 PM, Mike Jumper <mi...@guac-dev.org> wrote:
>
> On Sun, Aug 28, 2016 at 6:49 PM, Mike Jumper <mi...@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Namespacing of subproject Docker images vs. Incubator policy
Posted by Mike Jumper <mi...@guac-dev.org>.
On Sun, Aug 28, 2016 at 6:49 PM, Mike Jumper <mi...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Namespacing of subproject Docker images vs. Incubator policy
Posted by Mike Jumper <mi...@guac-dev.org>.
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
Re: Namespacing of subproject Docker images vs. Incubator policy
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
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.
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 :-(
Thanks,
Roman.
On Sun, Aug 28, 2016 at 4:21 PM, Mike Jumper <mi...@guac-dev.org> wrote:
> Hello all,
>
> We, Apache Guacamole (incubating), would like to migrate our project's
> Docker images to something beneath the ASF, but I am unsure how to
> proceed, nor the form that this migration would best take.
>
> We currently have two repositories which provide Docker images:
> incubator-guacamole-client [1] and incubator-guacamole-server [2].
> Prior to acceptance into the Apache Incubator, these repositories were
> used to produce the "glyptodon/guacamole" [3] and "glyptodon/guacd"
> [4] images respectively.
>
> As there is already an "apache/*" organization defined at Docker Hub
> (albeit a virtual desert) [5] and there was positive discussion
> regarding including the images of incubating projects under that
> organization [6], it seems that would be the logical and
> straightforward choice ... but because one of those images ("guacd")
> would not be namespaced by the project's own name, I'm unsure if this
> is actually possible/allowed.
>
> Ideally we would end up with a mapping like:
>
> incubator-guacamole-client -> apache/guacamole
> incubator-guacamole-server -> apache/guacd
>
> Or, since we're incubating, perhaps:
>
> incubator-guacamole-client -> apache/incubator-guacamole
> incubator-guacamole-server -> apache/incubator-guacd
>
> But again, I'm not sure if "apache/incubator-guacd" would be a
> violation of policy.
>
> Alternatively, a cleaner approach could be to define a Docker Hub
> organization specific to the project, as that would provide a nice
> analogy to the project/subproject relationship that exists between
> Apache Guacamole the "guacamole" and "guacd" applications:
>
> incubator-guacamole-client -> guacamole/guacamole
> incubator-guacamole-server -> guacamole/guacd
>
> But I'm not sure if THAT would be a violation of policy. Further,
> after creating exactly such an organization for the sake of testing,
> I've found that I can't set up the necessary linkage for enabling
> automatic builds (the organization would need to be owned by a user
> with sufficient access rights to the Apache GitHub mirrors).
>
> Any suggestions?
>
> Thanks,
>
> - Mike
>
> [1] https://github.com/apache/incubator-guacamole-client
> [2] https://github.com/apache/incubator-guacamole-server
> [3] https://hub.docker.com/r/glyptodon/guacamole/
> [4] https://hub.docker.com/r/glyptodon/guacd/
> [5] https://hub.docker.com/r/apache/
> [6] http://mail-archives.apache.org/mod_mbox/incubator-general/201604.mbox/%3CCANyrgvfAWifLkkvAccAV22Q9uyo8g3so=BJ0JFZ8oV16Bt=kzQ@mail.gmail.com%3E
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org