<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 18, 2014 at 5:03 AM, Karanbir Singh <span dir="ltr"><<a href="mailto:mail-lists@karan.org" target="_blank">mail-lists@karan.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
how about just using anaconda to drive the install ( so running the<br>
build like a native kvm image, then trimming). The yum installroot for<br>
@core is going to bring in a kernel etc as well, and we could<br>
--excludedocs and set installlang etc at the anaconda level. It also<br>
means, and I quite like, the idea that a single build process could be<br>
used for other things as well.<br></blockquote><div><br></div><div>I'm sold. It sounds like we'd need the build process to have three components:</div><div><br></div><div>* A kickstart;</div><div>* 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</div>
<div>* The harness that ties it all together.<br></div><div><br></div><div>If you can point me to the code that's used to create HVM AMIs, I can start poking at this.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="">
</div>afaik, trusted-builds are a CI component of app containers and might not<br>
be very relevant to the platform generic containers we might end up<br>
doing initially ? or am I missing something else here. Are they trying<br>
to setup trusted builds as a 'validated/verified good build with a<br>
trackable upstream' ? commit access to a github repo might not be much<br>
of in terms of traceability.</blockquote><div><br></div><div>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.</div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">We can work with or setup a new git repo for the docker configs,<br>
metadata etc and I would say we use the same workflow that has been<br>
proposed for the other cloud-instance sig stuff : ie. mirror on github<br>
for easier import, and manually bridge to <a href="http://git.centos.org" target="_blank">git.centos.org</a>, with triggers<br>
to build instance at <a href="http://git.centos.org" target="_blank">git.centos.org</a>.<br></blockquote><div><br></div><div>Any reason we can't just host it entirely on github and use webhooks to trigger the builds at <a href="http://git.centos.org">git.centos.org</a>?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
In terms of versions, we should do CentOS-5 as well. And we should<br>
perhaps, if we can get away with it, drop the updated-in-time images and<br>
stick to just the release content in CentOS-5/6 and then 7. The<br>
updated-in-time VM's have been a train wreck at AWS, and for 6.5 I didnt<br>
do it at all.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div><div>> Also, at this point we should target the easiest wins and ship a base OS</div>
<div>> image, but keep in mind that shipping app containers might be an</div><div>> interesting option as well in the future ( gluster cluster as an example ? )</div></div><div><br></div><div>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. :)</div>
<div><br></div></div>-- <br>Chris St. Pierre
</div></div>