[CentOS-gsoc] RootFS Build Factory IRC Log 2015-04-02

Thu Apr 2 18:32:54 UTC 2015

Hello everyone,
  I got a chance to discuss the build factory idea with imcleod and
Evolution on IRC Freenode #centos-gsoc. They gave me some good inputs.
While I work on improving my proposal based on those inputs, here is
the entire log of the chat.

-----------------------------------------------------------------------------------------------------------------------------
Conversation with #centos-gsoc at Thu 02 Apr 2015 12:49:44 AM IST on
mndar at irc.freenode.net (irc)
(12:49:44 AM) The topic for #centos-gsoc is: We are IN! ||
http://wiki.centos.org/GSoC/HowToApply ||
http://wiki.centos.org/GSoC/2015/
(12:49:44 AM) Topic for #centos-gsoc set by
kbsingh!~kbsingh at n12.lon1.karan.org at 06:43:51 PM on 03/03/2015
(01:05:21 AM) mndar: hughesjr: Perhaps you might have already seen my
email to you that I sent on 22 March. I learnt from Karsten Wade on
the centos-devel mailing list that you are busy with the CentOS
updates. I was wondering if you got the chance to review my proposal
for RootFS Build Factory. sankarshan asked me if I've been in
conversation with the mentor of this project. I am eager to discuss
the project with you.
(01:18:50 AM) lalatenduM left the room (quit: Quit: Leaving).
(01:33:55 AM) mndar: right now I am trying to figure out if using
ImageFactory is the best option for building ARM RootFS or whether we
need a separate set of scripts.
(01:34:11 AM) mndar: Evolution, imcleod: any thoughts?
(01:37:20 AM) Evolution: I'm fine either way.
(01:37:36 AM) Evolution: so long as there's 'one tool suite' to do so
(01:39:20 AM) mndar: by 'one tool suite' you mean, a single tool
should be able to generate x86 cloud images and ARM RootFS?
(01:56:45 AM) kbsingh: quaid: around ?
(01:58:09 AM) rbowen [~DrBacchus at apache/pony-mafia/rbowen] entered the room.
(02:01:57 AM) kbsingh: quaid: meet rbowen ; rbowen meet quaid :)
(02:05:19 AM) rbowen: quaid: I feel like maybe we've met somewhere before.
(02:15:22 AM) The account has disconnected and you are no longer in
this chat. You will automatically rejoin the chat when the account
reconnects.

Conversation with #centos-gsoc at Thu 02 Apr 2015 02:16:11 AM IST on
mndar at irc.freenode.net (irc)
(02:16:11 AM) The topic for #centos-gsoc is: We are IN! ||
http://wiki.centos.org/GSoC/HowToApply ||
http://wiki.centos.org/GSoC/2015/
(02:16:11 AM) Topic for #centos-gsoc set by
kbsingh!~kbsingh at n12.lon1.karan.org at 06:43:51 PM on 03/03/2015
(02:16:42 AM) mndar left the room (quit: Ping timeout: 264 seconds).
(02:33:39 AM) imcleod: mndar: I will try to get some initial review
comments in in the next day or two. Regarding the specific question, I
don't think it necessarily has to be based on ImageFactory.
(02:49:08 AM) mndar1: imcleod: thanks. In the next 2-3 days, I'll play
around a bit with ImageFactory. Check out what features it has. How it
does things. Should I refer to
https://github.com/imcleod/oz/tree/feature/arm_support or
http://imgfac.org/ ?
(02:50:17 AM) imcleod: mndar1: For this use case, the oz tree would
probably be a better starting point.
(02:51:19 AM) imcleod: The primary benefit of the Oz approach is that
we get to use Anaconda, which means we get the install runtime (with
yum/dnf, rpm versions, filesystem support) built for us.
(02:51:58 AM) imcleod: Earlier image solutions used in Fedora did not
use virt, and depended on things like running a yum transaction with
the target being a subdir or a loopback device.
(02:52:39 AM) imcleod: And this works, somewhat, if you are using
similar versions of the host and target (e.g. F20 -> F20) but starts
to break down when the diff between the host and target grows.
(02:53:52 AM) mndar1: imcleod: when I initially read the problem
statement on the ideas page, my first thought was to take the
subdir/loopback device approach.
(02:55:38 AM) imcleod: mndar1: Right. I believe the Fedora project is
in fact still using that approach to make the ARM images for F21 and
now F22.
(02:55:55 AM) mndar1: do we need anaconda for ARM boards? Packages
required to run a complete CentOS system can be put into a rootfs
image using the 'Build Factory'
(02:56:40 AM) imcleod: mndar1: But they do so using nested chroots
(IIRC). So, for example, the version of yum used to generate the F21
rootfs for ARM was the F21 version of yum (and rpm, etc.) not the
version running on the host doing the build.
(02:57:37 AM) imcleod: mndar1: Anaconda actually does work now for ARM
(and most of the other non x86_64 architectures).
(02:58:11 AM) imcleod: mndar1: And the appeal of using the Anaconda
approach is that it can essentially be the same thing that is already
done to generate disk images for x86.
(02:58:18 AM) imcleod: mndar1: It's an open question, in my mind.
(02:59:28 AM) mndar1: imcleod: I didn't know that about Anaconda.
Thanks. You've given me some good points to ponder over
(02:59:59 AM) imcleod: mndar1: Cheers.
(03:00:48 AM) mndar1: imcleod: do we also want something like this
http://fedoraproject.org/wiki/Fedora_ARM_Installer?
(03:08:58 AM) mndar1: imcleod: from what I've read so far Fedora has
released one image which needs to be installed using slightly
different techniques on each board. That's one approach. The second
would be, as you mentioned, Anaconda. With Anaconda users will have to
first copy over a bootable images to a SD card, boot with it and
install CentOS to their NAND Flash or SATA HDD and then configure it
(03:09:24 AM) mndar1: imcleod: another option is to create a
preconfigured images using the 'Build Factory'
(03:14:42 AM) imcleod: mndar1: I think the Fedora approach for F21 is
pretty cool, in that it manages to provide a single base image where
the only board-specific tweaks are related to the boot loader.
(03:17:11 AM) mndar1: imcleod: can you do custom partitioning with
those Fedora images?
(03:18:01 AM) imcleod: mndar1: You cannot. You are more or less stuck
with the partition layout they have given you, though there are built
in tools to extend the main parition (containing /) to fill whatever
sdcard you have used to do the install.
(03:21:43 AM) mndar1: imcleod: my initial thoughts are that we should
let the board vendor decide everything about partitions. If any user
wants to custom partitions he can easily create his own image using
the build factory. As far as the partitioning issue goes, your
suggestion of using Anaconda seems to be the best option
(03:24:47 AM) mndar1: imcleod: About Oz. So, it creates a virtual
machine using libvirt and then installs native packages? It would save
me some time if you could briefly tell me how Oz goes about generating
images
(03:33:23 AM) mndar1: imcleod: We want the build factory to be able to
generate different images containing different packages. For that, the
yum chroot option seems suitable
(03:37:03 AM) mndar1: So the ideal/Fedora solution is
https://fedoraproject.org/wiki/Architectures/ARM/F21/Installation#Download_the_Disk_Image_.26_Copy_to_Media
+ ability to generate custom images based on packages listed in a
template file
(03:45:55 AM) mndar1: imcleod: thanks for all your inputs. I have to
go now. its almost 4am over here
--------------------------------------------------------------------------------------------------------------------------

Regards
Mandar Joshi