Currently the architecture field does not used by Docker engine, so the value amd64 also works on ppc64le platform.
Yes, I saw the image was created locally, but it was not used by docker containerizer tests. When I run docker conainerizer tests on ppc64le, it still use the alpine image from Docker hub which is the amd64 architecture, and the tests still failed. So I think if the docker containerizer tests can use the image created in runtime_isolator_tests.cpp, these test cases will not fail on ppc64le platform. So can we also make this local docker image for Docker containerizer testing? Thanks, Zhiwei On Wed, Apr 13, 2016 at 2:02 AM, Gilbert Song <[email protected]> wrote: > Sorry Zhiwei, just see your email. Yes, I can do that. Just for curious, > are you using > the manifest architecture field in ppc64le? > > We already have tests relying on the image created locally. Please see: > runtime_isolator_tests.cpp > > What do you mean by "And could you make it create and load the image > before > running Docker related tests"? The local docker image is for unified > containerizer > testing. It is irrelevant to any test for docker containerizer. > > Cheers, > Gilbert > > On Mon, Apr 11, 2016 at 6:27 PM, zhiwei <[email protected]> wrote: > >> Hi Gilbert, do you have any updates on about this issue? >> >> When will you use the local build Docker image for Docker related testing? >> >> On Mon, Mar 14, 2016 at 9:44 PM, zhiwei <[email protected]> wrote: >> >>> Hi Gibert, >>> >>> I tested your patch, it works on ppc64le, but there is an issue that the >>> architecture in manifest file is hardcode to amd64[1]. >>> >>> This field is currently not used by Docker engine, but I think you can >>> enhance it to use `os.uname().machine` [2]. Or I can submit a patch for >>> this. >>> >>> And could you make it create and load the image before running Docker >>> related tests? >>> >>> [1]: >>> https://github.com/apache/mesos/blob/69b2ad528dd79979a8ee113a8edbbab2669e32e6/src/tests/containerizer/docker_archive.hpp#L150 >>> [2]: >>> https://github.com/docker/distribution/blob/master/docs/spec/manifest-v2-2.md#manifest-list-field-descriptions >>> >>> >>> On Sat, Mar 12, 2016 at 8:45 PM, zhiwei <[email protected]> wrote: >>> >>>> this because the architecture, alpine is x86_64, the power is ppc64le. >>>> >>>> this may help in IBM Power. >>>> On Mar 12, 2016 01:10, "Gilbert Song" <[email protected]> wrote: >>>> >>>>> Hi Zhiwei, >>>>> >>>>> I am trying to understand why 'alpine' is not compatible with IBM Power >>>>> platform. Is it because of the image's rootfs? >>>>> >>>>> We currently have a JIRA( >>>>> https://issues.apache.org/jira/browse/MESOS-4684) >>>>> in progress to create a local docker image, which is used for docker >>>>> runtime isolator local tests. This test image cp the host's linux >>>>> rootfs. >>>>> Does it possibly help in your case? >>>>> >>>>> Cheers, >>>>> Gilbert >>>>> >>>>> On Fri, Mar 11, 2016 at 2:30 AM, zhiwei <[email protected]> wrote: >>>>> >>>>> > Yes, I prefer to create specific mesos test images and make them >>>>> > configurable in configuration file. >>>>> > >>>>> > On Fri, Mar 11, 2016 at 6:20 PM, Alex Rukletsov <[email protected] >>>>> > >>>>> > wrote: >>>>> > >>>>> > > It also looks strange to me that we use "random" containers in >>>>> Mesos >>>>> > tests. >>>>> > > The proper way would be to have "mesos" or "apache" account on >>>>> docker hub >>>>> > > managed by PMC. Do you think it's worth to set up one or it's too >>>>> much >>>>> > time >>>>> > > investment? >>>>> > > >>>>> > > On Thu, Mar 10, 2016 at 12:19 PM, Jan Schlicht <[email protected]> >>>>> > wrote: >>>>> > > >>>>> > > > Hi Zhiwei, >>>>> > > > >>>>> > > > I was thinking about this as well, but for different reasons: >>>>> Pulling >>>>> > in >>>>> > > > Docker images for tests is not the ideal solution. Sure, testing >>>>> a >>>>> > `sleep >>>>> > > > 1000` should work, but testing an executor leaves some questions >>>>> on how >>>>> > > to >>>>> > > > handle changes/deprecation of the interfaces. It's not a >>>>> pressing issue >>>>> > > > right now, but might become one in the future. >>>>> > > > >>>>> > > > I think this is also what Timothy had in mind with his comment >>>>> > (Timothy, >>>>> > > > please correct me if I'm wrong): These problems can be resolved >>>>> by >>>>> > using >>>>> > > > local Docker images, ideally ones that are created during `make >>>>> check`. >>>>> > > But >>>>> > > > this would create new problems. Either we would have to build >>>>> libmesos >>>>> > > > inside our local container -- to be able to build test executors >>>>> -- >>>>> > which >>>>> > > > would take a long time, or we'd have to make sure that the >>>>> container >>>>> > > > environment is the same as the dev environment, to be able to >>>>> copy test >>>>> > > > executors into it, which isn't easy unless we'd restrict >>>>> ourselves to >>>>> > > only >>>>> > > > a couple of environments. >>>>> > > > >>>>> > > > Cheers, >>>>> > > > Jan >>>>> > > > >>>>> > > > On Thu, Mar 10, 2016 at 11:25 AM, zhiwei <[email protected]> >>>>> wrote: >>>>> > > > >>>>> > > > > Hi all, >>>>> > > > > >>>>> > > > > The Docker related test cases that hardcoded "alpine" as the >>>>> Docker >>>>> > > image >>>>> > > > > which caused test cases failed on IBM Power platform, since the >>>>> > Docker >>>>> > > > > image "alpine" is not compatible with IBM Power platform. >>>>> > > > > >>>>> > > > > And I saw an inline comment by Timothy: "// TODO(tnachen): Use >>>>> local >>>>> > > > image >>>>> > > > > to test if possible." >>>>> > > > > >>>>> > > > > So just wonder if someone has plan to implement this, or could >>>>> you >>>>> > give >>>>> > > > me >>>>> > > > > some tips? I can implement this. >>>>> > > > > >>>>> > > > > Following are the images that used in Mesos test cases: >>>>> > > > > >>>>> > > > > 1. alpine >>>>> > > > > 2. mesosphere/alpine-expect >>>>> > > > > 3. mesosphere/inky >>>>> > > > > 4. mesosphere/test-executor >>>>> > > > > 5. tnachen/test-executor >>>>> > > > > >>>>> > > > > >>>>> > > > > Thanks, >>>>> > > > > Zhiwei >>>>> > > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > -- >>>>> > > > *Jan Schlicht* >>>>> > > > Distributed Systems Engineer, Mesosphere >>>>> > > > >>>>> > > >>>>> > >>>>> >>>> >>> >> >
