Hi Karen,
thank you very much for looking into this.
Please see my response in line.
Jan
On 09/23/10 02:02 AM, Karen Tung wrote:
Hi Jan,
Here are my comments on the document. Sorry I didn't have time
to read through comments others made. If I mention something
that's already been discussed, please just point me to the answer.
General questions or comments:
--------------------------------
- Can the SCI tool be used to re-configure an already configured
system/zone?
No. We assume that SCI tool would be used only for configuration
of freshly installed or un-configured system. That means configured system
has to be un-configured first before SCI tool is run in order to achieve
desired
state. As far as un-configuration step is concerned, Jean is working on that
and she is discussing potential approaches with smf team.
I can see we might be missing some scenarios where reconfiguration could
be useful, but before committing to that, we need to understand if those
scenarios are important enough, so that they could not be left out.
After reading the whole document, I think it can not. If that's the
case,
it would be good to mention that in the document.
I agree - I will clarify that.
Also, what tool should
people use to re-configure their system?
Let me demonstrate on example of cloned zone, how SCI tool could
participate.
This is not the final design, just one of potential approaches:
* cloned zone is created from existing configured one (using 'zoneadm
clone')
As part of cloning process, resulting zone is 'marked' to be
un-configured on
first boot.
* cloned zone is booted into dedicated state where smf framework
activates unconfiguration mechanism.
* After unconfiguration is done, standard boot is resumed during which
SCI tools is brought up (alternatively, non-interactive configuration
takes place).
- From reading the use cases in section 12, I finally understand that the
SCI tool is used for generating a SMF properties profile that will be
consumed
the next time the system boots up. It would be nice to talk
about *how* SCI tool configures the system in some sort of
an overview section.
You are right. I will clarify that.
Section 6.2:
------------
- "global zone" is a supported working environment. Under what
circumstances
will the SCI tool be used in a global zone?
We are thinking about pre-installed images, replication (analogy of
flash archives).
Section 12.2:
--------------
- I am confused by the first bullet.
"SCI tool invoked by start method of
svc:/system/install/config:default smf service".
I thought the SCI tool is invoked as a standalone application.
To me, that means that is something a user/role would
execute a command to run. What does that have to do with a SMF service?
Let me try to clarify. By standalone application it is meant that it is
not part
of text installer, but instead separate 'binary'.
In most common scenarios (e.g. installed/cloned/migrated zone), we want that
tool automatically be invoked during first boot of installed system at
the right
point - this is why it is called from svc:/system/install/config:default
smf service.
Section 14.2.1:
----------------
- I am a little concern about implementing the SC module as a
checkpoint to
be executed by the engine. I know that the engine can run
non-interactive checkpoints. I am sure how well it will handle
checkpoints
that require user interaction. Have you try it to see whether it works?
No, I have not tried yet, so I do not know if it will work. Keith and Ethan
also pointed out that this part should be reconsidered, so we will be giving
it more thoughts :-)
section 15:
-----------
- Is the svc:/system/install/config:default SMF service going to be a
deliverable?
That service was already delivered by one of System Configuration project
pieces. It currently takes care of user/root account configuration on
system installed by means of AI. If you are interested in more information,
there is a design spec available for taking a look:
http://hub.opensolaris.org/bin/download/Project+caiman/System+Configuration+Project/scsmfdesignlatest.pdf
- 2nd bullet: If the SC Module will really be a checkpoint, I believe
it should
be delivered into
/usr/lib/python2.6/vendor-packages/solaris_install/scm.py
like all other checkpoints in CUD.
Thank you for pointing this out. At this point, it seems likely that it will
not be a checkpoint.
Thanks,
--Karen
On 09/16/10 06:32 AM, 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
