Scott we found an interesting problem with libvirt protections on /dev/kvm.  If you run this container on an atomic machine, the device has the wrong protections.  You need to add chmod 666 /dev/kvm to make it work, or

chmod 660 /dev/kvm
chown root:qemu /dev/kvm

I think this would break on other machines that do not have libvirt installed on the host.

On 03/19/2015 10:20 AM, Scott Collier wrote:
> On 03/11/2015 09:40 AM, Major Hayden wrote:

On 03/11/2015 09:23 AM, Joe Brockmeier wrote:
>>> I'm CC'ing Scott b/c, if I'm not mistaken, he's done quite a lot of
>>> the work so far on the Dockerfiles - but also, I think he's looking
>>> for assistance there in keeping the effort going.
I'll be glad to help maintain/update those Dockerfiles if needed, Scott.

> Thanks Major.  Here's a summary of things I think we should be looking at in general, not just Dockerfile maintenance:

> 1. Ensuring dnf support on Fedora 22 images.  This means figuring out how to manage dockerfiles in a manner that both dnf or yum can work.  For example, the FROM line will determine what package installation method we will use.  If it's FROM fedora:rawhide, should use dnf, if it's FROM fedora:21, should use yum.  Just need to think that through and how we want to handle.  I haven't played around with dnf yet.

> 2. Need READMEs for the libvirt images:


> 3. Need some extra eyes on all PRs and images that come in.  Might be good to require a +1 from two maintainers before merging a request?  Thoughts?

> 4. I'd like to set up some CI on these where and if it makes sense. Some triggers: docker package updates, Dockerfile updates, etc... Something simple: build the image, run the image, test for an expected result.

> 5. Does it make sense to add some kubernetes support / examples to these?  I know not all of these apps are "scalable" or usable in a production k8s cluster, per se, but dropping in a yaml file for a few select images, so people can explore and learn wouldn't hurt. It could sit right by the Dockerfile.  People could build the image, and deploy in a k8s environment.

> 6. Now that the LABEL patch has been (or will be merged) into Docker, we'll want people to start testing the LABEL functionality in fedora-dockerfiles and take advantage of that with the new atomic package.  We'll want to abstract away any complex docker install / docker run commands moving forward.  This will take some effort. This will be very helpful on an any host with the atomic tool.

> Anything else? Thoughts?

>> _______________________________________________
>> cloud mailing list
>> Fedora Code of Conduct:
> _______________________________________________
> cloud mailing list
> Fedora Code of Conduct: