[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ltib] Multi-user LTIB

From: Ken Gilmer
Subject: Re: [Ltib] Multi-user LTIB
Date: Wed, 13 Feb 2008 10:29:38 -0500

Hi Stuart,

I appreciate your detailed response! It took me some time to go through your email and make sure I understand everything. I certainly agree in this approach for LTIB in general. I think what we are trying to do with LTIB may be outside of it's intended use and perhaps not appropriate. Here are the "requirements" I see that we are looking for:

1. Support continuous build and test automation. Specifically we wish to hook our SCM to CruiseControl and to perform builds and test executions in an entirely automated fashion. 2. Allow multiple developers to utilize an existing Linux system concurrently and independently. 3. Allow users with a high variance in expertise to use the system. We may want to allow customers to generate their own target images. This may present some kind of opportunity for a web UI on top of LTIB and package metadata.

In regards to the points regarding the reasoning behind the existing behavior, I humbly submit counter points:

* Ensuring that all content referenced in packages is the same

What is the relevant distinction between packages living in /opt/... and in a private package pool? Disregarding performance for the moment, are there other reasons?

* Reducing overall installation size: if each instance
had /opt/{ltib,freescale}/pkgs, it would be a big overhead

% du --max-depth=1 -h .
1.4G    ./

% df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/md/2             229G   41G  177G  19% /

% du --max-depth=1 -h /opt
1.7G    /opt/freescale
103M    /opt/ltib

Ok, yes, 3.1 Gb is not small. But this can be considered temporary (does not grow with each successive build) as we would generate this fresh each time. In addition discs are big and getting bigger (and cheaper).

* Sharing the common host support packages so that when something breaks
I can be sure what environment (host tools) this happened (for most
things). The discipline this imposes is that backward compatibility has
to be ensured (which I try hard to do).

Understood. From a support perspective, assuming there was a configuration change (like a "mode") to switch, we could isolate behavior by switching back to standard "mode" to isolate potential issues.

In any case I understand and agree with the reasons LTIB works the way it does. From my perspective (potential) developer time resolving inconsistencies that come from concurrency issues outweigh the fixed-costs that a purely isolated LTIB system would incur. I guess my question now: Is it appropriate to modify LTIB to work the way we want it do? We certainly do not wish to hack it such that we're running our own custom version. If the modifications required are much more than pure (global) configuration it probably doesn't make sense.

Thanks for your time.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]