Anurag S. Maskey wrote:
Make your start method work w/ the old manifest properties; then no
special upgrade processing is needed. Note that your service can
wait to finish coming on line until manifest-import runs if that's
easier.
NWAM cannot wait for manifest-import to come online because
manifest-import is indirectly dependent on network/physical being
online.
So come on-line, but act like you have no network. If manifest
import cannot run w/o a working network, it would seem that we have
other
problems.
manifest-import doesn't need networking, but it does need NWAM to be
online. But NWAM Phase 1 needs the new manifest before it can be online.
Also, NWAM itself also cannot do a "svccfg import" because the
filesystem is read-only at that time. network/physical stars before
any of the filesystem/* services.
Furthermore, NWAM will not have access to the new SMF properties that
we've added for Phase 1. In the first boot after update, the nwamd
daemon will have to assume that it can only access the old (Phase
0/0.5) SMF properties.
It seems like we need two reboots before users can experience NWAM
Phase 1 :(
After manifest-import runs, is there a way to trigger
network/physical:nwam to restart? I can think of adding another SMF
service that's dependent on manifest-import (yuck!)and it simply does
a "svcadm restart nwam" but that's just hack.
This is pretty ugly, but we could get the first run of
the nwam service to add an invokation of
"svcadm restart nwam" to (the end of) /var/svc/profile/upgrade -
it is executed after most of the work of the manifest-import method
is done (but prior to any site customizations). This would
get the desired behaviour I think, and would be a one-shot thing
if we did it on the basis of an absence of an NWAM phase 1-only
property (e.g. nwamd/upgraded), since that would signal that the
new manifest is not there yet.
Alan
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
