Since dependencies can change in minor version, I don't think we will be able to get away with just a version that works with 2.x, like the maven plugin. We have already seen changes in the docker file due to dependencies, i.e. the recent update to ZooKeeper and the runtime binary path. I think having one-up counters off of releases makes the most sense, like in Brian's example. Accumulo doesn't have that many releases and we shouldn't have more than a few fixes per release.
On Mon, Apr 20, 2020 at 3:32 PM Christopher <[email protected]> wrote: > 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 > > > >>>> > > > >>>> > > > >>> > > > >> > > > > > > >
