On Tue, Mar 18, 2014 at 5:03 AM, Karanbir Singh mail-lists@karan.orgwrote:
how about just using anaconda to drive the install ( so running the build like a native kvm image, then trimming). The yum installroot for @core is going to bring in a kernel etc as well, and we could --excludedocs and set installlang etc at the anaconda level. It also means, and I quite like, the idea that a single build process could be used for other things as well.
I'm sold. It sounds like we'd need the build process to have three components:
* A kickstart; * A post-processing script that packages the image up (into either an AMI or a Docker image or whatever else comes along); and, of course * The harness that ties it all together.
If you can point me to the code that's used to create HVM AMIs, I can start poking at this.
afaik, trusted-builds are a CI component of app containers and might not be very relevant to the platform generic containers we might end up doing initially ? or am I missing something else here. Are they trying to setup trusted builds as a 'validated/verified good build with a trackable upstream' ? commit access to a github repo might not be much of in terms of traceability.
You're not missing anything -- they can't be used for base images, and they're not very trusted, either. I just mentioned them to definitively rule them out.
We can work with or setup a new git repo for the docker configs, metadata etc and I would say we use the same workflow that has been proposed for the other cloud-instance sig stuff : ie. mirror on github for easier import, and manually bridge to git.centos.org, with triggers to build instance at git.centos.org.
Any reason we can't just host it entirely on github and use webhooks to trigger the builds at git.centos.org?
In terms of versions, we should do CentOS-5 as well. And we should perhaps, if we can get away with it, drop the updated-in-time images and stick to just the release content in CentOS-5/6 and then 7. The updated-in-time VM's have been a train wreck at AWS, and for 6.5 I didnt do it at all.
What has been painful about them? If they're not always stable for the end user, we could consider tagging them with "nightly" and leaving a stable build (e.g., stock 6.5) as "latest", so that people have to specifically ask for the fully-updated image.
E.g., 'docker run ... centos/centos6' runs CentOS 6.5, or whatever the most recent "stable build" is. 'docker run ... centos/centos6:nightly' runs a fully-updated image.
BTW, I did snag the 'centos' username on the Docker index; I'll contact you or Jim on IRC today to transfer it to you guys.
Also, at this point we should target the easiest wins and ship a base OS image, but keep in mind that shipping app containers might be an interesting option as well in the future ( gluster cluster as an example
? )
Yes! If we're willing to make this a separate process, this would be super easy with Dockerfiles. We could even use Trusted Builds for this, based on our own images, and not have to use CentOS' own resources. :)