Thanks the answers Eric Yang, I think we have similar view about how the
releases are working and what you wrote is exactly the reason why I
prefer the current method (docker image creation from separated branch)
instead of the proposed one (create images from maven).
1. Not all the branches can b
See comments inline.
On Fri, Mar 22, 2019 at 2:06 AM Elek, Marton wrote:
>
>
> Thanks the answer,
>
> I agree, sha256 based tags seems to be more safe and bumping versions
> only after some tests.
>
>
> Let's say we have multiple hadoop docker images:
>
> apache/hadoop:3.2.0
> apache/hadoop:3.1.
Thanks the answer,
I agree, sha256 based tags seems to be more safe and bumping versions
only after some tests.
Let's say we have multiple hadoop docker images:
apache/hadoop:3.2.0
apache/hadoop:3.1.2
apache/hadoop:2.9.2
apache/hadoop:2.8.5
apache/hadoop:2.7.7
If I understood well, your pr
The flexibility of date appended release number is equivalent to maven snapshot
or Docker latest image convention, machine can apply timestamp better than
human. By using the Jenkins release process, this can be done with little
effort. For official release, it is best to use Docker image dige
> If versioning is done correctly, older branches can have the same docker
> subproject, and Hadoop 2.7.8 can be released for older Hadoop branches. We
> don't generate timeline paradox to allow changing the history of Hadoop
> 2.7.1. That release has passed and let it stay that way.
I und
,
Eric
From: Jonathan Eagles
Date: Tuesday, March 19, 2019 at 11:48 AM
To: Eric Yang
Cc: "Elek, Marton" , Hadoop Common
, "yarn-...@hadoop.apache.org"
, Hdfs-dev , Eric
Badger , Eric Payne ,
Jim Brennan
Subject: Re: [DISCUSS] Docker build process
This email discussion thr
Hi Arpit,
On Docker Hub, Hadoop tagged with version number that looks like:
docker-hadoop-runner-latest, or jdk11. It is hard to tell if jdk11 image is
Hadoop 3 or Hadoop 2 because there is no consistency in tag format usage. This
is my reasoning against tag as your heart desired because flex
Hi Eric,
> Dockerfile is most likely to change to apply the security fix.
I am not sure this is always. Marton’s point about revising docker images
independent of Hadoop versions is valid.
> When maven release is automated through Jenkins, this is a breeze
> of clicking a button. Jenkins eve
This email discussion thread is the result of failing to reach consensus in
the JIRA. If you participate in this discussion thread, please recognize
that a considerable effort has been made by contributors on this JIRA. On
the other hand, contributors to this JIRA need to listen carefully to the
co
I agree with Steve and Marton. I am ok with having the docker build as an
option, but I don't want it to be the default.
Jim
On Tue, Mar 19, 2019 at 12:19 PM Eric Yang wrote:
> Hi Marton,
>
> Thank you for your input. I agree with most of what you said with a few
> exceptions. Security fix
Hi Marton,
Thank you for your input. I agree with most of what you said with a few
exceptions. Security fix should result in a different version of the image
instead of replace of a certain version. Dockerfile is most likely to change
to apply the security fix. If it did not change, the sou
Thank you Eric to describe the problem.
I have multiple small comments, trying to separate them.
I. separated vs in-build container image creation
> The disadvantages are:
>
> 1. Require developer to have access to docker.
> 2. Default build takes longer.
These are not the only disadvanta
Loughran
Date: Monday, March 18, 2019 at 3:36 AM
To: Eric Yang
Cc: Hadoop Common , "yarn-...@hadoop.apache.org"
, Hdfs-dev , Eric
Badger , Eric Payne ,
Jonathan Eagles , Jim Brennan
, "Elek, Marton"
Subject: Re: [DISCUSS] Docker build process
I'm not enthusiastic abou
I'm not enthusiastic about making the docker build process mandatory. It's
bad enough having to remember to type -DskipShade to avoid a 5-10 minute
delay every time I do a build of a different branch, which I have to do
every single time I change from one PR to another.
I do not see why the docker
14 matches
Mail list logo
