'''Summary:''' Fedora Cloud agreed to make a base image plus several tailored to specific purposes. This is one of the tailored ones — Docker host ready to go.
'''Importance:''' moderate (Docker is hot stuff and we need an answer to CoreOS, but if we fail to do it, we are not any worse-off than we are now, and Docker can still be used on the base iamge.)
'''Timeframe:''' F21 alpha / If it's not ready for alpha, we have missed this release
'''Scope:''' system-wide'''
'''Cloud SIG owner:''' Sandro Mathys
https://fedoraproject.org/wiki/Changes/Docker_Cloud_Image
N.B. We may consider Fedora Atomic Initiative for this image, depending on degree of effort on that project across the rest of Fedora.
Current TODOs include: - Decide whether to use ostree - Decide whether to remove yum/dnf - Decide whether to replace cloud-init by coreos' cloud-init or min-metadata-service - Decide whether to kick out python (if we decided against yum/dnf and cloud-init) - Write the change proposal and send it to the wrangler - Other minor stuff like THE ACTUAL WORK, duh!
Since the change deadline is coming up real soon now, we really need to make all of those decisions ASAP. Status at last meeting some 2 or 3 weeks ago was: need input from Heat people first.
Replying to [comment:3 red]:
I think we have that input -- https://lists.fedoraproject.org/pipermail/cloud/2014-March/003398.html
There is a heat docker driver and it removes the need for having the cfn tools in the image.
Replying to [comment:4 mattdm]:
Replying to [comment:3 red]: Since the change deadline is coming up real soon now, we really need to make all of those decisions ASAP. Status at last meeting some 2 or 3 weeks ago was: need input from Heat people first. I think we have that input -- https://lists.fedoraproject.org/pipermail/cloud/2014-March/003398.html There is a heat docker driver and it removes the need for having the cfn tools in the image.
Yes, we do. I was more trying to say where the discussion of the above-mentioned points stopped, and why.
With that input, we need to decide whether we want go that path. Do we want to force users to use the (contrib-only / non-supported) docker driver? Not sure it's available to users of OpenStack public clouds (HP, Rackspace, ...) at all.
And if we do, there's still all those other decisions to be made.
nod -- yeah, decisions to be made.
My opinion is that I'd like to make the docker image more special purpose and radical, and document how docker can also be easily used on the cloud base image if you have special needs.
While I agree we can make this one very special purpose and radical, I'm just not sure ostree is there yet. I know, we want to adopt it early on and I love to ride the leading edge but I currently think we lack the capacity and it's not crucial to the image / mission. We do have a lot on our plates and activity in the WG / SIG is faltering.
So my opinion tends slightly towards "keep things close to how they were in F20 and focus on the new products and low hanging fruits like smaller footprint and systemd-networkd". That obviously includes sticking with yum/dnf and python for now.
Also, getting rid of cloud-init (or rather, all its dependencies etc.) would be nice but min-metadata-service isn't ready (and I'm not fully convinced radically minimal is great here). Unfortunately, I didn't have time to pay a closer look to coreos' solution either but I figure it isn't in Fedora yet anyway, so getting it in might take too long.
So since we didn't have a meeting in a while and I'd rather not formulate a change proposal with lots of undecided things/options, I hope more people (voting members and others) can weigh in here or on the ml.
Can you elaborate a bit on what you feel the biggest problems are for the rpm-ostree side?
Replying to [comment:8 walters]:
I don't think there's an actual show stopper except for lack of resources on the Cloud SIG side to implement the usage of ostree, but to answer your question:
The biggest is probably the lack of experience, guidelines and processes around ostree in the Fedora community. That goes from establishing and maintaining trees to diving into it real deep for QA purposes.
Other issues, that I know you're working on and that are probably within reach anyway: - It's not in Anaconda yet (but an early patchset has been submitted for feedback) - It's not working with extlinux yet (probably Fedora specific and easy to fix, if not fixed already) - A proper way to get rid of the 'physical' OS after moving to ostree (not necessarily applicable to our use case once Anaconda support has landed)
I would like to help in this effort, well at least make sure SELinux works properly and help with docker support.
Thanks, Dan. You're already working on making docker and SELinux work, right? Anything you need from us to go on from here?
Well, also, since we were speaking about docker and SELinux - is it still necessary with ostree to disable SELinux to boot into a tree as outlined in the [http://rpm-ostree.cloud.fedoraproject.org/#/installation installation guide]? Obviously, that would be a major show stopper.
I've now written a terrible first version of the change proposal and everyone is welcome to let me know what I can improve (or, do it yourself if it's minor-ish): https://fedoraproject.org/wiki/Changes/Docker_Cloud_Image
I tried to write it so that we can either: Just take take the base image, add docker-io (and possibly etcd and fleet) and call it something shiny new OR, implement any of the leading edge stuff, too - depending on how the discussion / necessary work goes and what we decide.
Replying to [comment:12 red]:
Not currently. The hardest thing will be handling of volumes with SELinux. IE If I want to mount random content into a container, how do I label it.
Replying to [comment:13 red]:
Replying to [comment:8 walters]: Can you elaborate a bit on what you feel the biggest problems are for the rpm-ostree side? Well, also, since we were speaking about docker and SELinux - is it still necessary with ostree to disable SELinux to boot into a tree as outlined in the [http://rpm-ostree.cloud.fedoraproject.org/#/installation installation guide]? Obviously, that would be a major show stopper.
I am not sure, have to let Colin Check in on this one. I have made some changes to the SELinux policy in Rawhide for OSTree, and I think Miroslav has been back porting them into F20.
I have talked to Colin about potential problems with people doing restorecon -R -v /. We might have to implement some changes to the SELinux tool chain.
Nope, that's been fixed for quite a while. I updated the web page.
The qcow2 images you download are in enforcing mode. Anaconda will install in enforcing mode. Now, using OSTree to parallel install is a trickier case, but should be fixed by https://bugzilla.redhat.com/show_bug.cgi?id=1061064
@mattdm, @red
I'd like to help out here. Definitely an interesting project. What needs to be done to move forward?
Change has been submitted but I'd like to leave this ticket open regarding the yet-to-be-made decisions. Or should I create a new one with the meeting keyword?
@scollier: Right now, IMHO: - Wait for FESCo's approval - Make some crucial decisions (see comment 4) - Wait for image building with Anaconda to become available in Koji - Wait for the base image to be adopted to Anaconda (unless we go with ostree, I guess)
So best things to do right now is to get familiar with all the bits and pieces (anaconda's image building, kernel-core, ostree, docker, etcd, fleet, whatever else you think should possibly be included in the Docker host image) and possibly form an opinion to support the decision making.
I should be available if anybody needs a hand.
As requested, I've now created a new ticket (#47) for the open decisions and will close this as the change has been proposed a while ago already.
Login to comment on this ticket.