<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 8, 2014 at 3:40 PM, Jim Perrin <span dir="ltr"><<a href="mailto:jperrin@centos.org" target="_blank">jperrin@centos.org</a>></span> wrote:<br>
<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=""><br>
<br>
On 04/08/2014 02:41 PM, Matthew Miller wrote:<br>
> On Tue, Apr 08, 2014 at 12:59:18PM -0500, Jim Perrin wrote:<br>
>> Adam/Matt, could you provide some detail as to the benefits of<br>
>> appliance-tools, and the capabilities?<br>
><br>
> Wellllllll. We are actively migrating away from appliance tools, actually.<br>
> the two benefits were:<br>
><br>
> - uses a standard input format we are all familiar with (kickstart)<br>
<br>
</div>so that's pretty much the same as what we're doing now then.<br>
<div class=""><br>
> - integrated into koji for builds (so we get the repeatability and<br>
> traceability benefits that brings)<br>
<br>
<br>
</div>and we're not using koji for the core builds.<br>
<div class=""><br>
<br>
> Now with Koji 1.9, we have an anaconda/imagefactory toolchain, which has<br>
> these advantages:<br>
><br>
> - also uses kickstart<br>
> - appliance-creator in maintenance mode only, anaconda actively developed<br>
> - even better koji integration (tarball outputs for docker to take in)<br>
><br>
> But, I think even that is intermediary. There is preliminary work on an idea<br>
> which uses rpm in mock as the build format:<br>
><br>
<br>
</div>Since el6 will still be current/relevant to us for quite some time,<br>
would this new method be able to create el6 images as well?<br>
<div class="im"><br></div></blockquote><div><br></div><div>For what it's worth I figured I'd mention the github comment thread that kind of </div><div>kicked off this topic.</div><div><br></div><div><a href="https://github.com/CentOS/sig-cloud-instance-build/pull/4">https://github.com/CentOS/sig-cloud-instance-build/pull/4</a><br>
</div><div><br></div><div>Also, in the event this ends up going anywhere I've moved forward with getting</div><div>appliance-tools into EPEL6</div><div><br></div><div><a href="https://admin.fedoraproject.org/updates/appliance-tools-007.7-2.1.el6">https://admin.fedoraproject.org/updates/appliance-tools-007.7-2.1.el6</a><br>
</div><div><br></div><div>-AdamM</div><div><br></div><div><br></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="im">
> - uses a standard input format we are all familiar with (spec files)<br>
> - much lighter weight than anaconda<br>
> - in active development<br>
> - can handle _layered_ images<br>
> - will be integrated with koji (i think also through imagefactory)<br>
><br>
> The nice thing here is that the output format (and fedbus messages) should<br>
> be the same if we make this second transition in the future, so the<br>
> koji -> docker registry bits can be the same.<br>
><br>
<br>
--<br>
</div><div class="im">Jim Perrin<br>
The CentOS Project | <a href="http://www.centos.org" target="_blank">http://www.centos.org</a><br>
twitter: @BitIntegrity | GPG Key: FA09AD77<br>
</div><div class=""><div class="h5">_______________________________________________<br>
CentOS-devel mailing list<br>
<a href="mailto:CentOS-devel@centos.org">CentOS-devel@centos.org</a><br>
<a href="http://lists.centos.org/mailman/listinfo/centos-devel" target="_blank">http://lists.centos.org/mailman/listinfo/centos-devel</a><br>
</div></div></blockquote></div><br></div></div>