Menno Lageman writes:
> The description for 6509298 (syslog manifest should be constructed so
> syslog can be replaced with syslog-ng) reads:
>
> "Some customers would like to replace syslog with syslog-ng. This is
> difficult currently because all properties for our syslog daemon are
> defined on the service. They should be defined on the instance so that
> an alternate syslog-ng instance will work properly."
This change is required due to a significant bug in how svccfg handles
import of two different manifests defining different instances on the
same service. :(
The change will simply be desired once svccfg import is fixed (as part
of the profiles project). Unfortunately, it's somewhat challenging to
fix and the best way is via a set of architectural changes to the
underlying repository that will be coming along with the profiles
project.
>
> As I am currently learning my way around libscf, this made me wonder
> what the subtle differences are between scf_service_get_pg(3SCF) and
> scf_instance_get_pg(3SCF) for instance (no pun intended), if used in a
> service with a 'default' instance (e.g. svc:/system/foobarbaz:default).
> Are there any differences? If so, when should I opt for
> scf_service_get_pg() and when for scf_instance_get_pg()?
If you use scf_instance_get_pg_composed() to do your reads you don't need
to worry about it. If you use naked scf_[service|instance]_get_pg(),
you do.
The basic theory is that services are objects for shared configuration
and instances implement a specific running copy of that shared config.
Thus, we want the instances to be able to override configuration. We
call this property composition.
This leads to 3 potential configuration situations. Here's how they
resolve and how you can explore them from the command line. An
important note is that svcprop -C lets you explore the uncomposed view.
1) property set on service (A=true), not instance
Read with scf_service_get_pg(), you'll get to A=true.
Read with scf_instance_get_pg(), you won't see A.
Read with scf_instance_get_pg_composed(), you'll get to A=true.
Read with svcprop, you'll get A=true.
Read with svcprop -C svc:/service:instance you won't see A
Read with svcprop -C svc:/service you'll see A=true
2) property set on service (A=true) and instance (A=false)
Read with scf_service_get_pg(), you'll get to A=true
Read with scf_instance_get_pg(), you get to A=false
Read with scf_instance_get_pg_composed(), you'll get to A=false
Read with svcprop, you'll get A=false
Read with svcprop -C svc:/service:instance you'll see A=false
Read with svcprop -C svc:/service you'll see A=true
3) property set on instance, not service (A=false)
Read with scf_service_get_pg(), you won't find A
Read with scf_instance_get_pg(), you get to A=false
Read with scf_instance_get_pg_composed(), you'll get to A=false
Read with svcprop, you'll get A=false
Read with svcprop -C svc:/service:instance you'll see A=false
Read with svcprop -C svc:/service you won't see A
svccfg also gives you access to an uncomposed view so that you can
choose to set the property on the instance for specific configuration
or on the service for shared configuration.
Choosing between scf_service_get_pg() and scf_instance_get_pg() for
writing allows you to influence the composition more directly. For
most people (as opposed to svccfg authors), writing to the instance is
usually the appropriate choice.
We really need a (non-crappy) simplified library to deal with this. As
Mike's enumerated, scf_simple* functions are a pain to use but I do want
to introduce a simplified reading/writing library that gives you closer
to "do what I want" semantics on the repository without having to know
the nitty gritty details. Some consumers will want to choose whether
to put things on the service or instance, but far from all.
liane
--
Liane Praza, Solaris Kernel Development
liane.praza at sun.com - http://blogs.sun.com/lianep
