That’s a fair point about separating the releases of Accumulo from its docker packaging. I would say that we’d want a new docker image release every time there’s a new Accumulo release, but the reverse is what we’re wanting to avoid. Personally, I would equate a Docker release to a RPM/DEB/etc release. There can be bugs in the packaging, and for RPMs my (possibly incorrect) understanding is the release number (the -1 in what I suggested) is meant to cover that.
> On 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 >>>>>>> >>>>>>> >>>>>> >>>>> >>> >>>
