Dave,
Thanks for the review. My responses are in-line.
Dave Miner wrote:
> Sundar Yamunachari wrote:
>> Hi,
>>
>> The requirements for setting up system configuration is posted at
>> http://www.opensolaris.org/os/project/caiman/auto_install/ai_design/system_configuration_parameter_requirements.pdf.
>>
>> Please review the document and provide your feedback before next
>> Wednesday (06/10/09).
>>
>
> General comment: please clean up verb tenses and add appropriate
> articles ("the"). This is somewhat difficult to read as-is, and as
> it's primarily a document for communication to other teams of
> requirements, it needs to be cleaner to be handed off to them.
okay.
>
> 1.0, second paragraph: Perhaps preface this with "In developing the
> OpenSolaris installation architecture, the following principle is
> being followed:".
okay.
>
>
> 1.0, third paragraph: It isn't at all obvious why a compelling
> experience requires configuration during the first boot after
> installation...
All the required configuration should be done as part of the install
(and the first boot) and the user is not required to configure some
parameters to make the system work
>
> 1.1: s/which/that/ s/produce/produces/
okay.
>
> 1.2, case 6: This could use some explanation of why this case is
> expected to work, and what the differences are vs. an update from an
> older release.
I will add more information to this use case.
>
> 1.2 case 7: This use case doesn't appear to translate into any
> requirements in section 2. It's also not completely clear how it
> differs from case 2.
Use case 7 is similar to use case 2. I made it as a two different use
cases because the users are different. The requirements for both of them
may be the same.
>
> 1.3 This section seems to be focused entirely on minimizing the set,
> but doesn't seem to discuss any extensibility, either for different
> OpenSolaris-based products or for future releases. For example, what
> if we want to ship OpenSolaris pre-installed on a netbook that has
> only a 3G-cellular networking interface? Similarly, there appears to
> be an eagerness to dispense with an initial user account and focus
> only on the root account, whereas our best practices suggest making
> root a role and defining administrative user accounts. As such, it
> seems this set of parameters can't even reproduce the existing
> OpenSolaris installation; are we asserting a change in direction
> here? Finally, some discussion with the networking team on whether we
> should be setting up default routers or instead/in addition
> configuring a routing protocol client seems worth having; I'm not
> aware such a discussion has occurred? Finally, a nit, but "DNS" here
> should be "DNS resolver" since it's the client that's required, not
> the server.
We were trying to minimize the list of parameters required for a useful
system.When you talk about extensibility, do you mean an interface to
add new or existing parameters which are not included in the minimum set?
Regarding the user account, there is no change in direction. We
discussed about adding an user account and how it may interfere with
existing user accounts (with user database) and decided that it is
optional. If that implies change of direction, I will add user accounts
back to the set.
We haven't had any specific discussion about default routers with
networking group. I will start a conversation with them.
I will fix the nit about the DNS resolver.
>
> 2.0, requirement 2: What's the "server" here? I am assuming this
> means "automated installation server", but that's overly specific, I
> think.
It is installation server or the machine where the user adds the
manifests to a service. Do you think changing it "automated installation
server" will make it better?
>
> 2.0 requirement 3: I'm not sure what a "property on the file" is here.
> I presume the requirement here is that the mechanism make a best
> effort at configuration, applying anything which can be, rather than
> failing immediately on any error and not configuring other attributes
> which may be correct.
Yes. The requirement is apply the configuration if it is known or makes
sense. Otherwise ignore and display a notice indicating that it cannot
be configured.
>
> 2.0: Reiterating prior comments, there's nothing here about
> extensibility, nor that would obviously satisfy case 7.
I will work on extensibility part of the requirements.
Thanks,
Sundar
>
> Dave
