I'd say this is a great idea. The only reason we haven't adopt multi-arch is because we started to adopt docker at early stage so there's no such feature then.
Jun can you roughly estimate the effort? If we're going for it, we better have it ready in 1.3.0 before ApacheCon which is around September. 2018-05-17 17:19 GMT+08:00 Naresh Bhat <naresh.b...@linaro.org>: > On 17 May 2018 at 13:21, Jun HE <ryan.j...@gmail.com> wrote: > > Hi, guys, > > > > As bigtop has simplified the way to create docker images for distros, by > > BIGTOP-2922, I'm thinking of multi-arch docker images support to ease > > building/test/development. > > > > Multi-arch feature has been supported since 2017, you may check this > link: > > https://blog.docker.com/2017/11/multi-arch-all-the-things/ > > In simple words, multi-arch is a virtual image which contains several > > architecture dependent images. When user try to pull this virtual image > > dockhub will send back the actual image based on the architecture he is > > using. > > > > Use multi-arch will help: > > * development: user don't have to issue different cmd to pull > puppet/slaves > > images, "docker pull bigtop/slaves:trunk-debian-9" is enough instead of > "docker > > pull bigtop/slaves:trunk-debian-9-ppc64le" or "docker pull > > bigtop/slaves:trunk-debian-9-aarch64" > > * test: unified yaml file for same distro. refer example in > > provisioner/docker/config_* > > > > So how do you think? :) > > Thanks Jun for initiating the thread. > +1 this makes sense. Is there any reason why we have not consider for > using multi-arch images ? If anybody explains advantage/disadvantage > of using multi-arch docker image in bigtop, it will help us to > understand in a better way. > > > > > Regards, > > > > Jun >
