[Lxc-users] [lxc-devel] Working LXC templates?

[Michael H. Warfield]

On Mon, 2013-09-09 at 17:23 +0530, Shridhar Daithankar wrote: 
> On Monday, September 09, 2013 07:28:43 AM Michael H. Warfield wrote:
> > In the git-stage current Fedora template, the entire problem is embodied
> > in the "download_fedora" function starting around line 201...  The
> > gotcha's are three commands around line 272 after we've identified and
> > downloaded the initial release rpm.  We have this:
> > 
> >     mkdir -p $INSTALL_ROOT/var/lib/rpm
> >     rpm --root $INSTALL_ROOT  --initdb
> >     rpm --root $INSTALL_ROOT -ivh ${INSTALL_ROOT}/${RELEASE_RPM}
> >     $YUM install $PKG_LIST
> > 
> > Ok...  Those are running in the host local run time environment.
> > Obviously, if the host does not have a (compatible) version of rpm
> > and/or yum in the host local environment, you're screwed.  That's the
> > catch-22 situation and it's the same situation with zypper in the
> > OpenSuse template.  That short space of code has to be recreated in a
> > totally distro-agnostic manner so it runs on any distro to create our
> > initial rootfs.  After that, we can do what ever distro (Fedora)
> > specific commands we want by chrooting into the target container first
> > (including rebuilding the rpm database to the target version).  That's
> > only even needed if you don't already have a cached rootfs for that
> > distro and version.

> Another approach could be to popularize the container downloads by the distro. 
> If each distro. could add a .tar.gz for a working container of a given 
> release, one could just download and configure them, no?

> then the lxc project upstream, could just list those links or include them in 
> the a separate tool, that just downloads and untars the same?

> That would completely sidestep the bootstrapping one-distro.-on-another 
> problem.

True, and that's been mentioned before in several different contexts.
The problem is that we have to get the cooperation of ALL the distros we
wish to support, which seems to be a bit of an intractable problem.  In
Fedora, it would require someone to take that on as a project and be the
maintainer.  It would also have to be architected into the build system
so it would be automatically build when a release it cut.

Since they already have the squashfs LiveOS system (which is 95% of what
we need), I don't think it would be a major leap for them to add a
parallel build to build an LXC LiveOS to live, say, in the same download
directory.  In fact, if they fixed some of the deficiencies in the
LiveOS image, we could work directly from the squashfs image that's
already there.

The problem is in getting someone interested (I'm not a Fedora
maintainer) and getting them to do it.  It would probably have to be
filled as an enhancement request and go through the months long vetting
process at best.  We might have a better shot (in this case) of filing a
bug report in bugzilla for the busted components of the LiveOS image and
getting them to fix it.  Even there, though, it's likely impossible to
get them to retroactively fix any of the previous images.

I agree it would work, I just don't think we can depend on getting
everyone else to agree to it and implement it in their distros.

Considering the direction Fedora has been taking in recent decisions
(removing sendmail / any MTA as well as the syslog server from the base
install) makes me seriously question if they would even care. 

> -- 
> Regards
>  Shridhar

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20130909/e05a956f/attachment.pgp>