On naming: having a name derived from the Accumulo version makes some sense. However, the Docker packaging itself can be versioned in addition to Accumulo being versioned. There may be bugs in the packaging, rather than bugs in Accumulo. I wouldn't want to do a new release of Accumulo every time there's a minor packaging bug. Similarly, it doesn't necessarily seem to make sense to release new Docker packaging every time there's a bugfix in Accumulo, if the existing Docker can be configured to use the newer version of Accumulo with a command-line option.
So, I think it makes sense to have them coupled a little... but not too coupled. Regarding the suggestion to include the Dockerfile inside the main package itself.... I'm not so sure about that. First, this gets us in the same position as having to release a new version of Accumulo every time there's a Docker packaging bug. Second, I'm not a fan of coupling packaging to the core project. Packaging should be downstream of the project. This helps ensure that the core project's decisions are agnostic to downstream packaging, which is a really good principle to try to follow so that you don't restrict downstream integration flexibility. FWIW, the naming convention we went with for Accumulo's maven plugin packaging for 2.x was: accumulo2-maven-plugin-1.0.0 (the versioning started over at 1.0.0, but used 'accumulo2' to communicate the intent that the plugin be for all Accumulo 2.x, because any client code compatible with 2.x should work with any future 2.x, because we are backwards compatible). Perhaps something similar makes sense for Docker? On Mon, Apr 20, 2020 at 9:57 AM Michael Wall <[email protected]> wrote: > > Thanks Brian, you bring up a good point on the latest tag. I would be fine > with this proposal as well. > > On Mon, Apr 20, 2020 at 9:41 AM Brian Loss <[email protected]> wrote: > > > Another possibility is to push all of that extra info into the tag. E.g., > > > > accumulo:1.9.3-1 > > accumulo:2.0.0-1 > > accumulo:2.0.0-1-alpine > > > > That seems to be the basic pattern used by projects such as openjdk. It’s > > true that you couldn’t then have a latest tag for Accumulo 1.9.3 and > > Accumulo 2.0, but I don’t believe that’s the intent of the latest tag. I > > believe that’s supposed to be the single latest available stable release so > > that if I did “docker pull accumulo” I’d get the current version. > > > > > On Apr 20, 2020, at 9:20 AM, Michael Wall <[email protected]> wrote: > > > > > > Just now following this. Looking at dockerhub, many project do something > > > like accumulo:1.9.3, accumulo:2.0.0 and then > > > have a tag accumulo:latest that is the latest version. So if you run > > > `docker pull accumulo`, it uses > > > latest by default. I have always found this a little lacking because if > > > you need to update the Dockerfile for say > > > accumulo:1.9.3, you must overwrite the previous images. If someone used > > > that prior image as a base image, it is > > > then really hard to recreate their image from scratch if they clear out > > > their docker cache. > > > > > > Numbers are free, so another option is to do something thing like > > > accumulo-1.9.3:1, accumulo-2.0.0:4 and tag > > > accumulo-2.0.0:latest with the last version of accumulo-2.0.0. This is > > > what I tend to do. > > > > > > If we wanted to provide images running on different OS's, we might also > > > consider names like accumulo-1.9.3-centos7:1 > > > and accumulo-2.0.0-ubuntu16:2. Not sure that is necessary. > > > > > > Mike > > > > > > On Mon, Apr 20, 2020 at 9:03 AM Vincent Russell < > > [email protected]> > > > wrote: > > > > > >> Most projects, that I've seen anyway, keep their Dockerfile in the same > > >> repository as their source code so that it's versioned with the software > > >> that its loading. > > >> > > >> Please consider doing this for accumulo. > > >> > > >> Thanks, > > >> Vincent > > >> > > >> On Mon, Apr 20, 2020 at 8:05 AM karthick rn < > > [email protected]> > > >> wrote: > > >> > > >>> Hi Christopher, > > >>> > > >>>> Before we vote, I'd like to us to have some idea of how we will label > > >>>> versions of accumulo-docker releases. Any opinions? > > >>> Could we label the 'accumulo-docker' versions based on the Accumulo > > >> version > > >>> used in it? I thought it would be simple by just relying on Accumulo > > >>> version & not having to maintain a separate versioning for > > >>> 'accumulo-docker'. However, I'm not sure if this would be an acceptable > > >>> practice in Apache, others might chime if they have any ideas? > > >>> > > >>> Found this JIRA https://issues.apache.org/jira/browse/INFRA-17518, > > that > > >>> suggests 2 options for publishing images to dockerhub, the 2nd option > > >> looks > > >>> more apt for our case & like you mentioned, we'll have to engage INFRA > > & > > >>> start a discussion on "[email protected]". > > >>> > > >>> Thanks, > > >>> Karthick > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> On Fri, 10 Apr 2020 at 13:49, Ed Coleman <[email protected]> wrote: > > >>> > > >>>> Does the NiFi community have an established process or procedure that > > >>> they > > >>>> follow that we could copy as a guide? ( > > >>>> https://hub.docker.com/r/apache/nifi/) > > >>>> > > >>>> -----Original Message----- > > >>>> From: Christopher [mailto:[email protected]] > > >>>> Sent: Friday, April 10, 2020 12:23 AM > > >>>> To: accumulo-dev <[email protected]> > > >>>> Subject: Re: accumulo-docker > > >>>> > > >>>> First, I don't know much about how Docker or Dockerhub works. I don't > > >> use > > >>>> docker often, and have never used Dockerhub. So that is a gap in my > > >>>> knowledge that will need to be filled by somebody else's expertise. > > >>>> > > >>>> Before we distribute accumulo-docker code, we need to vote on a > > >> release. > > >>>> Any PMC member can prepare a release candidate and initiate that vote. > > >>>> (I'm willing to do it, once we figure out how the distribution should > > >>> go.) > > >>>> > > >>>> Before we vote, I'd like to us to have some idea of how we will label > > >>>> versions of accumulo-docker releases. Any opinions? > > >>>> > > >>>> After we figure out release versioning and vote, I don't know what > > >> comes > > >>>> next. > > >>>> > > >>>> I believe INFRA has an "organization" for Apache on Dockerhub... but > > >> we'd > > >>>> probably have to put in a ticket. > > >>>> A search on JIRA shows some previous similar issues: > > >>>> > > >>>> > > >>> > > >> > > https://issues.apache.org/jira/browse/INFRA-18167?jql=project%3DINFRA%20AND%20text~dockerhub > > >>>> > > >>>> Those might be a good starting point for researching how to publish. > > >>>> > > >>>> On Thu, Apr 9, 2020 at 2:25 PM karthick rn < > > >> [email protected] > > >>>> > > >>>> wrote: > > >>>>> > > >>>>> Hi Christopher, > > >>>>> > > >>>>> Following the conversation from PR#12 > > >>>>> <https://github.com/apache/accumulo-docker/pull/12>, I'm interested > > >> to > > >>>>> drive this forward and publish the image to Dockerhub. Let me know > > >> how > > >>>>> do I get in touch with INFRA? > > >>>>> > > >>>>> Thanks, > > >>>>> Karthick > > >>>> > > >>>> > > >>> > > >> > > > >
