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<tel: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.<release-version> else it is stable. And lastly the above is overridden to RELEASE_VERSION if RELEASE_VERSION is set and COMMIT_ID is defined (wonder how that works with 2 branches with same RELEASE_VERSION?). There are few gaps that don’t seem to be covered by this versioning - perhaps there is a way that project owners who publish containers work around them? * How are the containers for multiple versions of master at various commits published ? They all seem to have the “master” tag * For a given branch (say Danube), same question for a given release (say for Danube 3.0, one might have multiple versions of a container with various patches) * Some projects may have containers that actually work with multiple OPNFV releases, will they be forced to publish the same container image with different tags (e.g. danube.3.0 and euphrates.1.0)? In general a docker container tag would have version in it (e.g. 3.2.1) and sometimes along with a text describing some classification (indicating for example variations of the same source code version). In the case of OPNFV. I’m not quite sure about when stable is used from the look of the script. I’d be interested to know how current project docker owners deal with the above and if there is any interest to address them. Thanks Alec From: <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<tel: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<tel: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<tel: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<tel: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.
_______________________________________________ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
