On 05/10/09 15:12, Peter Tribble wrote:
> On Thu, May 7, 2009 at 9:45 PM, Susan Sohn <Susan.Sohn at sun.com> wrote:
>> Below are the notes generated from the service redesign meeting yesterday,
>> May 6. In addition, I've added what I consider to be the use cases we'd
>> like to address.
>>
>> Please provide feedback and comments.
>>
>> Thanks,
>> Sue
>>
>>
>> User problem to solve:
>> Ensure that an AI client can deterministically be installed with the same
>> boot
>> image in a repeatable, consistent way, without client specific setup.
>>
>> Why can't we do this today?
>> 1. Client may not always get image of same architecture.
>> 2. Client may not always get same service every time it is booted.
> 
> Why is the current system non-deterministic? I've always taken the fact
> that my installs are absolutely deterministic as a given.

Depending on how dhcp IP pools are set up, if no client-specific configuration 
has
been done (create-client), it might be possible to get a different service
from install to install. As the image and manifests are associated with the
service, different install experiences could result.

>> What use cases do we want to address?
>> 1. Small office environment, homogeneous setup (clients either all x86 or
>> all
>> SPARC), the server and clients are in the same subnet, OpenSolaris needs to
>> be
>> installed on the first disk of each client.
> 
> I'm not sure that's valid. Even in that environment I would expect
> mirrored drives,
> and the first disk will only be useful on a subset of possible hardware.
> 
>> 2. Large company with 200 clients, roughly half x86 and half SPARC. The same
>> version of OpenSolaris needs to be installed on each set of systems.
> 
> That's not large. Thinks thousands.

True.

>> 3. Same as #2, except that a few clients need to be installed with something
>> different.
> 
> Or all different...

This is a valid case, however not one that I was thinking would be handled 
without
client setup. Are you thinking otherwise?

>> 4. Lab environment with 40 x86 clients, where 20 need OpenSolaris v1, 15
>> need
>> OpenSolaris v2 and 5 need OpenSolaris v3.
>>
>> Notes/Questions:
>> 1. Need to come up with definition of install service.
> 
> That would be handy. I'm having trouble matching the current discussion
> to the way I build systems, and I suepect terminology is a barrier.

I'm planning to call a meeting today to discuss this very thing.

>> 2. In original design, service discovery was considered a major feature. It
>> is
>> not being used. Do we still need it? Would using it conflict with our goal
>> of
>> having a repeatable, consistent client install?
>> 3. Consistent behavior needs more thought - how do we advertise and get
>> services?
>> 4. What should overall experience be with respect to remote servers?
>> 5. User experiences should be scalable.
> 
> Which also means keeping it flexible and simple. In particular, so
> it can be driven from outside. (For example, if it's just a bunch of flat
> configuration files then I can automatically generate those using
> pretty much any tool I choose from any source.)
> 
>> 6. Investigate idea of default service.
>> 7. Could a single service serve both x86 and SPARC clients?
> 
> Depends on the definition of a service..
> 
> I would expect to be able to use a single server to install all versions
> to all architectures, but would expect to configure each {version,arch}
> pair separately.

The challenge is figuring out how a given client would know which {version/arch}
pair it was associated with.

Thanks for the feedback,
Sue


Reply via email to