Re: [opnfv-tech-discuss] Multiple docker containers from one project

2017-07-11 Thread Jose Lausuch
More inline

From: Alec Hothan (ahothan) [mailto:ahot...@cisco.com]
Sent: Tuesday, July 11, 2017 16:40 PM
To: Jose Lausuch <jose.laus...@ericsson.com>; Fatih Degirmenci 
<fatih.degirme...@ericsson.com>; Beierl, Mark <mark.bei...@dell.com>
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] Multiple docker containers from one project

Inline…

From: Jose Lausuch <jose.laus...@ericsson.com<mailto:jose.laus...@ericsson.com>>
Date: Tuesday, July 11, 2017 at 4:27 AM
To: Fatih Degirmenci 
<fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com>>, "Beierl, 
Mark" <mark.bei...@dell.com<mailto:mark.bei...@dell.com>>, "Alec Hothan 
(ahothan)" <ahot...@cisco.com<mailto:ahot...@cisco.com>>
Cc: 
"opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>" 
<opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>>
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?
[Jose]
More or less, but Euphrates is not released yet. So it is latest-master, which 
will become Euphrates in the end.
latest for Danube = stable tag


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?
[Jose]
Yes. Stable tag refers to the latest state of stable/danube currently and 
stable/euphrates once we branch the repos. This is meant for CI testing. The 
released image won’t be called “stable”.

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.
[Jose]
Not explicitly
In Functest case, everything is in our Dockerfile and requirements.txt. That 
will conform the content of the Functest release (a docker image). I guess it’s 
applicable for other projects.


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.
[Jose] I can talk only for Functest, and we try to do it, but we need all the 
repos to be tagged when we build the image.


  *   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
[Jose] Good point.. maybe we should create danube.3.1



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: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Fatih 
Degirmenci ARG BRANCH=master
Sent: Monday, July 10, 2017 18:24 PM
To: Beierl, Mark <mark.bei...@dell.com<mailto:mark.bei...@dell.com>>; Alec 
Hothan (ahothan) <ahot...@cisco.com<mailto:ahot...@cisco.com>>
Cc: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-d

Re: [opnfv-tech-discuss] Multiple docker containers from one project

2017-07-11 Thread Alec Hothan (ahothan)
Inline…

From: Jose Lausuch <jose.laus...@ericsson.com>
Date: Tuesday, July 11, 2017 at 4:27 AM
To: Fatih Degirmenci <fatih.degirme...@ericsson.com>, "Beierl, Mark" 
<mark.bei...@dell.com>, "Alec Hothan (ahothan)" <ahot...@cisco.com>
Cc: "opnfv-tech-discuss@lists.opnfv.org" <opnfv-tech-discuss@lists.opnfv.org>
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: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Fatih 
Degirmenci ARG BRANCH=master
Sent: Monday, July 10, 2017 18:24 PM
To: Beierl, Mark <mark.bei...@dell.com>; Alec Hothan (ahothan) 
<ahot...@cisco.com>
Cc: opnfv-tech-discuss@lists.opnfv.org
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: 
<opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>>
 on behalf of "Beierl, Mark" <mark.bei...@dell.com<mailto:mark.bei...@dell.com>>
Date: Monday, 10 July 2017 at 18:10
To: "Alec Hothan (ahothan)" <ahot...@cisco.com<mailto:ahot...@cisco.com>>
Cc: 
"opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>" 
<opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>>
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 pr

Re: [opnfv-tech-discuss] Multiple docker containers from one project

2017-07-11 Thread Jose Lausuch
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

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.

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.


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.


Regards,
Jose


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Fatih 
Degirmenci ARG BRANCH=master
Sent: Monday, July 10, 2017 18:24 PM
To: Beierl, Mark <mark.bei...@dell.com>; Alec Hothan (ahothan) 
<ahot...@cisco.com>
Cc: opnfv-tech-discuss@lists.opnfv.org
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: 
<opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>>
 on behalf of "Beierl, Mark" <mark.bei...@dell.com<mailto:mark.bei...@dell.com>>
Date: Monday, 10 July 2017 at 18:10
To: "Alec Hothan (ahothan)" <ahot...@cisco.com<mailto:ahot...@cisco.com>>
Cc: 
"opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>" 
<opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>>
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
mark.bei...@dell.com<mailto:mark.bei...@dell.com>

On Jul 10, 2017, at 11:34, Alec Hothan (ahothan) 
<ahot...@cisco.com<mailto:ahot...@cisco.com>> 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="sta

Re: [opnfv-tech-discuss] Multiple docker containers from one project

2017-07-10 Thread Fatih Degirmenci
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: <opnfv-tech-discuss-boun...@lists.opnfv.org> on behalf of "Beierl, Mark" 
<mark.bei...@dell.com>
Date: Monday, 10 July 2017 at 18:10
To: "Alec Hothan (ahothan)" <ahot...@cisco.com>
Cc: "opnfv-tech-discuss@lists.opnfv.org" <opnfv-tech-discuss@lists.opnfv.org>
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
mark.bei...@dell.com<mailto:mark.bei...@dell.com>

On Jul 10, 2017, at 11:34, Alec Hothan (ahothan) 
<ahot...@cisco.com<mailto:ahot...@cisco.com>> 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. 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: 
<opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>>
 on behalf of Cedric OLLIVIER 
<ollivier.ced...@gmail.com<mailto:ollivier.ced...@gmail.com>>
Date: Monday, July 10, 2017 at 12:20 AM
To: "Beierl, Mark" <mark.bei...@dell.com<mailto:mark.bei...@dell.com>>
Cc: 
"opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>" 
<opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>>
Subject: Re: [opnfv-te

Re: [opnfv-tech-discuss] Multiple docker containers from one project

2017-07-10 Thread Beierl, Mark
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
mark.bei...@dell.com<mailto:mark.bei...@dell.com>

On Jul 10, 2017, at 11:34, Alec Hothan (ahothan) 
<ahot...@cisco.com<mailto:ahot...@cisco.com>> 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. 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: 
<opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>>
 on behalf of Cedric OLLIVIER 
<ollivier.ced...@gmail.com<mailto:ollivier.ced...@gmail.com>>
Date: Monday, July 10, 2017 at 12:20 AM
To: "Beierl, Mark" <mark.bei...@dell.com<mailto:mark.bei...@dell.com>>
Cc: 
"opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>" 
<opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>>
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 
<mark.bei...@dell.com<mailto:mark.bei...@dell.com>>:
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
mark.bei...@dell.com<mailto:mark.bei...@dell.com>

On Jul 9, 2017, at 21:00, Cedric OLLIVIER 
<ollivier.ced...@gmail.com<mailto:ollivier.ced...@gmail.com>> 

Re: [opnfv-tech-discuss] Multiple docker containers from one project

2017-07-10 Thread Alec Hothan (ahothan)

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. 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: <opnfv-tech-discuss-boun...@lists.opnfv.org> on behalf of Cedric OLLIVIER 
<ollivier.ced...@gmail.com>
Date: Monday, July 10, 2017 at 12:20 AM
To: "Beierl, Mark" <mark.bei...@dell.com>
Cc: "opnfv-tech-discuss@lists.opnfv.org" <opnfv-tech-discuss@lists.opnfv.org>
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 
<mark.bei...@dell.com<mailto:mark.bei...@dell.com>>:
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
mark.bei...@dell.com<mailto:mark.bei...@dell.com>

On Jul 9, 2017, at 21:00, Cedric OLLIVIER 
<ollivier.ced...@gmail.com<mailto:ollivier.ced...@gmail.com>> 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 
<mark.bei...@dell.com<mailto:mark.bei...@dell.com>>:
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
mark.bei...@dell.com<mailto:mark.bei...@dell.com>

On Jul 9, 2017, at 19:03, Julien 
<julien...@gmail.com<mailto:julien...@gmail.com>> wrote:
Hi Cédric,

Patch in  https://gerrit.opnfv.org/gerrit/#/c/36963/ is exact what I mean. 
Let's collect the opinions f

Re: [opnfv-tech-discuss] Multiple docker containers from one project

2017-07-10 Thread Cedric OLLIVIER
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 <mark.bei...@dell.com>:

> 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 <1-613-314-8106>
> mark.bei...@dell.com
>
> On Jul 9, 2017, at 21:00, Cedric OLLIVIER <ollivier.ced...@gmail.com>
> 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 <mark.bei...@dell.com>:
>
>> 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 <1-613-314-8106>
>> mark.bei...@dell.com
>>
>> On Jul 9, 2017, at 19:03, Julien <julien...@gmail.com> 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 <ollivier.ced...@gmail.com>于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 <julien...@gmail.com>:
>>>
>>>> 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 <mark.bei...@dell.com>于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 <1-613-314-8106>
>>>>> mark.bei...@dell.com
>>>>>
>>>>> On Jul 7, 2017, at 11:01, Xuan Jia <jason.jiax...@gmail.com> wrote:
>>>>>
>>>>> +1 Using build service from docker-hub
>>>>>
>>>>>
>>>>> On Thu, Jul 6, 2017 at 11:42 PM, Yujun Zhang (ZTE) <
>>>>> zhangyujun+...@gmail.com> wrote:
>>>>>
>>>>>> Does anybody consider using the build service from docker-hub[1] ?
>>>>>>
>>>>>> It supports multiple Dockerfile from same repository and

Re: [opnfv-tech-discuss] Multiple docker containers from one project

2017-07-09 Thread Julien
Hi Mark,

Yes, there may be some some configuration files or entry point shell file
in the sub-directory. We can keep in the same sub-directory and it can be
supported well.

Can you list some use case for the docker to contain other files in
parents' directory? Maybe it also can be supported during the bootup time.


Beierl, Mark <mark.bei...@dell.com>于2017年7月10日周一 上午7:26写道:

> 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 <1-613-314-8106>
> mark.bei...@dell.com
>
> On Jul 9, 2017, at 19:03, Julien <julien...@gmail.com> 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 <ollivier.ced...@gmail.com>于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 <julien...@gmail.com>:
>>
>>> 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 <mark.bei...@dell.com>于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 <1-613-314-8106>
>>>> mark.bei...@dell.com
>>>>
>>>> On Jul 7, 2017, at 11:01, Xuan Jia <jason.jiax...@gmail.com> wrote:
>>>>
>>>> +1 Using build service from docker-hub
>>>>
>>>>
>>>> On Thu, Jul 6, 2017 at 11:42 PM, Yujun Zhang (ZTE) <
>>>> zhangyujun+...@gmail.com> 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 <
>>>>> jose.laus...@ericsson.com> 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:mark.bei...@dell.com]
>>>>>> *Sent:* Thursday, July 06, 2017 16:18 PM
>>>>>> *To:* opnfv-tech-discuss@lists.opnfv.org
>>>>>> *Cc:* Julien <julien...@gmail.com>; Fatih Degirmenci <
>>>>>> fatih.degirme...@ericsson.com>; Jose Lausuch <
>>>>>> jose.laus...@ericsson.com>
>>>>>> *Subject:* Re: [opnfv-tech

Re: [opnfv-tech-discuss] Multiple docker containers from one project

2017-07-09 Thread Beierl, Mark
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
mark.bei...@dell.com<mailto:mark.bei...@dell.com>

On Jul 9, 2017, at 21:00, Cedric OLLIVIER 
<ollivier.ced...@gmail.com<mailto:ollivier.ced...@gmail.com>> 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 
<mark.bei...@dell.com<mailto:mark.bei...@dell.com>>:
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
mark.bei...@dell.com<mailto:mark.bei...@dell.com>

On Jul 9, 2017, at 19:03, Julien 
<julien...@gmail.com<mailto:julien...@gmail.com>> 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 
<ollivier.ced...@gmail.com<mailto:ollivier.ced...@gmail.com>>于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 
<julien...@gmail.com<mailto:julien...@gmail.com>>:
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 <mark.bei...@dell.com<mailto:mark.bei...@dell.com>>于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
mark.bei...@dell.com<mailto:mark.bei...@dell.com>

On Jul 7, 2017, at 11:01, Xuan Jia 
<jason.jiax...@gmail.com<mailto:jason.jiax...@gmail.com>> wrote:

+1 Using build service from docker-hub

On Thu, Jul 6, 2017 at 11:42 PM, Yujun Zhang (ZTE) 
<zhangyujun+...@gmail.com<mailto:zhangyujun+...@gmail.com>> 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 
<jose.laus...@ericsson.com<mailto:jose.laus...@ericsson.com>> 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:mark.bei...@dell.com<mailto:mark.bei...@dell.com>]
Sent: Thursday, July 06, 2017 16:18 PM
To: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Cc: Julien <julien...@gmail.com<mailto:julien...@gmail.com>>; Fatih Degirmenci 
<fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com>>; Jose 
Lausuch <jose.laus...@ericsson.com<mailto:jose.laus...@ericsson.com>>
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 Syste

Re: [opnfv-tech-discuss] Multiple docker containers from one project

2017-07-09 Thread Cedric OLLIVIER
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 <mark.bei...@dell.com>:

> 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 <1-613-314-8106>
> mark.bei...@dell.com
>
> On Jul 9, 2017, at 19:03, Julien <julien...@gmail.com> 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 <ollivier.ced...@gmail.com>于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 <julien...@gmail.com>:
>>
>>> 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 <mark.bei...@dell.com>于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 <1-613-314-8106>
>>>> mark.bei...@dell.com
>>>>
>>>> On Jul 7, 2017, at 11:01, Xuan Jia <jason.jiax...@gmail.com> wrote:
>>>>
>>>> +1 Using build service from docker-hub
>>>>
>>>>
>>>> On Thu, Jul 6, 2017 at 11:42 PM, Yujun Zhang (ZTE) <
>>>> zhangyujun+...@gmail.com> 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 <
>>>>> jose.laus...@ericsson.com> 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:mark.bei...@dell.com]
>>>>>> *Sent:* Thursday, July 06, 2017 16:18 PM
>>>>>> *To:* opnfv-tech-discuss@lists.opnfv.org
>>>>>> *Cc:* Julien <julien...@gmail.com>; Fatih Degirmenci <
>>>>>> fatih.degirme...@ericsson.com>; Jose Lausuch <

Re: [opnfv-tech-discuss] Multiple docker containers from one project

2017-07-09 Thread Beierl, Mark
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
mark.bei...@dell.com<mailto:mark.bei...@dell.com>

On Jul 9, 2017, at 19:03, Julien 
<julien...@gmail.com<mailto:julien...@gmail.com>> 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 
<ollivier.ced...@gmail.com<mailto:ollivier.ced...@gmail.com>>于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 
<julien...@gmail.com<mailto:julien...@gmail.com>>:
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 <mark.bei...@dell.com<mailto:mark.bei...@dell.com>>于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
mark.bei...@dell.com<mailto:mark.bei...@dell.com>

On Jul 7, 2017, at 11:01, Xuan Jia 
<jason.jiax...@gmail.com<mailto:jason.jiax...@gmail.com>> wrote:

+1 Using build service from docker-hub

On Thu, Jul 6, 2017 at 11:42 PM, Yujun Zhang (ZTE) 
<zhangyujun+...@gmail.com<mailto:zhangyujun+...@gmail.com>> 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 
<jose.laus...@ericsson.com<mailto:jose.laus...@ericsson.com>> 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:mark.bei...@dell.com<mailto:mark.bei...@dell.com>]
Sent: Thursday, July 06, 2017 16:18 PM
To: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Cc: Julien <julien...@gmail.com<mailto:julien...@gmail.com>>; Fatih Degirmenci 
<fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com>>; Jose 
Lausuch <jose.laus...@ericsson.com<mailto:jose.laus...@ericsson.com>>
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
mark.bei...@dell.com<mailto:mark.bei...@dell.com>

On Jun 24, 2017, at 04:05, Jose Lausuch 
<jose.laus...@ericsson.com<mailto:jose.laus...@ericsson.com>> 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 
<julien...@gmail.com<mailto:julien...@gmail.com>> 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.



Fatih Degirmenci 
<fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com>>于2017年6月21日周三
 上午2:26写道:
Hi Mark,

It is perfectly fine to have different build processes and/or number of 
artifact

Re: [opnfv-tech-discuss] Multiple docker containers from one project

2017-07-09 Thread Julien
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 <ollivier.ced...@gmail.com>于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 <julien...@gmail.com>:
>
>> 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 <mark.bei...@dell.com>于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 <1-613-314-8106>
>>> mark.bei...@dell.com
>>>
>>> On Jul 7, 2017, at 11:01, Xuan Jia <jason.jiax...@gmail.com> wrote:
>>>
>>> +1 Using build service from docker-hub
>>>
>>>
>>> On Thu, Jul 6, 2017 at 11:42 PM, Yujun Zhang (ZTE) <
>>> zhangyujun+...@gmail.com> 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 <jose.laus...@ericsson.com>
>>>> 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:mark.bei...@dell.com]
>>>>> *Sent:* Thursday, July 06, 2017 16:18 PM
>>>>> *To:* opnfv-tech-discuss@lists.opnfv.org
>>>>> *Cc:* Julien <julien...@gmail.com>; Fatih Degirmenci <
>>>>> fatih.degirme...@ericsson.com>; Jose Lausuch <
>>>>> jose.laus...@ericsson.com>
>>>>> *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
>>>>&

Re: [opnfv-tech-discuss] Multiple docker containers from one project

2017-07-09 Thread Cedric OLLIVIER
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 <julien...@gmail.com>:

> 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 <mark.bei...@dell.com>于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 <1-613-314-8106>
>> mark.bei...@dell.com
>>
>> On Jul 7, 2017, at 11:01, Xuan Jia <jason.jiax...@gmail.com> wrote:
>>
>> +1 Using build service from docker-hub
>>
>>
>> On Thu, Jul 6, 2017 at 11:42 PM, Yujun Zhang (ZTE) <
>> zhangyujun+...@gmail.com> 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 <jose.laus...@ericsson.com>
>>> 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:mark.bei...@dell.com]
>>>> *Sent:* Thursday, July 06, 2017 16:18 PM
>>>> *To:* opnfv-tech-discuss@lists.opnfv.org
>>>> *Cc:* Julien <julien...@gmail.com>; Fatih Degirmenci <
>>>> fatih.degirme...@ericsson.com>; Jose Lausuch <jose.laus...@ericsson.com
>>>> >
>>>> *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 <1-613-314-8106>
>>>>
>>>> *mark.bei...@dell.com <mark.bei...@dell.com>*
>>>>
>>>>
>>>>
>>>> On Jun 24, 2017, at 04:05, Jose Lausuch <jose.laus...@ericsson.com>
>>>> 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 

Re: [opnfv-tech-discuss] Multiple docker containers from one project

2017-07-09 Thread Julien
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 <mark.bei...@dell.com>于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 <1-613-314-8106>
> mark.bei...@dell.com
>
> On Jul 7, 2017, at 11:01, Xuan Jia <jason.jiax...@gmail.com> wrote:
>
> +1 Using build service from docker-hub
>
>
> On Thu, Jul 6, 2017 at 11:42 PM, Yujun Zhang (ZTE) <
> zhangyujun+...@gmail.com> 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 <jose.laus...@ericsson.com>
>> 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:mark.bei...@dell.com]
>>> *Sent:* Thursday, July 06, 2017 16:18 PM
>>> *To:* opnfv-tech-discuss@lists.opnfv.org
>>> *Cc:* Julien <julien...@gmail.com>; Fatih Degirmenci <
>>> fatih.degirme...@ericsson.com>; Jose Lausuch <jose.laus...@ericsson.com>
>>> *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 <1-613-314-8106>
>>>
>>> *mark.bei...@dell.com <mark.bei...@dell.com>*
>>>
>>>
>>>
>>> On Jun 24, 2017, at 04:05, Jose Lausuch <jose.laus...@ericsson.com>
>>> 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 <julien...@gmail.com> 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.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Fatih Degirmenci <fatih.degirme...@ericsson.com>于2017年6月21日周三 上午2:26写道:
>>>
>>> Hi Mark,
>>>
>>>
>

Re: [opnfv-tech-discuss] Multiple docker containers from one project

2017-07-07 Thread Beierl, Mark
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
mark.bei...@dell.com<mailto:mark.bei...@dell.com>

On Jul 7, 2017, at 11:01, Xuan Jia 
<jason.jiax...@gmail.com<mailto:jason.jiax...@gmail.com>> wrote:

+1 Using build service from docker-hub

On Thu, Jul 6, 2017 at 11:42 PM, Yujun Zhang (ZTE) 
<zhangyujun+...@gmail.com<mailto:zhangyujun+...@gmail.com>> 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 
<jose.laus...@ericsson.com<mailto:jose.laus...@ericsson.com>> 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:mark.bei...@dell.com<mailto:mark.bei...@dell.com>]
Sent: Thursday, July 06, 2017 16:18 PM
To: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Cc: Julien <julien...@gmail.com<mailto:julien...@gmail.com>>; Fatih Degirmenci 
<fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com>>; Jose 
Lausuch <jose.laus...@ericsson.com<mailto:jose.laus...@ericsson.com>>
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
mark.bei...@dell.com<mailto:mark.bei...@dell.com>

On Jun 24, 2017, at 04:05, Jose Lausuch 
<jose.laus...@ericsson.com<mailto:jose.laus...@ericsson.com>> 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 
<julien...@gmail.com<mailto:julien...@gmail.com>> 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.



Fatih Degirmenci 
<fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com>>于2017年6月21日周三
 上午2:26写道:
Hi Mark,

It is perfectly fine to have different build processes and/or number of 
artifacts for the projects from releng point of view.

Once you decide what to do for storperf, we can take a look and adapt docker 
build job/script to build storperf images, create additional repos on docker 
hub to push images and activate the builds when things are ready.

/Fatih

On 20 Jun 2017, at 19:18, Beierl, Mark 
<mark.bei...@dell.com<mailto:mark.bei...@dell.com>> wrote:
Hello,

I'd like to poll the various groups about ideas for how to handle this 
scenario.  I have interns working on breaking down services from StorPerf into 
different containers.  In one case, it will be a simple docker compose that is 
used to fire up existing containers from the repos, but the other case requires 
more thought.

We are creating a second container (storperf-reporting) that will need to be 
built and pushed to hub.docker.com<http://hub.docker.com/>.  Right now the 
build process for docker images lives in releng, and it only allows for one 
image to be built.  Should I be requesting a second git repo in this case, or 
should we look at changing the releng process to allow multiple docker images 
to be build?

Regards,
Mark

Mark Beierl
SW System Sr Principal Engineer
Dell EMC | Office of the CTO
mobile +1 613 314 8106
mark.bei...@dell.com<mailto:mark.bei...@dell.com>

___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
___
opnfv-t

Re: [opnfv-tech-discuss] Multiple docker containers from one project

2017-07-07 Thread Alec Hothan (ahothan)

+1 for the central file managed by releng with (unfrequent) changes submitted 
through gerrit (this is similar to how many openstack releng features work).
Overall, allowing projects to build more than 1 docker container is a nice 
addition.

With regard to versioning, is there a document describing how container 
versioning works? How do project owners track a container image (with the given 
Docker tag such as “danube.1.0”) to a particular git commit or tag? How often 
are containers rebuilt, or can they be rebuilt on demand by project owner?
For example, once Danube 3.0 is out, how can a project owner push out a newer 
version of a container (for example to fix a bug)?

Thanks

  Alec


From: <opnfv-tech-discuss-boun...@lists.opnfv.org> on behalf of Jose Lausuch 
<jose.laus...@ericsson.com>
Date: Friday, July 7, 2017 at 1:14 AM
To: "Chigang (Justin)" <chig...@huawei.com>, "Yujun Zhang (ZTE)" 
<zhangyujun+...@gmail.com>, "Beierl, Mark" <mark.bei...@dell.com>, 
"opnfv-tech-discuss@lists.opnfv.org" <opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] Multiple docker containers from one project

Hi Mark,

I wonder if that docker-list.txt should be located in each project’s repo... I 
know you want to avoid having patches in Releng and have the control in your 
repo, but I think that is the purpose of Release engineering :)

Also, that file is useless without the Releng mechanism, so if I clone Storperf 
and see that file in there, I won’t understand the purpose of as it isn’t 
really part of storperf framework/code... it can’t work without OPNFV CI.

The idea is good, but we could try to move that logic to Releng. For example, 
something like this:
http://paste.openstack.org/raw/614708/

Projects do not add new Dockerfiles so often, so it won’t really be a burden to 
put that file in a central place. Besides, it also exposes visibility to what 
all the projects are building.

For those Dockerfiles that are .patch we have to pay special attention as they 
can’t be built as is, but that logic can be done in the docker script.


/Jose



From: Chigang (Justin) [mailto:chig...@huawei.com]
Sent: Friday, July 07, 2017 09:02 AM
To: Yujun Zhang (ZTE) <zhangyujun+...@gmail.com>; Jose Lausuch 
<jose.laus...@ericsson.com>; Beierl, Mark <mark.bei...@dell.com>; 
opnfv-tech-discuss@lists.opnfv.org
Subject: 答复: [opnfv-tech-discuss] Multiple docker containers from one project

+1

We have used automated build  docker images in  docker hub account[1]. But each 
github repository just builds a docker image.
If it is supported, it will be great.

Regards
Justin

https://hub.docker.com/search/?isAutomated=0=0=1=0=Compass4nfv=0


发件人: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] 代表 Yujun Zhang (ZTE)
发送时间: 2017年7月6日 23:42
收件人: Jose Lausuch; Beierl, Mark; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
主题: Re: [opnfv-tech-discuss] Multiple docker containers from one project

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 
<jose.laus...@ericsson.com<mailto:jose.laus...@ericsson.com>> 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:mark.bei...@dell.com<mailto:mark.bei...@dell.com>]
Sent: Thursday, July 06, 2017 16:18 PM
To: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Cc: Julien <julien...@gmail.com<mailto:julien...@gmail.com>>; Fatih Degirmenci 
<fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com>>; Jose 
Lausuch <jose.laus...@ericsson.com<mailto:jose.laus...@ericsson.com>>
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
mark.bei...@dell.com<mailto:mark.bei...@dell.com>

On Jun 24, 2017, at 04:05, Jose Lausuch 
<jose.laus...@ericsson.com<mailto:jose.laus...@ericsson.com>> wrote:

+1

No need for an additional

Re: [opnfv-tech-discuss] Multiple docker containers from one project

2017-07-07 Thread Jose Lausuch
Hi Mark,

I wonder if that docker-list.txt should be located in each project’s repo... I 
know you want to avoid having patches in Releng and have the control in your 
repo, but I think that is the purpose of Release engineering :)

Also, that file is useless without the Releng mechanism, so if I clone Storperf 
and see that file in there, I won’t understand the purpose of as it isn’t 
really part of storperf framework/code... it can’t work without OPNFV CI.

The idea is good, but we could try to move that logic to Releng. For example, 
something like this:
http://paste.openstack.org/raw/614708/

Projects do not add new Dockerfiles so often, so it won’t really be a burden to 
put that file in a central place. Besides, it also exposes visibility to what 
all the projects are building.

For those Dockerfiles that are .patch we have to pay special attention as they 
can’t be built as is, but that logic can be done in the docker script.


/Jose



From: Chigang (Justin) [mailto:chig...@huawei.com]
Sent: Friday, July 07, 2017 09:02 AM
To: Yujun Zhang (ZTE) <zhangyujun+...@gmail.com>; Jose Lausuch 
<jose.laus...@ericsson.com>; Beierl, Mark <mark.bei...@dell.com>; 
opnfv-tech-discuss@lists.opnfv.org
Subject: 答复: [opnfv-tech-discuss] Multiple docker containers from one project

+1

We have used automated build  docker images in  docker hub account[1]. But each 
github repository just builds a docker image.
If it is supported, it will be great.

Regards
Justin

https://hub.docker.com/search/?isAutomated=0=0=1=0=Compass4nfv=0


发件人: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] 代表 Yujun Zhang (ZTE)
发送时间: 2017年7月6日 23:42
收件人: Jose Lausuch; Beierl, Mark; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
主题: Re: [opnfv-tech-discuss] Multiple docker containers from one project

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 
<jose.laus...@ericsson.com<mailto:jose.laus...@ericsson.com>> 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:mark.bei...@dell.com<mailto:mark.bei...@dell.com>]
Sent: Thursday, July 06, 2017 16:18 PM
To: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Cc: Julien <julien...@gmail.com<mailto:julien...@gmail.com>>; Fatih Degirmenci 
<fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com>>; Jose 
Lausuch <jose.laus...@ericsson.com<mailto:jose.laus...@ericsson.com>>
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
mark.bei...@dell.com<mailto:mark.bei...@dell.com>

On Jun 24, 2017, at 04:05, Jose Lausuch 
<jose.laus...@ericsson.com<mailto:jose.laus...@ericsson.com>> 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 
<julien...@gmail.com<mailto:julien...@gmail.com>> 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.



Fatih Degirmenci 
<fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com>>于2017年6月21日周三
 上午2:26写道:
Hi Mark,

It is perfectly fine to have different build processes and/or number of 
artifacts for the projects from releng point of view.

Once you decide what to do for storperf, we can take a look and adapt docker 
build job/script to build storperf images, create additional repos on docker 
hub to push images and activate the builds when things are ready.

/Fatih

On 20 Jun 2017, at 19:18, Beierl, Mark 
<mark.bei...@dell.com<mailto:mark.bei...@dell.com>> wrote:
Hello,

I'd like to poll the various groups about ideas for how to handle this 
scenario.  I have interns wo

Re: [opnfv-tech-discuss] Multiple docker containers from one project

2017-07-06 Thread Beierl, Mark
Hello,

I have proposed the following patch [1].  It respects backward compatibility in 
that if there is no file in the project called "docker/docker-list.txt" it 
behaves identically to the existing code.

If there is a file called docker/docker-list.txt, it iterates over the newline 
delimited contents as follows:


  1.  If there is an entry: docker/Dockerfile, it executes identically to the 
existing code
  2.  If there is an entry: any-other-path/Dockerfile-othername, it cd to 
any-other-path and build Dockerfile-othername, and push its image to 
project-othername as "opnfv/project-othername".  So 
storperf/reporting/docker/Dockerfile-reporting will cause a new image to be 
pushed which is named "opnfv/storperf-reporting"

Please, comments, suggestions, criticism, anything, is more than welcome!

[1] https://gerrit.opnfv.org/gerrit/#/c/37041

Regards,
Mark

Mark Beierl
SW System Sr Principal Engineer
Dell EMC | Office of the CTO
mobile +1 613 314 8106
mark.bei...@dell.com<mailto:mark.bei...@dell.com>

On Jul 6, 2017, at 11:42, Yujun Zhang (ZTE) 
<zhangyujun+...@gmail.com<mailto:zhangyujun+...@gmail.com>> 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 
<jose.laus...@ericsson.com<mailto:jose.laus...@ericsson.com>> 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:mark.bei...@dell.com<mailto:mark.bei...@dell.com>]
Sent: Thursday, July 06, 2017 16:18 PM
To: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Cc: Julien <julien...@gmail.com<mailto:julien...@gmail.com>>; Fatih Degirmenci 
<fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com>>; Jose 
Lausuch <jose.laus...@ericsson.com<mailto:jose.laus...@ericsson.com>>
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
mark.bei...@dell.com<mailto:mark.bei...@dell.com>

On Jun 24, 2017, at 04:05, Jose Lausuch 
<jose.laus...@ericsson.com<mailto:jose.laus...@ericsson.com>> 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 
<julien...@gmail.com<mailto:julien...@gmail.com>> 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.



Fatih Degirmenci 
<fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com>>于2017年6月21日周三
 上午2:26写道:
Hi Mark,

It is perfectly fine to have different build processes and/or number of 
artifacts for the projects from releng point of view.

Once you decide what to do for storperf, we can take a look and adapt docker 
build job/script to build storperf images, create additional repos on docker 
hub to push images and activate the builds when things are ready.

/Fatih

On 20 Jun 2017, at 19:18, Beierl, Mark 
<mark.bei...@dell.com<mailto:mark.bei...@dell.com>> wrote:
Hello,

I'd like to poll the various groups about ideas for how to handle this 
scenario.  I have interns working on breaking down services from StorPerf into 
different containers.  In one case, it will be a simple docker compose that is 
used to fire up existing containers from the repos, but the other case requires 
more thought.

We are creating a second container (storperf-reporting) that will need to be 
built and pushed to hub.docker.com<http://hub.docker.com/>.  Right now the 
build process for docker images lives in releng, and it only allows for one 
image to be built.  Should I be requesting a second git repo in this case, or 
should we look at changing the releng process to allow multiple docker images 
to be build?

Regards,
Mark

Mark Beierl
SW System Sr Principal Engineer
Dell EMC | Office of the CTO
mobile +1 613 314 8106
mark.bei...@dell.com<

Re: [opnfv-tech-discuss] Multiple docker containers from one project

2017-07-06 Thread Yujun Zhang (ZTE)
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 <jose.laus...@ericsson.com>
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:mark.bei...@dell.com]
> *Sent:* Thursday, July 06, 2017 16:18 PM
> *To:* opnfv-tech-discuss@lists.opnfv.org
> *Cc:* Julien <julien...@gmail.com>; Fatih Degirmenci <
> fatih.degirme...@ericsson.com>; Jose Lausuch <jose.laus...@ericsson.com>
> *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 <1-613-314-8106>
>
> *mark.bei...@dell.com <mark.bei...@dell.com>*
>
>
>
> On Jun 24, 2017, at 04:05, Jose Lausuch <jose.laus...@ericsson.com> 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 <julien...@gmail.com> 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.
>
>
>
>
>
>
>
> Fatih Degirmenci <fatih.degirme...@ericsson.com>于2017年6月21日周三 上午2:26写道:
>
> Hi Mark,
>
>
>
> It is perfectly fine to have different build processes and/or number of
> artifacts for the projects from releng point of view.
>
>
>
> Once you decide what to do for storperf, we can take a look and adapt
> docker build job/script to build storperf images, create additional repos
> on docker hub to push images and activate the builds when things are ready.
>
>
> /Fatih
>
>
> On 20 Jun 2017, at 19:18, Beierl, Mark <mark.bei...@dell.com> wrote:
>
> Hello,
>
>
>
> I'd like to poll the various groups about ideas for how to handle this
> scenario.  I have interns working on breaking down services from StorPerf
> into different containers.  In one case, it will be a simple docker compose
> that is used to fire up existing containers from the repos, but the other
> case requires more thought.
>
>
>
> We are creating a second container (storperf-reporting) that will need to
> be built and pushed to hub.docker.com.  Right now the build process for
> docker images lives in releng, and it only allows for one image to be
> built.  Should I be requesting a second git repo in this case, or should we
> look at changing the releng process to allow multiple docker images to be
> build?
>
>
>
> Regards,
>
> Mark
>
>
>
> *Mark Beierl*
>
> SW System Sr Principal Engineer
>
> *Dell **EMC* | Office of the CTO
>
> mobile +1 613 314 8106 <1-613-314-8106>
>
> *mark.bei...@dell.com <mark.bei...@dell.com>*
>
>
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
>
>
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss


Re: [opnfv-tech-discuss] Multiple docker containers from one project

2017-07-06 Thread Jose Lausuch
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:mark.bei...@dell.com]
Sent: Thursday, July 06, 2017 16:18 PM
To: opnfv-tech-discuss@lists.opnfv.org
Cc: Julien <julien...@gmail.com>; Fatih Degirmenci 
<fatih.degirme...@ericsson.com>; Jose Lausuch <jose.laus...@ericsson.com>
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
mark.bei...@dell.com<mailto:mark.bei...@dell.com>

On Jun 24, 2017, at 04:05, Jose Lausuch 
<jose.laus...@ericsson.com<mailto:jose.laus...@ericsson.com>> 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 
<julien...@gmail.com<mailto:julien...@gmail.com>> 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.



Fatih Degirmenci 
<fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com>>于2017年6月21日周三
 上午2:26写道:
Hi Mark,

It is perfectly fine to have different build processes and/or number of 
artifacts for the projects from releng point of view.

Once you decide what to do for storperf, we can take a look and adapt docker 
build job/script to build storperf images, create additional repos on docker 
hub to push images and activate the builds when things are ready.

/Fatih

On 20 Jun 2017, at 19:18, Beierl, Mark 
<mark.bei...@dell.com<mailto:mark.bei...@dell.com>> wrote:
Hello,

I'd like to poll the various groups about ideas for how to handle this 
scenario.  I have interns working on breaking down services from StorPerf into 
different containers.  In one case, it will be a simple docker compose that is 
used to fire up existing containers from the repos, but the other case requires 
more thought.

We are creating a second container (storperf-reporting) that will need to be 
built and pushed to hub.docker.com<http://hub.docker.com/>.  Right now the 
build process for docker images lives in releng, and it only allows for one 
image to be built.  Should I be requesting a second git repo in this case, or 
should we look at changing the releng process to allow multiple docker images 
to be build?

Regards,
Mark

Mark Beierl
SW System Sr Principal Engineer
Dell EMC | Office of the CTO
mobile +1 613 314 8106
mark.bei...@dell.com<mailto:mark.bei...@dell.com>

___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss


___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss


Re: [opnfv-tech-discuss] Multiple docker containers from one project

2017-06-24 Thread Jose Lausuch
+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 
> 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.



Fatih Degirmenci 
>于2017年6月21日周三
 上午2:26写道:
Hi Mark,

It is perfectly fine to have different build processes and/or number of 
artifacts for the projects from releng point of view.

Once you decide what to do for storperf, we can take a look and adapt docker 
build job/script to build storperf images, create additional repos on docker 
hub to push images and activate the builds when things are ready.

/Fatih

On 20 Jun 2017, at 19:18, Beierl, Mark 
> wrote:

Hello,

I'd like to poll the various groups about ideas for how to handle this 
scenario.  I have interns working on breaking down services from StorPerf into 
different containers.  In one case, it will be a simple docker compose that is 
used to fire up existing containers from the repos, but the other case requires 
more thought.

We are creating a second container (storperf-reporting) that will need to be 
built and pushed to hub.docker.com.  Right now the 
build process for docker images lives in releng, and it only allows for one 
image to be built.  Should I be requesting a second git repo in this case, or 
should we look at changing the releng process to allow multiple docker images 
to be build?

Regards,
Mark

Mark Beierl
SW System Sr Principal Engineer
Dell EMC | Office of the CTO
mobile +1 613 314 8106
mark.bei...@dell.com

___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss


Re: [opnfv-tech-discuss] Multiple docker containers from one project

2017-06-23 Thread Julien
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.



Fatih Degirmenci 于2017年6月21日周三 上午2:26写道:

> Hi Mark,
>
> It is perfectly fine to have different build processes and/or number of
> artifacts for the projects from releng point of view.
>
> Once you decide what to do for storperf, we can take a look and adapt
> docker build job/script to build storperf images, create additional repos
> on docker hub to push images and activate the builds when things are ready.
>
> /Fatih
>
> On 20 Jun 2017, at 19:18, Beierl, Mark  wrote:
>
> Hello,
>
> I'd like to poll the various groups about ideas for how to handle this
> scenario.  I have interns working on breaking down services from StorPerf
> into different containers.  In one case, it will be a simple docker compose
> that is used to fire up existing containers from the repos, but the other
> case requires more thought.
>
> We are creating a second container (storperf-reporting) that will need to
> be built and pushed to hub.docker.com.  Right now the build process for
> docker images lives in releng, and it only allows for one image to be
> built.  Should I be requesting a second git repo in this case, or should we
> look at changing the releng process to allow multiple docker images to be
> build?
>
> Regards,
> Mark
>
> *Mark Beierl*
> SW System Sr Principal Engineer
> *Dell **EMC* | Office of the CTO
> mobile +1 613 314 8106 <1-613-314-8106>
> mark.bei...@dell.com
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss


Re: [opnfv-tech-discuss] Multiple docker containers from one project

2017-06-20 Thread Fatih Degirmenci
Hi Mark,

It is perfectly fine to have different build processes and/or number of 
artifacts for the projects from releng point of view.

Once you decide what to do for storperf, we can take a look and adapt docker 
build job/script to build storperf images, create additional repos on docker 
hub to push images and activate the builds when things are ready.

/Fatih

On 20 Jun 2017, at 19:18, Beierl, Mark  wrote:

Hello,

I'd like to poll the various groups about ideas for how to handle this 
scenario.  I have interns working on breaking down services from StorPerf into 
different containers.  In one case, it will be a simple docker compose that is 
used to fire up existing containers from the repos, but the other case requires 
more thought.

We are creating a second container (storperf-reporting) that will need to be 
built and pushed to hub.docker.com.  Right now the build process for docker 
images lives in releng, and it only allows for one image to be built.  Should I 
be requesting a second git repo in this case, or should we look at changing the 
releng process to allow multiple docker images to be build?

Regards,
Mark

Mark Beierl
SW System Sr Principal Engineer
Dell EMC | Office of the CTO
mobile +1 613 314 8106
mark.bei...@dell.com

___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss


smime.p7s
Description: S/MIME cryptographic signature
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss