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.

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

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

Or all different...

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

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

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/

Reply via email to