Deployment image customization

[Greg Smith]

Hi Dan,

Those sound like two good steps.

I think we should make a design decision here to either:
1 - "clone" minus a list of configurations
or
2 - Extend customization to include everything relevant for a deployment.

Both have challenges. My preference is clone because I think its easier 
for the end user (create an XO the way you like it then click "clone"). 
However, we need to figure out the list of things that should not be 
cloned as you mention.

Extending the customization key has two main challenges as I see it. The 
first is that we may miss some customization that people want. The 
second is that its a little cumbersome to collect all the files, put 
them on a USB stick, add an fs.zip etc. I believe it also requires a 
second boot of the XO and possibly 2 USB sticks. One to update OS and a 
second to add "customizations".

The final image must be deliverable as an upgrade or a clean install via 
and of the following: olpc-update to internet, via olpc-update to XS, 
via NAND Blaster, via USB stick.

I updated the requirements to bullet those out more clearly.

In terms of customization stick or clone, this is where the lead 
engineer or whoever does the work gets to make the final call. Just make 
sure you address all the requirements and that  we get it done in time 
for a QA cycle in February and we'll be OK.

If some requirement cannot be met (e.g. set the language to Mongolian) 
we can consider living without it. I prefer to nail them all but hitting 
the date and improving the product is more important than the perfect 
solution which never comes.

I agree that its closely related to the lease delegation, signing, and 
building requirements (your next step #1 below).

A well architected approach that addresses all the points (section 2 
here: http://wiki.laptop.org/go/9.1.0#Top_Priority) would be great!

Thanks,

Greg S

Daniel Drake wrote:
> On Tue, Dec 23, 2008 at 2:19 PM, Greg Smith <gregsmitholpc at gmail.com> wrote:
>> Your suggestion that we allow
>> addition of RPMs and get those built into a signed image via "pilgrim or
>> puritan" is certainly valuable and part of the requirement.
>>
>> However, it doesn't cover a few added things (language settings was
>> specifically requested by Mongolia and others):
>>
>> - Updated language packs (I believe we are trying to make this an RPM which
>> may solve it)
>> - Starting language
>> - Date, time and timezone
>> - Network settings
> 
> Well, my suggestion of pilgrim and puritan was only for customising
> RPM packages. For the other things, I wrote:
> "As for other customisations, the current method (customization key)
> works fine for the limited customisations that it allows, so that
> simply needs to be expanded. "
> 
> I could have probably worded that better. In other words, my opinion
> is that the existing customisation stick system should be expanded to
> also allow customisation of timezone, language settings, translation
> installation, etc.
> 
>> The biggest challenge I see is to find those things which you do not want to
>> "clone" from the source XO. The only things that come to mind are Name and
>> Color. We could even pre-fill them as long as those dialog boxes come up at
>> start up.
> 
> There is a lot more than that - it's things that are invisible to the
> user, technical details of the system, which are the bits we don't
> have a good answer for. For example (an easy one), keys are generated
> on first boot, but it is potentially bad news down the line if
> multiple XOs have the same keys. The hard part is tracking these
> things, which are not specified anywhere and there's no one place you
> can look to find them. I wish I could find a link to Michael's mail,
> where he investigated some of these things for an old build, and some
> of the findings were surprising even to us who hack on the system
> level all day...
> 
>> In short, I like your proposal but I still want a little more :-)
> 
> If you're looking for initial high-level action items:
> 1. The discussions on lease delegation / allowing countries to sign
> their builds / providing customised builds for countries need to be
> finished. The outcome would be someone implementing whatever method
> allows country A to say "we want OLPC build B with added RPMs C,D,E"
> 2. Someone needs to implement the customization stick enhancements
> (and surrounding projects, such as xot bundles). Will require some
> modifications on the sugar-level too.
> 
> Daniel
>