[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [atomic-devel] ARM builds?

> -----Original Message-----
> From: SGhosh [mailto:sghosh redhat com]
> Sent: Saturday, August 27, 2016 8:18 AM
> To: Josh Berkus; Jon Stanley; Richard Henwood
> Cc: atomic-devel
> Subject: Re: [atomic-devel] ARM builds?
> On 08/26/2016 06:13 PM, Josh Berkus wrote:
> > On 08/26/2016 11:24 AM, Jon Stanley wrote:
> >> Will kube schedule a container on a host that can't run it? i.e. a
> >> container with x86 code on a AArch64 host, or vice versa? I think
> >> that it needs to DTRT sooner rather than later if the scheduling
> >> isn't smart yet. In the meantime I assume that you could run a
> >> separate cluster of ARM vs. x86, but that would probably be less than
> >> ideal I think. Other thoughts?
> > Oh, I wasn't even thinking of mixed clusters.  Figured it wouldn't be
> > possible.   Also, while I can imagine having an x86 kube-master and a
> > bunch of ARM kubelets, I'm not sure that there's much of a real cases
> > for mix-and-match kubelets.
> >
> In general if you think of a datacenter of mixed architecture, you would want a
> global resource allocator that is architecture aware. Making architecture-
> specific clusters reduces your flexibility in making resource allocation decisions.
> In the virt world there has been a tendency to create cluster of a like
> architecture - where arch is actually a very particular x86 cpu family/generation.
> This was required for VM migration flexibility and the need to map VM CPU
> capabilities to the host CPU capabilities. For containers, that CPU mapping need
> does not exist - so the clusters can be more diverse.
> The current state of Kube however is not arch aware afaik - although we could
> manage that via node labels, it would be clunky. So short term, arch specific
> clusters. But the goal should be arch-aware orchestrators.

Thanks for the info: labels may get us being able to demo some things. I share your vision of arch-aware orchestrators as integrated system logic in the medium-term.

> Note: container naming/packaging in general is not architecture aware either.
> Docker Hub packages are mixed arch, even though Docker recommends using
> different registries for different archs. The RH container image naming
> standards that leverages container labels embeds an arch label for all the
> Fedora/RH/CentOS images. Skopeo can inspect those labels remotely. But there
> is more work to be done at the community level for arch awareness.

Indeed: repositories need some arch-specific-ness to enable the heterogeneous container datacenter. From the recent Fedora Flock (reading about it here: http://lwn.net/Articles/697347/) it seems that architecture is anticipated in Fedora's Layered Docker Image Build Service, which sounds like things are headed in the right direction.

Best regards,

PS. I have made some progress with an AArch64 Atomic Host F24 build it's not booting yet. Debugging...
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]