[fedora-virt] Lorax F15 composes - buildinstall rewrite
James Laska
jlaska at redhat.com
Fri Jan 14 18:52:16 UTC 2011
Sent on behalf of mgracik+AEA-redhat.com (not subscribed to virt+AEA).
-------- Forwarded Message --------
+AD4 From: Martin Gracik +ADw-mgracik+AEA-redhat.com+AD4
+AD4 Reply-to: mgracik+AEA-redhat.com
+AD4 To: virt+AEA-lists.fedoraproject.org
+AD4 Cc: James Laska +ADw-jlaska+AEA-redhat.com+AD4
+AD4 Subject: +AFs-Fwd: Re: Lorax F15 composes - buildinstall rewrite+AF0
+AD4 Date: Tue, 11 Jan 2011 13:05:23 +-0100
+AD4
+AD4 Hello,
+AD4
+AD4 I'm working on the buildinstall scripts rewrite, called lorax, and I
+AD4 have one issue. The buildinstall scripts generate the .treeinfo file,
+AD4 which is used by python-virtinst, and that it looks for the +AFs-images-xen+AF0
+AD4 section.
+AD4
+AD4 What I'd like to do in lorax, is that the section name will depend on
+AD4 the kernel name. If the kernel is a PAE kernel, it's filename will be
+AD4 kernel-PAE and initrd filename will be initrd-PAE.img (this is the same
+AD4 in buildinstall), but the section would be +AFs-images-PAE+AF0 as opposed to
+AD4 buildinstall's +AFs-images-xen+AF0.
+AD4
+AD4 And if a XEN kernel is installed, the filename will be vmlinuz-XEN
+AD4 (initrd-XEN.img) and corresponding section will be +AFs-images-XEN+AF0.
+AD4
+AD4 Will this change cause you any difficulties?
+AD4
+AD4 --
+AD4 Martin Gracik +ADw-mgracik+AEA-redhat.com+AD4
+AD4 email message attachment, +ACI-Forwarded message - Re: Lorax F15 composes
+AD4 - buildinstall rewrite+ACI
+AD4 +AD4 -------- Forwarded Message --------
+AD4 +AD4 From: James Laska +ADw-jlaska+AEA-redhat.com+AD4
+AD4 +AD4 To: Martin Gracik +ADw-mgracik+AEA-redhat.com+AD4
+AD4 +AD4 Cc: Jesse Keating +ADw-jkeating+AEA-redhat.com+AD4, Adam Williamson
+AD4 +AD4 +ADw-awilliam+AEA-redhat.com+AD4, Dennis Gilmore +ADw-dgilmore+AEA-redhat.com+AD4,
+AD4 +AD4 Christopher Lumens +ADw-clumens+AEA-redhat.com+AD4, David Cantrell
+AD4 +AD4 +ADw-dcantrel+AEA-redhat.com+AD4
+AD4 +AD4 Subject: Re: Lorax F15 composes - buildinstall rewrite
+AD4 +AD4 Date: Mon, 10 Jan 2011 08:58:20 -0500
+AD4 +AD4
+AD4 +AD4 On Mon, 2011-01-10 at 08:51 -0500, Martin Gracik wrote:
+AD4 +AD4 +AD4
+AD4 +AD4 +AD4 --
+AD4 +AD4 +AD4
+AD4 +AD4 +AD4 Martin Gracik
+AD4 +AD4 +AD4
+AD4 +AD4 +AD4 ----- Original Message -----
+AD4 +AD4 +AD4 +AD4 On Sun, Jan 09, 2011 at 06:53:38AM -0500, Martin Gracik wrote:
+AD4 +AD4 +AD4 +AD4 +AD4 ----- Original Message -----
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 On Tue, 2011-01-04 at 16:24 -0500, Martin Gracik wrote:
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 --
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 Martin Gracik
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 ----- Original Message -----
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 Hi Martin,
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 Thanks for reaching out on the topic. Exciting to see the
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 lorax
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 work
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 coming into Fedora.
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 On Tue, 2011-01-04 at 14:29 -0500, Martin Gracik wrote:
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 Hello,
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 I'm working on the Lorax project, which is a rewrite of
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 anaconda's
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 buildinstall scripts. It is now in a state ready for
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 thorough
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 testing.
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 The lorax package was already added to fedora and the build
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 is
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 in
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 koji. I have a patch for pungi, and from the tests I did
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 myself,
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 I'm
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 able to create the install images using patched pungi +-
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 lorax,
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 and
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 do
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 a successful install with them. I would like lorax to be
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 used
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 for
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 F15
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 composes if it will be possible.
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 Lorax as of now only supports i386 and x86+AF8-64 architectures,
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 so
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 there's a problem with all the secondary archs. I don't know
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 which
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 solution would be better, if the secondary archs should use
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 unpatched
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 pungi, which will still be running buildinstall, or if the
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 patched
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 pungi should run lorax only if the buildarch is supported,
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 otherwise
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 run buildinstall.
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 After we'll have the patched pungi build, we can get the
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 lorax
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 enabled
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 composes to QA and get more testing.
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 I would like to hear your thoughts and comments, if this
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 stuff
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 is
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 your
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 concern.
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 Has lorax been used to generate and compare F-14 install
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 images?
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 If
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 possible, I think comparing the resulting images might be
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 interesting.
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 Clumens +ACY I just finished up a new autoqa test that runs pungi
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 whenever
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 a new anaconda koji build is available. The test runs pungi
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 inside
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 a
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 mock chroot and is intended to capture potential compose
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 issues
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 ahead
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 of
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 time. Would any changes be needed for this test? Do we want to
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 run
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 both lorax and buildinstall versions of pungi at the same
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 time?
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 We're doing rawhide composes with buildinstall and lorax every
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 day,
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 and doing diffs between the initrds. I'm trying to get the lorax
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 composes as close as possible to the buildinstall ones. I don't
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 know
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 if you can access this server, but they are here
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 http://10.34.39.2/trees/lorax/ and
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 http://10.34.39.2/trees/rawhide/
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 Ah perfect, thanks for the links.
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 The diffs are in the lorax directories. I know the format is
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 strange, I didn't give a lot of thought to the formatting. It
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 basically has 3 parts:
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 1. missing files from the lorax compose, that are in
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 buildinstall
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 2. diff of text files that are in both composes
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 3. files that are in lorax compose, and NOT in the buildinstall
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 (leftovers), sorted by size and package they belong to (I used
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 this
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 part to remove leftover files, so the image is smaller, the ones
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 that are left now don't take much space, so I'm getting to the
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 part,
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 that removing them is not very effective for the maintainability
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 of
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 code, so they are still left there)
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 Careful with some of the tree metadata that several tools rely on
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 (virt-install, cobbler/koan to some degree, snake, beaker ...).
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +ACo lorax - http://10.34.39.2/trees/lorax/20110105/i386/os/.treeinfo
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 +ACo buildinstall -
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 http://10.34.39.2/trees/rawhide/20110105/i386/os/.treeinfo
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 Two issues jump out from comparing the two ...
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 1. The +AFs-images-+ACoAXQ sections appear to be missing from the lorax
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 generated .treeinfo
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 2. Also, possibly related, the +AFs-general+AF0 boot.iso option should be
+AD4 +AD4 +AD4 +AD4 +AD4 +AD4 moved to +AFs-images-+ACQ-arch+AF0 boot.iso
+AD4 +AD4 +AD4 +AD4 +AD4
+AD4 +AD4 +AD4 +AD4 +AD4 Yes, thanks for catching this, it must have slipped somehow,
+AD4 +AD4 +AD4 +AD4 +AD4 should be fixed now.
+AD4 +AD4 +AD4 +AD4
+AD4 +AD4 +AD4 +AD4 Looking good. One more comment, the lorax generated treeinfo includes
+AD4 +AD4 +AD4 +AD4 a
+AD4 +AD4 +AD4 +AD4 section +AFs-images-PAE+AF0, while the rawhide treeinfo used +AFs-images-xen+AF0.
+AD4 +AD4 +AD4 +AD4 Should
+AD4 +AD4 +AD4 +AD4 they match, or do we need to inform consumers that the xen images can
+AD4 +AD4 +AD4 +AD4 be found
+AD4 +AD4 +AD4 +AD4 under +AFs-images-PAE+AF0? Now that I think of it, is xen-guest support in
+AD4 +AD4 +AD4 +AD4 the
+AD4 +AD4 +AD4 +AD4 regular +AFs-images-+ACQ-basearch+AF0 anyway?
+AD4 +AD4 +AD4
+AD4 +AD4 +AD4 Yeah well, what I did in lorax is that, I take the images-+ADw-suffix+AD4 from the actual kernel name.
+AD4 +AD4 +AD4 If the kernel name ends with PAE, we rename it to vmlinuz-PAE, and corresponding initrd to initrd-PAE,
+AD4 +AD4 +AD4 so I put it to images-PAE. If the kernel would end with XEN, it would be all XEN instead of PAE.
+AD4 +AD4 +AD4 This looks more elegant to me, but I can change it easily to images-xen if it's a problem.
+AD4 +AD4
+AD4 +AD4 Looking at the source code of python-virtinst, it does rely on the
+AD4 +AD4 presence of +AFs-images-xen+AF0. I'd recommend reaching out to
+AD4 +AD4 virt+AEA-lists.fedoraproject.org to let them know of the change.
+AD4 +AD4
+AD4 +AD4 Thanks,
+AD4 +AD4 James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application+AC8-pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http:+AC8ALw-lists.fedoraproject.org+AC8-pipermail+AC8-virt+AC8-attachments+AC8-20110114+AC8-96d7c4de+AC8-attachment-0001.bin
More information about the virt
mailing list