On 09/23/10 05:13, Jan Damborsky wrote:
Hi Ethan,
On 09/22/10 04:41 AM, Ethan Quach wrote:
Jan,
4 - Just wanted to clarify if the use on bare-metal outside of the
text-installer (e.g. like first boot of the global zone) is in scope.
Bare metal is mentioned in the requirements in section 6.2, but
not explicitly mentioned here.
Yep. Bare metal is in scope. For instance, SCI tool could be used for
configuration of pre-installed images. I will clarify that.
5.1 This is probably related to your question in 12.2, but how
would we control this? e.g. in AI, if we placed a SMF profile on
the system with properties A, B, and C, but not D, and if D was a
required parameter, would SCI just prompt for all A, B, C, and D?
With current proposal, it would work in following way:
* in AI scenario SCI tool would not be brought up by default, even if
some of
configuration parameters were not configured in SC manifests.
* user could explicitly enable invoking SCI tool during first boot
(e.g. by setting
smf property in SC manifest) if interactive configuration was
preferred over
non-interactive one.
Then SCI would prompt for all parameters applicable to running
environment regardless
of what was configured in AI manifest.
6.4 - nit, maybe omit the word 'graphical' here.
Yep. I will remove it.
12.1 - Curious, are the rest of the text-installer's screens implemented
as a checkpoint as well? Wondering if there's a need for any
consistency there afa going back and forth across the panels
and hence across the SC checkpoint...
This is a good point - the current proposal would likely not allow
going back
across the panels as expected.
Based on your and Keith's comments, we are currently taking a closer
look at how SCI & text installer might be plugged in into CUD.
12.2 - "TBD - How to determine if SCI tool should be brought up?"
This is important for AI as we eventually want to support the use
case where a SC profile containing any subset of the parameters
defined in 14.1 would still be a supported SC profile to use with AI.
The usage expectation is perhaps that upon first boot, parameters
would get prompted for? Thoughts on this?
With current proposal, it is assumed that configuration of core set of
parameters defined in 14.1 would happen either in interactive or
non-interactive
way.
If both mechanisms took place, then interactive configuration
would take precedence over non-interactive one.
Such approach provides less flexibility comparing to legacy sysid tools
and it needs to be discussed if this is acceptable limitation.
I don't have huge heartburn if the whole wad of questions had to
be re-prompted for. My question was really whether or not SCI
could automatically get launched if one of the required parameters
was not set (rather than basing it on the specific property to invoke
SCI.)
What particular AI scenario you think would take advantage of this
feature ?
I think the general concept of being self-contained is what I
am striving for. That is, if AI accepted an SC profile that lacked
a piece of configuration that made the resultant installed system
unusable by default (e.g. if root account and user account were
not in the profile), it would be nice if we just launched SCI to
"correct" the issue.
thanks,
-ethan
Thank you for your comments,
Jan
thanks,
-ethan
On 09/16/10 06:32, Jan Damborsky wrote:
Hello Caimaniacs,
first draft of System Configuration Interactive tool design spec
has been published for review:
http://hub.opensolaris.org/bin/download/Project+caiman/System+Configuration+Project/sci%2Dtool%2Dlatest.pdf
During this round, we would like to verify that the proposed
design fits the overall Caiman architecture and that we are
not missing any important requirements or features.
Thus the current version of document lacks details.
We will be elaborating more on them later after we verify
the overall vision.
Susan, if you happen to have cycles to take a quick look
and verify that we are on the right track from
zones point of view, it would be greatly appreciated.
Please provide your comments/feedback before COB Wednesday 9/22.
Thank you very much,
Jan
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
