On 09/21/10 12:26 PM, Keith Mitchell wrote:
On 09/21/10 07:53 AM, Jan Damborsky wrote:
Hi Keith,
thank you very much for looking into this.
Please see my response in line.
Jan
On 09/17/10 11:53 PM, Keith Mitchell wrote:
Hi Jan,
I have a number of comments, mostly because I know I'll end up
working with you on this so I want to make sure I understand things
as well as I can. I like the design here, mostly because I think the
transition of the system configuration related screens from the text
installer to the SCI tool will be relatively painless.
General: The design depends on text installer using the new install
engine - will all work to convert the text installer to use the
engine be part of this project, or is it expected that the text
installer will be converted first, then the SCI tool implemented and
the text installer updated to consume it? I think I know the answer,
but I want to be sure.
This is something which requires further discussion as I can
imagine different approaches might be taken based on when
other components are available.
As an one extreme, I am wondering if in the first phase system
configuration
part could be completely separated out from text installer and run
independently
without significantly changing existing user experience.
That would allow breaking dependency on having text installer converted
into CUD.
The reasoning behind this is that SCI tool is key component in new
sysconig portfolio, since without that we can't get rid of legacy sysid
tools.
I agree that it should be possible to remove SCI's dependency on CUD.
I think it might be possible to have text installer run SCI "in-line"
so to speak, which could maintain the user experience but remove the
dependency on the engine. Of course, getting the text installer
converted over to the engine would be ideal, but I agree that the SCI
tool is more important than converting text installer.
8.2: I don't know if this is worth mentioning in the doc itself, but
I wanted to add that I think there will end up being 3 portions of
the migration:
* Common UI library (port text installer generic UI components to a
more accessible location/package - this should just be a packaging
change)
* SCI screens (consume the common UI library)
* Text Installer changes (embed relevant SCI screens, consume common
UI library)
I think it is worth mentioning this in the doc - I will add this
information.
Indeed this approach will be really useful as there could be future
tools that would be easily able to utilize the UI.
12.1: This is very different from how I thought that text installer
might consume the Install Engine, so I have a few questions.
Initially, when first thinking about how text installer might use
the engine, I thought that the Text Installer application would own
the responsibility of interacting with the user (gathering input,
displaying information to the screen, etc.) and that engine tasks
would happen in the background. In other words, I envisioned the
Text UI owning the 'screens', and the Engine owning the data and
disks (to put it roughly).
This design doc appears to propose that a checkpoint within the
Engine would have to control the terminal/console, at least during
certain parts of the install process, which means that one must
manage how to pass control of the display between the text installer
application and the system configuration checkpoint. I don't know if
that will be easy or if it will be difficult, but it does seem
awkward at first glance. One must also extrapolate to the GUI
installer (even though the GUI installer is not being considered
here, I think we should be at least somewhat aware of it so that if
a GUI SCI tool were available we could potentially incorporate it
into the GUI installer).
To put it succinctly, I'm not certain that "UI control" checkpoints
make sense for the engine (maybe they do, maybe they don't, but I
think more information is needed before a final decision is made).
I can see your point - let me think more about this. I will take a
closer look at CUD pieces and
will get back to you on this particular aspect.
I'm continuing to mull it over as well.
14.1.1: Currently, the text installer doesn't have a language/locale
screen, as the user is prompted for that information during boot. I
assume this screen would be skippable dependent on such factors?
The idea here was that SCI locale screen would replace language
screen displayed during boot process.
How would one choose the language for the installer itself, in this case?
I thought it was the other way around too for the reason Keith mentions.
i.e. if the user chose the language early on, then the text-installer
would be display output in that language use that as the default
language selection. This would enable one to skip the language
selection screen.
14.1.4: This screen is skipped in the text installer case if there
is only one NIC available on the system - would this continue to be
true?
It makes sense. Unless Frank has objections, I am fine with that.
14.1.6: Is it safe to assume that this screen would be disabled
unless a second option for naming services (beyond DNS) is added?
That sounds reasonable. We need to consult with Frank UI design of
those screens.
There are provisions in the text installer UI flow for easily skipping
certain screens - they may not be the most elegant (this SCI work will
be a good chance for me to see about streamlining some things in the
UI flow...)
14.1.5, 14.1.7: Currently in the text installer, these 2 screens are
combined. One of the goals for our installers has been to keep the
number of screens to a minimum. In general, it seems the SCI tool is
increasing the number of screen. What's the user experience impact
of injecting additional screens in this manner?
I agree - the current proposal mimics UI of legacy sysid tools
and is very likely subject of change. Again, we need to involve Frank
in this :-)
Certainly. It also sounds like there's some flexibility in that it
will probably be acceptable to have more screens for the text
installer since that installer targets more advanced users who might
want more configuration options at install time.
14.2.1: "SC module will support mechanisms for customizing set of
displayed screens based on specified running environment."
One of the things I dislike most about our current mechanism for
ICTs is how they make decisions based on environment (e.g.,
existence of .autoinstall file) rather than making those decisions
based on parameters passed in. I'd prefer not to see the SCI tool go
the same route, and rather, allow the application to *tell* the SCI
tool what it should do, rather than the SCI tool "guessing" based on
environment. To quote the "Zen of Python" (PEP 20) - "Explicit is
better than implicit."
I am in agreement with you on that, I didn't explain it correctly in
doc.
I wanted to say that SC module would provide mechanism for
customizing set of screens
to be displayed.
The decision which set of screens is to be presented should be made
outside
of SC module, or completely outside of SCI tool. SCI tool could
accept environment
type as command line parameter.
As an example, when launched from smf service, it could look like:
[...]
. /lib/svc/share/smf_include.sh
env_type="global_zone"
if smf_is_nonglobal_zone; then
if smf_configure_ip; then
env_type="non_global_zone_exclusive_ip"
else
env_type="non_global_zone_shared_ip"
fi
fi
/usr/sbin/system-config -t $env_type
[...]
Thanks for the explanation - that's definitely a much better method of
running it. I might like to see this taken a step further, though - e.g.:
if smf_is_nonglobal_zone; then
if smf_configure_ip; then
/usr/sbin/system-config --zone --ip-config=yes
else
/usr/sbin/system-config --zone --ip-config=no
fi
else
/usr/sbin/system-config --all
fi
One caveat to all this: It sounds like a user will *never* run
/usr/sbin/system-config, is that correct (i.e., sysconfig will always
run via SMF or an installer)? If so, then your approach above, or one
similar to my suggestion, is the right way. But if a user might ever
execute system-config (perhaps for a reconfiguration case, if that's
not doable via SMF), then I think it might be more acceptable for the
system-config tool to make assumptions based on environment (so long
as that can be overridden for purposes such as testing/debugging).
In other words, the exposed interface should implicitly use
environment to execute the internal interface into SCI.
15: Should the python module(s) delivered be under
"solaris_install"? Or, better yet, a top level vendor-package called
"sysconfig"?
Sounds reasonable. I tend to prefer separate 'sysconfig' directory -
I will update doc accordingly.
Agreed.
Thanks,
Keith
As mentioned above in my comments on 8.2, I imagine we'll want to
factor generic UI components into a common area (that is, somewhere
other than solaris_install). Perhaps a "textui" package (text UI
literally meaning text UI, *not* as a shorthand for "Text Installer
UI"), or maybe "terminalui".
Sounds good to me.
Thanks,
Keith
----- [email protected] 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
