Huafeng Lu writes:
> 篋\x8E 2008綛\xB410\xE6\x9C\x8828\xE6\x97\xA5 01:10, James Carlson
> \xE5\x86\x99\xE9\x81\x93:
> > 2. Storing parameters in SCF
[...]
> It looks natural to map a VRRP instance/group to a SMF instance. Note, a
> VRRP group as a whole should also map to a SMF instance in this way. And
> the two advantages Jim listed are valid. But the biggest problem, I
> think, is the inconsistence of the admin interface presented to the users.
There's no necessary mapping here between design and administrative
interface. Using SMF and SCF doesn't mean that you must _force_ users
into using any of the svccfg or svcadm tools.
> In the current design, there's only one VRRP SMF service instance, and
> it uses a single configuration file,
I don't think that matters. Based on your documentation, the
configuration file appears to be not intended as an interface. That's
really part (2) in my description above -- how to store the
parameters.
> whose location is the only SMF
> property of the VRRP SMF service. All VRRP related operations are done
> by using the "vrrpadm" tool.
Providing such a tool that can control all operations is a good
solution. There's no reason to abandon that solution just because
you're using separate SMF instances.
> If each VRRP instance/group is mapped to a SMF instance, how to do the
> operations?
>
> 1. To create a VRRP instance/group. First need to create a new SMF
> instance using "svccfg -s network/vrrp <vinst_name>". Then the user
> needs to use "svccfg -s network/vrrp:<vinst_name> setprop ..." to set
> all properties of the VRRP instance. Then "svcadm refresh". Finally the
> user issue "svcadm enable ...", which calls "vrrpadm create ..." to
> create the VRRP instance.
Why not just have the user do "vrrpadm create", and have vrrpadm call
libscf internally?
> Note, "svccfg setprop" can modify all SMF properties, which map to VRRP
> properties, but will lead to different VRRP operations. Changes to VRRP
> priority, adv interval, accept mode, etc, will trigger "vrrpadm modify";
> changes to external executables will trigger "vrrpadm register";
> changes to "fatal" properties such as VRID, ifname, primary IP address
> will require a restart of this VRRP instance.
There's no necessary requirement for that. The design is entirely in
your control. Plus, what you're talking about here is still tied up
in question (2), and we're trying to solve (1).
Possible choices consistent with factoring this service into separate
SMF instances (per (1)) include:
- Properties are stored in SMF (actually SCF). The vrrpadm
interface allows you to change those properties; it calls libscf
to change the permanent storage, and invokes a private UNIX socket
mechanism to make run-time changes in the daemon. Those using
'svccfg' instead (not the recommended interface) will have to
refresh and restart the daemon.
- Properties are stored in SCF. The vrrpadm interface allows you to
change those properties, and it calls libscf to do that. It also
sends a signal to the daemon to tell it to refresh properties when
there are changes. That same signal is the :kill refresh method
in the service manifest.
- Properties are stored in an undocumented (private) configuration
file somewhere in /etc. The vrrpadm interface allows you to
change those properties by writing to that file, and it uses a
private UNIX socket to notify the daemon of changes. There are no
SMF-related changes here *EXCEPT* that there's a separate SMF
instance per VRRP group/instance.
That's not an exhaustive list. You can design other possible answers.
Note that not all of them necessarily involve storing your parameters
in SMF/SCF.
> 5. To show the run time attributes of VRRP instances/groups, "vrrpadm
> show" is needed; no corresponding SMF commands to do this. (And we can
> expect more operations in the future which cannot be handled directly by
> SMF commands.)
Sure. That's one of several reasons why vrrpadm is needed.
The SMF system architecture has *NEVER* insisted that subsystems
abandon their own configuration utilities. In fact, just the
opposite: it's a assumed that non-trivial subsystems will have their
own utilities for configuration, because the raw SMF interfaces are
too complex and lack domain-specific error checking.
The only real difference between old-style and SMF design is where the
data are stored.
> So we can see three different types of admin interfaces for different
> operations: (1) Some (show) must use vrrpadm(1M) directly; (2) some
> (destroy) can use SMF command; (3) some (create, register, etc) should
> use a wrapper to encapsulate multiple SMF commands (take "create" as an
> example: a wrapper should contain "svccfg add", multiple "svccfg
> setprop", "svcadm refresh" and finally "svcadm enable").
Not true.
> Jim had some comments under item 5 above:
> > Actually, I'd encourage such an implementation to call libscf from
> > vrrpadm (perhaps indirectly via libvrrp), and include commands to
> > manipulate instances and properties in addition to just getting
> > status.
> >
> > Just because something is factored into SMF doesn't mean that users
> > need to be forced into using the svccfg command.
> I think the key idea is to use libscf to read some properties from SMF
> configuration repository, and use vrrpadm/libvrrp to get the others.
> Since Jim also mentioned "to manipulate instance and properties in
> additon to just getting status", I guess it's not just for "show", but
> also for other operations such as "create", where vrrpadm (via libvrrp)
> calls libscf to write the properties into the repository. (Is my
> understanding right, Jim?)
Yes.
> This looks to me like that part of the SMF features (storing properties
> into SMF configuration repository) becomes part of the service that it
> manages, so that the service itself is unable to run by itself (i.e.,
> not from the SMF infrastructure). I'm not quite comfortable with this.
I don't understand why you're not comfortable with that. SMF is part
of Solaris. It's not an "option" that anyone can elect to ignore, or
that might somehow go missing. It's a core component of the operating
system and a fundamental part of how it works.
Also, it seems that you're still talking about (2) for some reason,
and I thought we'd already noted that this is a completely separate
issue. The separate instance question should be distinct from the
parameter storage question.
All that aside, there are many ways to skin this cat, and what you're
describing is not a necessary conclusion. Here's yet another short
list of alternatives:
- Make the daemon run a single group/instance. Give it command-line
options that can be used to set all of the parameters needed for
that operation. Provide a simple method script to invoke the
daemon, and have that script invoke 'svcprop' to read SCF and set
up the proper command line.
- Make the daemon run a single group/instance. Make it read
parameters directly from libscf (assuming defaults where the
parameters are missing), and allow override from the command line
using options. You likely won't need a method script if you do it
right, and you'll still be able to invoke without using SMF at
all.
As before, there are many other ways to design this. It's not
necessary to create a daemon that is dependent on SMF for operation,
but I don't think it's a bad thing, either. In fact, when you
eventually go to ARC review, I think you should have to justify any
non-SMF operation you support. The big question there, given that SMF
is a core OS feature, is "why?"
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
[email protected]
