Re: [Ltib] Multi-user LTIB

[Ken Gilmer]

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
> (/opt/{ltib,freescale}/pkgs

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    ./com.buglabs.build.production

% 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.
-ken