On 03/ 8/11 04:16 AM, Ethan Quach wrote:
On 03/04/11 05:42, Jan Damborsky wrote:
On 03/ 3/11 06:42 PM, William Schumann wrote:
Ethan,
Please find responses inline. Took your suggestions unless
otherwise noted.
current webrev: http://cr.opensolaris.org/~wmsch/profile4/
differences with last webrev
http://cr.opensolaris.org/~wmsch/profile3-diff/
On 02/24/11 06:12 PM, Ethan Quach wrote:
William,
On 02/16/11 07:43, William Schumann wrote:
current webrev: http://cr.opensolaris.org/~wmsch/profile3/
differences with last webrev
http://cr.opensolaris.org/~wmsch/profile2-diff/
last webrev: http://cr.opensolaris.org/~wmsch/profile2/
TODO: I'm still hanging onto code that extracts hostname and
timezone from profiles until which time I'm sure that its
removal
won't interfere with testing.
Curious. Does this code being left in include the current
support
for the embedded SC profile? I'm noticing that's still in
there and it's something that should be removed by this
project.
Indeed, the embedded SC profile code should be removed from
the AI
client, since the AI client code is bound to the AI service
image.
In a light of CR7023449 Anna recently filed, how process
of fetching SC manifest will work in case AI is booted from
media ?
With William's project, the management of configuration
profiles is
decoupled from the AI manifest, which will indeed be a big
change
for
users because the configuration profile has always been inside
the AI
manifest since the early versions of AI; however, this is the
model
we're moving toward.
Yep. I understand this and support that model.
I was just wondering how that is going to affect the scenario
above.
As a result of this change, the AI booted from media use case
will
change a little bit as well. Namely, the AI manifest provided
at the
prompt will no longer contain a configuration profile in its
content.
This use case has always been a bridge to the true usage of AI
over
the network and in that comparison, it can be looked at as a
semi-interactive mode. As such, the plan for this use case is to
have
SCI tool get launched upon first boot after an AI installation
where
no configuration profile was provided. This will be true for
the AI
netboot case as well, so in that sense, it will be
consistent. I'm
not certain yet how we will configure for SCI tool to get
launched,
but your thoughts on this is appreciated.
I see. Thank you for clarifying that. It sounds reasonable.
I think early on we discussed that it would be nice if SCI tool
(or
the service that launches it) could just automatically detect
if one
or more of the "basic" configuration parameters were missing. Is
this
still the case?
It is not part of current design, only explicit way is to be
supported.
When originally thinking about implicit approach,
all possibilities seemed too fragile and limiting the end
user. In
particular, I think we can't reliably guess user's intent
based on what parameters were configured in SC profile. Also,
booting
the system with completely skipping configuration
step should be possible.
Based on that, system/config smf service will invoke SCI tool
only if
appropriate smf property is configured. It could be
done by dropping canned profile on target - it would just
configure SCI
tool related smf property.
If not, we could perhaps make the AI installer just guestimate
that
when no profiles are given, it should set whatever property it
needs
to set on the system-config service to launch SCI tool.
Yep. I think we could deliver pre-canned SC profile (for
instance as
/usr/share/auto_install/sc_profiles/sci.xml)
which would be used by AI client in case of bootable AI.
I am not sure how network AI should behave in case that no SC
profiles
are supplied from AI server -
in that scenario, do we also want to 'force' invoking SCI tool
at the
first boot or would it be
better to let user make that decision (i.e. assign that SC
profile
on AI
server if interactive post-install
configuration is desired) ?
