On Tue, Mar 18, 2014 at 5:03 AM, Karanbir Singh <mail-lists at karan.org>wrote: > > 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. :) -- Chris St. Pierre -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140318/85d673d8/attachment-0007.html>