nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aldrin Piri <>
Subject Re: [DISCUSS] Official Apache NiFi Docker Image
Date Mon, 09 Jan 2017 16:29:37 GMT
I think with some of the general ideas we discussed, we are tracking
appropriately with currently accepted guidance. Of particular note is our
discussed terms of tagging/versions of the images that would be created
exclusively and solely with community releases.

I base this interpretation off LEGAL-270 [1].


On Fri, Jan 6, 2017 at 11:36 AM, Josh Elser <> wrote:

> Cool, regex to work on the recent "rel/*" tagging scheme would work out
> well!
> I'd also give one word of caution about licensing (I don't think the ASF
> as a whole has figured out how to navigate this). Essentially, a docker
> image is a "convenience binary" and may contain GPL'ed things. Thus, this
> would violate the traditional policy.
> I don't bring that up to dissuade Jeremy or anyone from taking up the
> work, just to make sure that you all are aware that this has been a broad
> area of discussion :)
> Aldrin Piri wrote:
>> Thanks for the info, Josh.  Looks like these are building directly off of
>> the ASF Github mirrors.
>> Looks like a few projects have navigated the process [1] and INFRA would
>> likely be the folks to make that happen.  Need to understand a bit more
>> about what is appropriate in the context of ASF.  But, at minimum, we
>> could
>> create automated builds that only build release tags using a regex [2].
>> [1]
>> 20~%20%22dockerhub%22%20and%20project%20%3D%20INFRA
>> [2]
>> On Thu, Jan 5, 2017 at 2:07 PM, Josh Elser<>  wrote:
>> FYI, there's also an "apache" space on dockerhub[1]. Sadly, I'm a little
>>> unclear on how a project would actually go about pushing stuff there.
>>> Might
>>> be some docs floating around or a ping to infra.
>>> [1]
>>> Jeremy Dyer wrote:
>>> Team,
>>>> I wanted to discuss getting an official Apache NiFi Docker image similar
>>>> to
>>>> other Apache projects like storm [1], httpd [2], thrift [3], etc.
>>>> Official Docker images are hosted at and made
>>>> available to the Docker runtime of end users without them having to
>>>> build
>>>> the images themselves. The process of making a Docker image "official",
>>>> meaning that it is validated and reviewed by a community of Docker folks
>>>> for security flaws, best practices, etc, works very closely to how our
>>>> standard contribution process to NiFi works today. We as a community
>>>> would
>>>> create our Dockerfile(s) and review them just like we review any JIRA
>>>> today
>>>> and then commit that against our codebase.
>>>> There is an additional step from there in that once we have a commit
>>>> against our codebase we would need an "ambassador" (I happily volunteer
>>>> to
>>>> handle this if there are no objections) who would open a Github Pull
>>>> Request against the official docker image repo [4]. Once that PR has
>>>> successfully been reviewed by the official repo folks it would be hosted
>>>> on
>>>> Dockerhub and readily available to end users.
>>>> In my mind the steps required to reach this goal would be.
>>>> 1. Create NiFi, MiNiFi, MiNiFi-CPP JIRAs for creating the initial folder
>>>> structure and baseline Dockerfiles in each repo. I also volunteer myself
>>>> to
>>>> take this on as well.
>>>> 2. Once JIRA is completed, reviewed, and community thumbs up is given I
>>>> will request the Dockerhub repo handle of "library/apachenifi" with the
>>>> maintainer of that repos contact email as<>
>>>> 2a). I suggest we follow the naming structure like
>>>> "library/apachenifi:nifi-1.1.0", "library/apachenifi:minifi-0.1.0",
>>>> "libraryapachenifi:minifi-cpp-0.1.0". This makes our official image
>>>> much
>>>> more clean than having 3 separate official images for each subproject.
>>>> 3) I will open a PR against [4] with our community Dockerfiles
>>>> 4) After each release I will continue to open pull requests against [4]
>>>> to
>>>> ensure the latest releases are present.
>>>> Please let me know your thoughts.
>>>> [1] -
>>>> [2] -
>>>> [3] -
>>>> [4] -
>>>> Thanks,
>>>> Jeremy Dyer

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message