Inline…
From: Jose Lausuch <[email protected]>
Date: Tuesday, July 11, 2017 at 4:27 AM
To: Fatih Degirmenci <[email protected]>, "Beierl, Mark"
<[email protected]>, "Alec Hothan (ahothan)" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: RE: [opnfv-tech-discuss] Multiple docker containers from one project
Hi,
We excluded incremental tags because we overflooded our docker repos (I had to
remove ~300 tags manually once in Functest docker repo). For projects that
merge patches almost every day, that approach is unmaintainable.
This is what we are currently following:
latest:
built from latest master. It is used in CI master jenkins jobs -->
Continuous Delivery
[Alec]
Does latest always refer to the “current development release” – e.g. it would
be Euphrates as of today?
How about latest for Danube?
stable:
built from “latest” patch of stable branch. It doesn’t change so
frequently but it contains latest bugfixes from stable branches. It is used in
CI Danube jenkins jobs.
[Alec]
What is defined as the “stable branch”? Is it the danube branch as of today?
Is it needed to have a stable for euphrates or for Colorado?
danube.X.0
built once the project is ready for release. It must be done manually
by the PTL or Jenkins admin. Not tested directly in CI, but it should be the
same image as stable tag at the end of the release cycle.
[Alec]
Is there a manifest per project somewhere that indicates what artifacts go into
a release for that project?
This along with a project list for the release will provide exactly the full
content of a release.
A few of the questions I raised in a previous email:
* do force every project to have a git tag that matches the container tag (
this obviously does not apply to non unique container tags such as “stable” or
“latest”)? Without that, it is very difficult to track a container version to a
git repo commit.
* How are incremental versions supported for a given release (e.g. when
danube 3.0 comes out, how can a project push out a new maintenance release of a
container say 2 days after the danube 3.0 was released), we can’t just
overwrite the “danube.3.0” container
For the concern:
“As for the git clone issue, or pip install from git, there is no tag provided.
This is a concern that I have with the way there is a separation of docker
build (in releng) and git clone. We cannot actually rebuild from a label at
this time.”
If you are doing a git clone of your repository to be installed by pip. You can
setup arguments in your Dockerfile. Example:
ARG BRANCH=master
RUN git clone --depth 1 -b $BRANCH
https://gerrit.opnfv.org/gerrit/storperf
BRANCH argument can be overwritten by the docker build command (default is
‘master’ in this example) and it’s exactly what the jenkins job is doing.
[Alec]
That’s good but we still have to solve the resulting container tag
appropriately ;-)
Thanks,
/Alec
Regards,
Jose
From: [email protected]
[mailto:[email protected]] On Behalf Of Fatih
Degirmenci ARG BRANCH=master
Sent: Monday, July 10, 2017 18:24 PM
To: Beierl, Mark <[email protected]>; Alec Hothan (ahothan)
<[email protected]>
Cc: [email protected]
Subject: Re: [opnfv-tech-discuss] Multiple docker containers from one project
Hi,
About the tagging question; in the past we tagged all the images we built and
stored on Docker hub. The tags for the intermediate versions were set
incrementally and applied automatically by the build job and release tag was
applied manually for the release.
But then (some of the) test projects decided not to do that and got rid of
that. (I don't exactly remember who, why and so on.)
We obviously failed to flag this at that time. This should be discussed by Test
WG and fixed.
/Fatih
From:
<[email protected]<mailto:[email protected]>>
on behalf of "Beierl, Mark" <[email protected]<mailto:[email protected]>>
Date: Monday, 10 July 2017 at 18:10
To: "Alec Hothan (ahothan)" <[email protected]<mailto:[email protected]>>
Cc:
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Subject: Re: [opnfv-tech-discuss] Multiple docker containers from one project
Sorry, Alec, for not responding. I'm not a releng committer so I thought
someone from there would have replied. You are correct that the tag is
provided by the person running the job in Jenkins and passed through to
opnfv-docker.sh.
As for the git clone issue, or pip install from git, there is no tag provided.
This is a concern that I have with the way there is a separation of docker
build (in releng) and git clone. We cannot actually rebuild from a label at
this time.
Perhaps this is a bigger issue that needs to be discussed before we can
properly address multiple docker builds.
Regards,
Mark
Mark Beierl
SW System Sr Principal Engineer
Dell EMC | Office of the CTO
mobile +1 613 314 8106<tel:1-613-314-8106>
[email protected]<mailto:[email protected]>
On Jul 10, 2017, at 11:34, Alec Hothan (ahothan)
<[email protected]<mailto:[email protected]>> wrote:
Projects that do not have pyPI packages (or the right version of PyPI package
published) might prefer to do a git clone instead and either install it
directly or using pip install from the clone in the container.
Some Dockerfile may prefer to directly install from the current (cloned) repo
(and avoid a git clone) but this might accidentally (or purposely) include
local patches into the built container.
There are many valid ways to skin the cat…
I did not get any feedback on a previous question I had on container
versioning/tagging.
The container versioning currently used is based on the branch name followed by
a release name (e.g. “danube.3.0”) with the addition of latest, stable and
master.
From opnfv-docker.sh:
# Get tag version
echo "Current branch: $BRANCH"
BUILD_BRANCH=$BRANCH
if [[ "$BRANCH" == "master" ]]; then
DOCKER_TAG="latest"
elif [[ -n "${RELEASE_VERSION-}" ]]; then
DOCKER_TAG=${BRANCH##*/}.${RELEASE_VERSION}
# e.g. danube.1.0, danube.2.0, danube.3.0
else
DOCKER_TAG="stable"
fi
if [[ -n "${COMMIT_ID-}" && -n "${RELEASE_VERSION-}" ]]; then
DOCKER_TAG=$RELEASE_VERSION
BUILD_BRANCH=$COMMIT_ID
fi
If branch is master, the tag is master, if RELEASE_VERSION is defined, it is
branch.<release-version> else it is stable.
And lastly the above is overridden to RELEASE_VERSION if RELEASE_VERSION is set
and COMMIT_ID is defined (wonder how that works with 2 branches with same
RELEASE_VERSION?).
There are few gaps that don’t seem to be covered by this versioning - perhaps
there is a way that project owners who publish containers work around them?
· How are the containers for multiple versions of master at various
commits published ? They all seem to have the “master” tag
· For a given branch (say Danube), same question for a given release
(say for Danube 3.0, one might have multiple versions of a container with
various patches)
· Some projects may have containers that actually work with multiple
OPNFV releases, will they be forced to publish the same container image with
different tags (e.g. danube.3.0 and euphrates.1.0)?
In general a docker container tag would have version in it (e.g. 3.2.1) and
sometimes along with a text describing some classification (indicating for
example variations of the same source code version). In the case of OPNFV.
I’m not quite sure about when stable is used from the look of the script.
I’d be interested to know how current project docker owners deal with the above
and if there is any interest to address them.
Thanks
Alec
From:
<[email protected]<mailto:[email protected]>>
on behalf of Cedric OLLIVIER
<[email protected]<mailto:[email protected]>>
Date: Monday, July 10, 2017 at 12:20 AM
To: "Beierl, Mark" <[email protected]<mailto:[email protected]>>
Cc:
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Subject: Re: [opnfv-tech-discuss] Multiple docker containers from one project
I'm sorry I don't understand the point of git clone.
Here we simply install Functest via the python package.
Pip install does a local copy because it's not published in PyPI yet and then
removes it after installing the package.
Why should we clone again the repository?
Cédric
2017-07-10 3:10 GMT+02:00 Beierl, Mark
<[email protected]<mailto:[email protected]>>:
Why should we avoid copy? Why do a git clone of the existing git clone?
Almost every dockerfile example I have seen uses copy, not a second got
checkout of the same code.
Regards,
Mark
Mark Beierl
SW System Sr Principal Engineer
Dell EMC | Office of the CTO
mobile +1 613 314 8106<tel:1-613-314-8106>
[email protected]<mailto:[email protected]>
On Jul 9, 2017, at 21:00, Cedric OLLIVIER
<[email protected]<mailto:[email protected]>> wrote:
No we cannot (parent directory) and we should mostly avoid copying files
(except for configurations).
For instance, you could have a look to
https://gerrit.opnfv.org/gerrit/#/c/36963/.
All Dockerfiles simply download Alpine packages, python packages (Functest +
its dependencies) and upper constraints files.
testcases.yaml is copied from host as it differs between our containers (smoke,
healthcheck...).
Cédric
2017-07-10 1:25 GMT+02:00 Beierl, Mark
<[email protected]<mailto:[email protected]>>:
My only concern is for dockerfiles that do a "COPY . /home" in them. That means
all the code would be located under the docker directory.
I suppose multiple ../ paths can be used instead.
Regards,
Mark
Mark Beierl
SW System Sr Principal Engineer
Dell EMC | Office of the CTO
mobile +1 613 314 8106<tel:1-613-314-8106>
[email protected]<mailto:[email protected]>
On Jul 9, 2017, at 19:03, Julien
<[email protected]<mailto:[email protected]>> wrote:
Hi Cédric,
Patch in https://gerrit.opnfv.org/gerrit/#/c/36963/ is exact what I mean.
Let's collect the opinions from the releng team.
Julien
Cedric OLLIVIER
<[email protected]<mailto:[email protected]>>于2017年7月10日周一
上午4:15写道：
Hello,
Please see https://gerrit.opnfv.org/gerrit/#/c/36963/ which introduces several
containers for Functest too.
I think the tree conforms with the previous requirements.
Automating builds on Docker Hub is a good solution too.
Cédric
2017-07-09 12:10 GMT+02:00 Julien
<[email protected]<mailto:[email protected]>>:
Hi Jose,
According to the current implementation, current script only support one
Dockerfile, my personal suggestion is:
1. list all the sub-directory which contains "Dockerfile"
2. build for each sub-directory fetched in #1
3. for the names, in the top directory using the project name, in the
sub-directory using: project_name-sub_directory_name
not too much changes for current script and easy for project to manage.
/Julien
Beierl, Mark <[email protected]<mailto:[email protected]>>于2017年7月7日周五
下午11:35写道：
Hello,
Having looked over the docker-hub build service, I also think this might be the
better approach. Less code for us to maintain, and the merge job from OPNFV
Jenkins can use the web hook to remotely trigger the job on docker-hub.
Who has the opnfv credentials for docker-hub, and the credentials for the
GitHub mirror that can set this up? Is that the LF Helpdesk?
Regards,
Mark
Mark Beierl
SW System Sr Principal Engineer
Dell EMC | Office of the CTO
mobile +1 613 314 8106<tel:1-613-314-8106>
[email protected]<mailto:[email protected]>
On Jul 7, 2017, at 11:01, Xuan Jia
<[email protected]<mailto:[email protected]>> wrote:
+1 Using build service from docker-hub
On Thu, Jul 6, 2017 at 11:42 PM, Yujun Zhang (ZTE)
<[email protected]<mailto:[email protected]>> wrote:
Does anybody consider using the build service from docker-hub[1] ?
It supports multiple Dockerfile from same repository and easy to integrate with
OPNFV Github mirror.
[1]: https://docs.docker.com/docker-hub/builds/
On Thu, Jul 6, 2017 at 11:02 PM Jose Lausuch
<[email protected]<mailto:[email protected]>> wrote:
Hi Mark,
I would incline for option 1), it sounds better than searching for a file. We
could define specific values of DOCKERFILE var for each project.
/Jose
From: Beierl, Mark [mailto:[email protected]<mailto:[email protected]>]
Sent: Thursday, July 06, 2017 16:18 PM
To:
[email protected]<mailto:[email protected]>
Cc: Julien <[email protected]<mailto:[email protected]>>; Fatih Degirmenci
<[email protected]<mailto:[email protected]>>; Jose
Lausuch <[email protected]<mailto:[email protected]>>
Subject: Re: [opnfv-tech-discuss] Multiple docker containers from one project
Ideas:
· Change the DOCKERFILE parameter in releng jjb so that it can accept a
comma delimited list of Dockerfile names and paths. Problem with this, of
course, is how do I default it to be different for StorPerf vs. Functest, etc?
· Change the opnfv-docker.sh to search for the named DOCKERFILE in all
subdirectories. This should cover the .aarch64 and vanilla docker file cases.
Please +1/-1 or propose other ideas, thanks!
Regards,
Mark
Mark Beierl
SW System Sr Principal Engineer
Dell EMC | Office of the CTO
mobile +1 613 314 8106<tel:1-613-314-8106>
[email protected]<mailto:[email protected]>
On Jun 24, 2017, at 04:05, Jose Lausuch
<[email protected]<mailto:[email protected]>> wrote:
+1
No need for an additional repo, the logic can be in Releng..
Functest will probably move to different containers some time soon, so that is
something we could also leverage.
-Jose-
On 23 Jun 2017, at 18:39, Julien
<[email protected]<mailto:[email protected]>> wrote:
Agree,
If StorPerf can list some rules and examples, current scripts can be adapted
for multiple docker image building and other project can use this type of
changes. It is not deserved to add a new repo just for build a new image.
_______________________________________________
opnfv-tech-discuss mailing list
[email protected]
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
