[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
(/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