[atomic-devel] Atomic Host for ARM

[Iván Chavero]

Hello, I want to use Atomic Host on a Cubietruck but i can't find any 
images for ARM.


I've checked and just found ISO and vagrant files and cloud images for 
x86_64, looked for


guides on how to build the image and i couldn't find any.


Can somebody give me pointers on where to find the ARM images or guides 
on how to build them?



Thanks


--
Iván Chavero
Hacker

Re: [atomic-devel] Add Nvidia GPU to Centos Atomic Node

[Colin Walters]

On Wed, Nov 8, 2017, at 02:29 PM, Stephen Milner wrote:

> What about literally providing dkms in a container? It wouldn't
> directly take care of the original request but it would give an avenue
> for folks to use the dkms toolchain if they'd like to in AH without
> package layering.

Maybe?  Are we trying to replace dkms for yum-managed systems too?
I'm a bit worried about the sustainability of adding a whole other model
to dkms without trying to delete one at the same time.   That said,
it might not be *too* hard to get a PoC here.

Offhand I feel like focusing on cri-o/kube in-syscontainers is more important?
Just today I saw from IRC chat:
https://github.com/kubernetes/contrib/commit/9bef0bee1c4881469fbd1688b6e6c73a30ebb8d9

Yet there's no
https://github.com/kubernetes-incubator/kubespray
for any *AH =(  (Or for that matter Fedora...I just glanced at it
and it looks like it's python2, which brings us to
https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2017-August/msg1.html
)

Though someone who's doing e.g. OpenShift-on-AH and
wants to do GPGPU/ML using Nvidia GPUs in their cluster
might have a different perspective!

Re: [atomic-devel] a better place for system container images?

[Giuseppe Scrivano]

Colin Walters  writes:

> On Mon, Nov 6, 2017, at 03:57 AM, Giuseppe Scrivano wrote:
>
>> The goal is to build the images automatically on every PR merged.
>> Occasional builds (maybe daily?) will prevent to miss changes in the
>> base layers or in the installed rpms.
>
> Let's write down these requirements/requests in an issue for Fedora rel-eng to
> get fixed?  We could probably help with that too.
> I'm sure there are other containers that want something like this.

IMHO what is important to have is:

- automatically build the images based on the last development version
- have them all available, no matter the base image used by each

At the moment we have images based both on CentOS and on Fedora, so we
would still not able to host all of them on the Fedora registry.

We are already using the Fedora registry for some of the system
containers and the intention was to add them to the CentOS registry as
well (Docker and CRI-O are host specific, at least for now).
Even if we'll cherry pick more images to the Fedora/CentOS registry, I
think having a common place where users can find all the latest system
containers is still a good idea.

Avoiding these duplicate efforts is probably a much wider discussion, but
something to consider in the long term.

Not sure there is much Fedora rel-eng could do to simplify the
organization of the different images we have.  As I said before, my only
wish for the Fedora registry part is that it would be nice if the
release number is not part of the image.  Could even be a new namespace
that links to the last one:

registry.fedoraproject.org/latest/etcd -> registry.fedoraproject.org/f26/etcd

Giuseppe