On 08/30/11 15:33, Ethan Quach wrote:
Karen,

Just to be sure, does croinfo also depend on devchassisd? If so, I'm wondering if the relevant service here should be svc:/system/devchassis:daemon (or perhaps both to be clear.)
Hi Ethan,

Good point, I didn't know about svc:/system/devchassis:daemon.  Drew told me
croinfo depends on fmd. Looking at the man page for devchassisd, I think that's likely
the service that's actually providing the information consumed by croinfo.
svc:/system/devchassis:daemon is dependent on fmd SMF service.
Perhaps that's why making our services depend on fmd SMF service
appears to work.

I think the correct fix should be to make setup-install and auto-install SMF service
depend on svc:/system/devchassis:daemon

I will make that change and test it out.

--Karen



On 08/29/11 11:54, Karen Tung wrote:
I am trying to figure out what's the best way to fix bug 7083584:

7083584 snv 172 text installer does not initially present SAS drive 
aliases/receptacles
http://monaco.sfbay.sun.com/detail.jsf?cr=7083584

Receptacle information is not displayed the first time text installer
is run because fmd SMF service is not online yet, and croinfo command
replies in fmd to get the information.

To confirm that the bug exists because fmd service is not yet online,
I built a special ISO where I make the install-setup SMF service dependent
on fmd SMF service, and the bug submitter confirmed that problem is gone.

Even though this problem is reported on the text installer,
it could also exist for the other installer images, since there's
no explicitly dependency to make sure that the installers
are not run until fmd is up.

I can think of 2 ways to fix the problem, both have it's advantages
and disadvantages.  I would like to hear your opinion on which way
is better.

Solution 1
--------------
Make install-setup SMF service(used by text installer) and
manifest-locator SMF service(used by AI) dependent on fmd SMF service.
There's no SMF service that starts the GUI installer, but since it
takes so much longer to start X server, GNOME, auto-login..etc..
By the time the GUI installer starts, fmd will very likely be online already.

The advantage of this approach is that we just let SMF take care of
the dependencies.  The disadvantage is that if fmd failed to start
for some reason, the installers will fail to start too.  Furthermore,
if fmd takes a long time to start, the installers will appear to take
a long time to start.  I booted the text installer image I built with
fmd dependency on my laptop.  I don't notice any difference in
start up time.  I am not sure whether fmd will take much longer
to start on machines with SAS drives.

To me, it would seem like any frailty or expediency issues are really just issues in those services and would ultimately need to be addressed there. Solution 2 seems like it's preemptively working around this.

-ethan


Solution 2
---------------
Add code in target discovery to check the status of fmd SMF
service.  Right before we need to run the croinfo command, we check
for the status of the fmd service.  It's it's not yet online, we wait a
specified period of time. If it is still not online by the time we finish waiting, we will log a message in the installer log indicating the problem, and proceed
with running croinfo to retrieve the information...etc..

The advantage of this approach is that even if fmd SMF service fail for
some reason, people can still use the installers as usual.  Also, there's
no potential start up delays.  The disadvantage is that we need to have
special code in our gate to handle SMF status.

I prefer solution 2, Drew prefers solution 1.

We would like to hear your thoughts.

Thanks,

--Karen



_______________________________________________
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

Reply via email to