Thank you for clarifying that, Sean.
Yeah, I am aware of the lack of synchronous restart,
since we had to deal with that limitation couple of times
during sysconfig implementation.
Though so far we have been operating under assumption that
'svccfg apply' and manifest-import produce equivalent results
as far as application of smf profiles is concerned
and nobody questioned that during our long smf discussions :-).
PSARC/2011/108 is not quite clear about that aspect when it says:
...
Because we want to encourage manifests in standard locations,
we intend to deprecate use of svccfg import, and push most uses
to "svcadm restart manifest-import". Administrators who wish to
apply XML-specified changes at the administrative layer should
use svccfg apply. svccfg apply will take both manifest and profile
bundle files.
svccfg import will work in compatibility mode with a warning.
svccfg apply of standard-location profiles will also work in
compatibility mode with a warning.
...
Jan
On 11/09/11 16:25, Sean Wilcox wrote:
The behavior should be put a manifest or profile in a standard
location, and
then restart the manifest-import service to manage your files that you
are putting
in the standard location.
The problem is that the restart of manifest-import is an asynchronous
operation
that you would then have to monitor to know that it was complete.
This is not
ideal, and there is a bug filed to provide a synchronous restart so
that the proper
action can be taken, 6370885. The simplest fix in this case is to set
the environment
variable because this is what you will gain once the bug is fixed and
the manifest-import
service is restarted.
On 11/09/11 03:31, Jan Damborsky wrote:
Hi Ginnie,
if I understand the underlying problem correctly, it is caused by the
fact
that 'svccfg apply' does not store hashes for profiles applied. Thus,
if such
profile is then later removed, manifest import does not recognize
that and
doesn't remove related configuration from site-profile layer unless
there is another change in site profiles which has its has recorded
in smf.
If my understanding is correct, then I am wondering if this behavior
is intentional
or if it's a bug, as such behavior is apparently confusing.
Pulling Sean into the loop who may shed more light on this aspect.
Thank you,
Jan
On 11/08/11 15:35, Virginia Wray wrote:
Hi All --
Could I get a review for the following CR:
http://monaco.sfbay/detail.jsf?cr=7105569
Webrev is located at:
https://cr.opensolaris.org/action/browse/caiman/ginnie/7105569/webrev/
Seb -- if Sean Wilcox didn't satisfactorily answer your question in
the affiliated bug, please let me know.
Thanks,
ginnie
_______________________________________________
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
