You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@yetus.apache.org by Allen Wittenauer <aw...@effectivemachines.com.INVALID> on 2018/11/12 06:46:41 UTC
[DISCUSS] YETUS-683
YETUS-683 proposes to start publishing convenience binaries as images at hub.docker.com. Included with that JIRA is a patch that provides some (admittedly sparse) documentation on how to take advantage of those images.
My current design is to provide two images:
apache/yetus-base:(latest|branch|release tag) - Apache Yetus’ requirements in it
apache/yetus:(latest|branch|release tag) - base+ Apache Yetus pre-installed in /usr
We’d take advantage of docker hub’s capabilities to auto-build for us so it shouldn’t require much work other than telling infra to turn it on. The necessary magic for hub.docker.com to build things sanely (e.g., apache/yetus:0.9.0 will use apache/yetus-base:0.9.0 and not latest) was already committed as part of YETUS-15.
IMHO, I view making these images available as an absolutely critical part of making Apache Yetus easier to use. In particular, it should be noted that in order to make Circle CI and Gitlab CI first class citizens (see YETUS-681), Docker images are pretty much required.
Any questions/comments/concerns?
Thanks!
Re: [DISCUSS] YETUS-683
Posted by Allen Wittenauer <aw...@effectivemachines.com.INVALID>.
> On Nov 14, 2018, at 5:11 PM, Sean Busbey <bu...@apache.org> wrote:
>
> "latest" sounds like something a downstreamer should use to stay up to
> date, so I'd rather have it track release and name the current master
> branch image "master”.
I’m actually leaning towards not having a latest. ‘latest’ is particularly loaded when it comes to Docker and we probably want folks to manually switch from one version to another. e.g., what happens when latest switches from a 1.0 to 2.0? likely major carnage. I’m also thinking the same thing about branches. In the end, that would leave us with (e.g.):
apache/yetus-base:master <- pre-reqs to run master
apache/yetus-base:0.9.0 <- pre-regs to run 0.9.0
apache/yetus:master <- yetus-base:master + master installed in /usr
apache/yetus:0.9.0 <- yetus-base:0.9.0 + 0.9.0 installed in /usr
From a practical perspective, this would make a Jenkins pipeline+Github Source Plugin (post-YETUS-681 and all of its dependents, which auto-resolves a lot of the command line parameters) file look something like this if the yetus Dockerfile has everything a build needs from the OS:
pipeline {
agent {
docker ‘apache/yetus:0.9.0’
}
options {
checkoutToSubdirectory(’src’)
}
stages {
steps {
sh ‘’’#!/usr/bin
test-patch —basedir=${WORKSPACE}/src —plugins=all —patch-dir=${WORKSPACE}/out
‘’'
}
}
post {
dir(“${WORKSPACE}”) {
archiveArtifacts artifacts: ‘out/**/*'
}
}
}
If there are no other comments, I’ll start a vote thread to work out the logistics with INFRA to get images uploaded.
Thanks!
Re: [DISCUSS] YETUS-683
Posted by Sean Busbey <bu...@apache.org>.
"latest" sounds like something a downstreamer should use to stay up to
date, so I'd rather have it track release and name the current master
branch image "master".
Otherwise sounds good.
On Tue, Nov 13, 2018, 12:41 Allen Wittenauer
<aw@effectivemachines.com.invalid wrote:
>
>
> > On Nov 13, 2018, at 4:17 AM, Sean Busbey <bu...@apache.org> wrote:
> >
> > How do we delineate between images meant for downstream (i.e. releases)
> vs
> > those only for use when working on yetus (branches)?
>
> Basically, you’ll have images tagged with version numbers. i.e.,
> apache/yetus:0.9.0 would correspond with Apache Yetus v0.9.0. Branches
> would appear (given our current naming scheme) as apache/yetus:YETUS-1 (or
> whatever JIRA). The master branch would appear as apace/yetus:latest
> unless we’d want to tag it as something specific (e.g., master).
>
> FWIW, I’m currently working on a patch to allow users to specify
> the image tag to use as the base rather than depending upon docker build as
> a companion to these images.
Re: [DISCUSS] YETUS-683
Posted by Allen Wittenauer <aw...@effectivemachines.com.INVALID>.
> On Nov 13, 2018, at 4:17 AM, Sean Busbey <bu...@apache.org> wrote:
>
> How do we delineate between images meant for downstream (i.e. releases) vs
> those only for use when working on yetus (branches)?
Basically, you’ll have images tagged with version numbers. i.e., apache/yetus:0.9.0 would correspond with Apache Yetus v0.9.0. Branches would appear (given our current naming scheme) as apache/yetus:YETUS-1 (or whatever JIRA). The master branch would appear as apace/yetus:latest unless we’d want to tag it as something specific (e.g., master).
FWIW, I’m currently working on a patch to allow users to specify the image tag to use as the base rather than depending upon docker build as a companion to these images.
Re: [DISCUSS] YETUS-683
Posted by Sean Busbey <bu...@apache.org>.
How do we delineate between images meant for downstream (i.e. releases) vs
those only for use when working on yetus (branches)?
On Mon, Nov 12, 2018, 00:53 Allen Wittenauer
<aw@effectivemachines.com.invalid wrote:
>
>
> YETUS-683 proposes to start publishing convenience binaries as
> images at hub.docker.com. Included with that JIRA is a patch that
> provides some (admittedly sparse) documentation on how to take advantage of
> those images.
>
> My current design is to provide two images:
>
> apache/yetus-base:(latest|branch|release tag) - Apache
> Yetus’ requirements in it
> apache/yetus:(latest|branch|release tag) - base+ Apache
> Yetus pre-installed in /usr
>
> We’d take advantage of docker hub’s capabilities to auto-build for
> us so it shouldn’t require much work other than telling infra to turn it
> on. The necessary magic for hub.docker.com to build things sanely (e.g.,
> apache/yetus:0.9.0 will use apache/yetus-base:0.9.0 and not latest) was
> already committed as part of YETUS-15.
>
> IMHO, I view making these images available as an absolutely
> critical part of making Apache Yetus easier to use. In particular, it
> should be noted that in order to make Circle CI and Gitlab CI first class
> citizens (see YETUS-681), Docker images are pretty much required.
>
> Any questions/comments/concerns?
>
> Thanks!
>
>
>