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.
Anurag,
I suggest looking at how network/ipfilter handles a similar
configuration upgrade scenario, migrating existing ipf settings to the
new repository properties. A quick overview:
Versioning: network/ipfilter manifest defines the new
firewall_config_default/version property to store the current
configuration version. The property has a default value of 0 which gets
updated after every successful upgrade. The start method has a new
hard-coded version in its method script which it compares to the current
version (value in the property) to determine whether an upgrade is
necessary (this also allows us to upgrade between different versions).
Starting logic: network/ipfilter start method performs an upgrade if
- aforementioned version property exists
- and the version value is a down-rev
If the version property doesn't exist, the service needs to wait for
manifest-import and simply returns 0 (quasi-online state).
Manifest-import will request a service refresh once it completed
importing the new manifest. The service's refresh method determines if
an upgrade is necessary using the same logic (though it's guaranteed to
have the new property), and simply does 'svcadm restart' to request the
start method to perform the upgrade.
It is not perfect but seems to work fine for network/ipfilter. We're
also contemplating enhancement to SMF to simplify the upgrade use cases,
perhaps an upgrade that prior to start method if an upgrade is
necessary. Stay tuned.
cheers,
-tony
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
