Re: [opnfv-tech-discuss] Arch-specific Docker tags
I think the key point is about using multiple repositories or multiple tags to differenciate the architectures listed in manifests. Multiple repositories (eg: opnfv/functest-core_amd64 & opnfv/functest-core_arm64) are more flexible (stable could be linked to different versions according to the arch) and allows multiple maintainers. But it could break rules about cross repositories. That's why we agreed to multiply tags as storperf did. Cédric 2017-10-13 22:59 GMT+02:00 Cedric OLLIVIER <ollivier.ced...@gmail.com>: > Hello, > > Of course I will vote for 1. > I consider 2 and 3 as false from a Docker point of view. > > Yes we already have published manifests which are suitable solutions > to avoid duplicating Dockerfiles and jenkins jobs. > Let me know if you want much technical details. > > I must precise that the choice done by Storperf can't work for Functest > Most of our containers depend on a parent which oblige to use external > tools instead of releng (they mainly forbid variable in FROM > instructions). > > Cédric > > 2017-10-13 21:50 GMT+02:00 Alexandru Avadanii <alexandru.avada...@enea.com>: >> Hi, Alec, >> >> Thanks for the vote J >> >> That is exactly what Cédric implemented for Functest, using manifests. >> >> >> >> If we are not to duplicate tags (i.e. choose between #1 and #3), I will vote >> for #1 too. >> >> >> >> From: Alec Hothan (ahothan) [mailto:ahot...@cisco.com] >> Sent: Friday, October 13, 2017 9:57 PM >> To: Alexandru Avadanii; TECH-DISCUSS OPNFV >> Subject: Re: [opnfv-tech-discuss] Arch-specific Docker tags >> >> >> >> >> >> I would prefer limiting the number of container images because we’re going >> to have a lot more image versions for some projects (to tackle versioned >> XCI/CD) >> >> So option 2 does not look great for me. >> >> I’d vote for option 1. >> >> >> >> Have you guys looked at support for multi-arch docker images? >> >> I find it really interesting and removes the need for an arch specific tag. >> >> >> >> http://container-solutions.com/multi-arch-docker-images/ >> >> >> >> If we could implement this, that would be even better. >> >> >> >>Alec >> >> >> >> >> >> From: <opnfv-tech-discuss-boun...@lists.opnfv.org> on behalf of Alexandru >> Avadanii <alexandru.avada...@enea.com> >> Date: Friday, October 13, 2017 at 10:04 AM >> To: TECH-DISCUSS OPNFV <opnfv-tech-discuss@lists.opnfv.org> >> Subject: [opnfv-tech-discuss] Arch-specific Docker tags >> >> >> >> Hi, >> >> Cédric pointed out that Docker uses DEB/kernel format for describing the >> architecture of a Docker container. >> >> To align with this, the Functest Docker tags were updated from >> "x86_64-latest"/"aarch64-latest" to "amd64-latest"/"arm64-latest". >> >> >> >> Although the arch-naming convention is not enforced to this format (as long >> as the manifest points for a specific architecture to a specific tag, that >> tag can be named however we want), we agreed that aligning with the Docker >> internal format would be a good idea. >> >> >> >> My personal preference would be to duplicate the tags, and have both >> "x86_64-latest"/"amd64-latest", respectively "aarch64-latest"/"arm64-latest" >> point to the same image. >> >> >> >> Anyway, I think we should agree on a format at the OPNFV-project level, and >> try to use it for all our projects. >> >> >> >> So, for multiarch projects that push Docker images, we have at least 3 >> options: >> >> 1. "amd64"/"arm64" tags, aligning with Docker internal naming (currently >> used by Functest); >> >> 2. "amd64" + "x86_64" / "arm64" + "aarch64"; >> >> 3. "x86_64" / "aarch64" (currently used by Storperf); >> >> >> >> Note that if the project provides a manifest, arch-specific tags are more or >> less hidden from the end-user, and a simple `docker pull >> opnfv/functest-core:latest' (or without a tag) will fetch the image for the >> current system arch automatically (amd64-latest or arm64-latest for >> Functest). >> >> >> >> Thank you, Cédric, for handling this for Functest on such short notice! >> >> >> >> BR, >> >> Alex >> >> ___ >> >> 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] Arch-specific Docker tags
Hello, Of course I will vote for 1. I consider 2 and 3 as false from a Docker point of view. Yes we already have published manifests which are suitable solutions to avoid duplicating Dockerfiles and jenkins jobs. Let me know if you want much technical details. I must precise that the choice done by Storperf can't work for Functest Most of our containers depend on a parent which oblige to use external tools instead of releng (they mainly forbid variable in FROM instructions). Cédric 2017-10-13 21:50 GMT+02:00 Alexandru Avadanii <alexandru.avada...@enea.com>: > Hi, Alec, > > Thanks for the vote J > > That is exactly what Cédric implemented for Functest, using manifests. > > > > If we are not to duplicate tags (i.e. choose between #1 and #3), I will vote > for #1 too. > > > > From: Alec Hothan (ahothan) [mailto:ahot...@cisco.com] > Sent: Friday, October 13, 2017 9:57 PM > To: Alexandru Avadanii; TECH-DISCUSS OPNFV > Subject: Re: [opnfv-tech-discuss] Arch-specific Docker tags > > > > > > I would prefer limiting the number of container images because we’re going > to have a lot more image versions for some projects (to tackle versioned > XCI/CD) > > So option 2 does not look great for me. > > I’d vote for option 1. > > > > Have you guys looked at support for multi-arch docker images? > > I find it really interesting and removes the need for an arch specific tag. > > > > http://container-solutions.com/multi-arch-docker-images/ > > > > If we could implement this, that would be even better. > > > >Alec > > > > > > From: <opnfv-tech-discuss-boun...@lists.opnfv.org> on behalf of Alexandru > Avadanii <alexandru.avada...@enea.com> > Date: Friday, October 13, 2017 at 10:04 AM > To: TECH-DISCUSS OPNFV <opnfv-tech-discuss@lists.opnfv.org> > Subject: [opnfv-tech-discuss] Arch-specific Docker tags > > > > Hi, > > Cédric pointed out that Docker uses DEB/kernel format for describing the > architecture of a Docker container. > > To align with this, the Functest Docker tags were updated from > "x86_64-latest"/"aarch64-latest" to "amd64-latest"/"arm64-latest". > > > > Although the arch-naming convention is not enforced to this format (as long > as the manifest points for a specific architecture to a specific tag, that > tag can be named however we want), we agreed that aligning with the Docker > internal format would be a good idea. > > > > My personal preference would be to duplicate the tags, and have both > "x86_64-latest"/"amd64-latest", respectively "aarch64-latest"/"arm64-latest" > point to the same image. > > > > Anyway, I think we should agree on a format at the OPNFV-project level, and > try to use it for all our projects. > > > > So, for multiarch projects that push Docker images, we have at least 3 > options: > > 1. "amd64"/"arm64" tags, aligning with Docker internal naming (currently > used by Functest); > > 2. "amd64" + "x86_64" / "arm64" + "aarch64"; > > 3. "x86_64" / "aarch64" (currently used by Storperf); > > > > Note that if the project provides a manifest, arch-specific tags are more or > less hidden from the end-user, and a simple `docker pull > opnfv/functest-core:latest' (or without a tag) will fetch the image for the > current system arch automatically (amd64-latest or arm64-latest for > Functest). > > > > Thank you, Cédric, for handling this for Functest on such short notice! > > > > BR, > > Alex > > ___ > > 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] Arch-specific Docker tags
I would prefer limiting the number of container images because we’re going to have a lot more image versions for some projects (to tackle versioned XCI/CD) So option 2 does not look great for me. I’d vote for option 1. Have you guys looked at support for multi-arch docker images? I find it really interesting and removes the need for an arch specific tag. http://container-solutions.com/multi-arch-docker-images/ If we could implement this, that would be even better. Alec From: <opnfv-tech-discuss-boun...@lists.opnfv.org> on behalf of Alexandru Avadanii <alexandru.avada...@enea.com> Date: Friday, October 13, 2017 at 10:04 AM To: TECH-DISCUSS OPNFV <opnfv-tech-discuss@lists.opnfv.org> Subject: [opnfv-tech-discuss] Arch-specific Docker tags Hi, Cédric pointed out that Docker uses DEB/kernel format for describing the architecture of a Docker container. To align with this, the Functest Docker tags were updated from "x86_64-latest"/"aarch64-latest" to "amd64-latest"/"arm64-latest". Although the arch-naming convention is not enforced to this format (as long as the manifest points for a specific architecture to a specific tag, that tag can be named however we want), we agreed that aligning with the Docker internal format would be a good idea. My personal preference would be to duplicate the tags, and have both "x86_64-latest"/"amd64-latest", respectively "aarch64-latest"/"arm64-latest" point to the same image. Anyway, I think we should agree on a format at the OPNFV-project level, and try to use it for all our projects. So, for multiarch projects that push Docker images, we have at least 3 options: 1. "amd64"/"arm64" tags, aligning with Docker internal naming (currently used by Functest); 2. "amd64" + "x86_64" / "arm64" + "aarch64"; 3. "x86_64" / "aarch64" (currently used by Storperf); Note that if the project provides a manifest, arch-specific tags are more or less hidden from the end-user, and a simple `docker pull opnfv/functest-core:latest' (or without a tag) will fetch the image for the current system arch automatically (amd64-latest or arm64-latest for Functest). Thank you, Cédric, for handling this for Functest on such short notice! BR, Alex ___ 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
[opnfv-tech-discuss] Arch-specific Docker tags
Hi, Cédric pointed out that Docker uses DEB/kernel format for describing the architecture of a Docker container. To align with this, the Functest Docker tags were updated from "x86_64-latest"/"aarch64-latest" to "amd64-latest"/"arm64-latest". Although the arch-naming convention is not enforced to this format (as long as the manifest points for a specific architecture to a specific tag, that tag can be named however we want), we agreed that aligning with the Docker internal format would be a good idea. My personal preference would be to duplicate the tags, and have both "x86_64-latest"/"amd64-latest", respectively "aarch64-latest"/"arm64-latest" point to the same image. Anyway, I think we should agree on a format at the OPNFV-project level, and try to use it for all our projects. So, for multiarch projects that push Docker images, we have at least 3 options: 1. "amd64"/"arm64" tags, aligning with Docker internal naming (currently used by Functest); 2. "amd64" + "x86_64" / "arm64" + "aarch64"; 3. "x86_64" / "aarch64" (currently used by Storperf); Note that if the project provides a manifest, arch-specific tags are more or less hidden from the end-user, and a simple `docker pull opnfv/functest-core:latest' (or without a tag) will fetch the image for the current system arch automatically (amd64-latest or arm64-latest for Functest). Thank you, Cédric, for handling this for Functest on such short notice! BR, Alex ___ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
