Hi Max, On Mon, Nov 19, 2007 at 12:47:05PM +0800, Max Zhen wrote: > Maybe we need to add some explanation about the semantics of states for > our SMF instances... > > Per our previous discussion, online for an instance means that it is > managed by an policy engine. But, in NWAM case, vlan and aggr is not > currently supported. Does that mean vlan and aggr instances have to be > disabled when we switch from network/physical:default to > network/physical:nwam? If that is the case, does that mean vlan and aggr > is not usable under NWAM?
Yes, to both of your questions. NWAM phase 1 only supports basic network configurations; phase 2 will add support for more complex configurations, including vlans, aggregations, vnics, and so on. This is the primary reason why nwam cannot be the default (or only) policy engine right now. -renee > > Thanks, > Max > > Alan Maguire wrote: > > I've been trying to flesh out the service model a bit > > further based on what we've discussed so far. I'd really > > appreciate any thoughts people might have on this. > > > > thanks! > > > > alan > > > > Below I suggest an approach for managing network > > entities via SMF. Discussed first are the representations > > of the entities themselves, followed by a suggested > > policy-neutral service instance and API to create > > them. These are just suggestions, and I've left out details of > > the NWAM-specific instances (corresponding to what > > are termed locations and external network modifiers), > > since they are policy-specific. > > > > 1. Policy-independent representations of network entities > > (links, IP interfaces etc). > > > > In order to represent network entities as SMF instances, > > we need to be able to create, modify (e.g. for link > > rename) and remove such representations. These activities > > need to be policy-independent, since the representations > > are required whether we are using network/physical:default > > or network/physical:nwam as the policy engine for > > detailed configuration. Note that enable/disable > > of the entities will be determined by the active > > policy. So for example, network/physical:default will > > enable all IP interface instances that have a corresponding > > /etc/hostname.interface file, while NWAM might > > have more complex mutual-exclusion rules such > > as "enable wired link and not wireless" that can dynamically > > change depending on profile applicability. Different > > policy engines might have different rules for > > creating entities too, e.g. NWAM might catch hotplug > > events and create instances appropriately. However > > all will need to catch link renames. > > > > 1.1. svc:/network/datalink > > > > Physical datalinks. At the service level, we define > > the methods, property groups, dependencies and > > documentation info for datalink instances. > > Configuration parameters (such as tunables > > from the Brussels project) that apply across > > all links could ultimately be stored at the > > service level, and sensible defaults could > > be also specified there for NWAM-specific > > config, that the instances then inherit > > and can override via property composition. > > > > Naming: datalink instances are named for their > > (Clearview) vanity names. > > > > Methods: > > > > - start: not clear if this method needs to do > > anything with datalinks as active policy engine will > > be responsbile for configuring wireless etc. May need > > to refresh all policy engines, since the user will > > expect a refresh of the instance to mean > > "reapply policy config". In the NWAM case, this > > would mean applying configuration specified in the > > active NCU (network configuration unit) associated > > with the link instance, in the non-NWAM case, this > > would mean refresh network/physical:default. > > - stop: not clear what this method needs to do > > either, though again we'd need to propogate > > this event to policy engines. > > - refresh: simply propogate refresh to policy > > engines. > > > > Restarter: svc:/system/svc/restarter (default > > master restarter) > > > > Property groups: > > > > - link-generic: containing properties used > > for links in all cases (regardless of policy > > engine), e.g. linkid. > > - NWAM-specific: NCU property group containing > > desired NWAM configuration > > > > Dependencies: > > > > svc:/network/dlmngt:default > > > > Depends on dlmgmtd, since its initialization > > is required before links can be enumerated > > and their representations created. > > > > 1.2. svc:/network/ip > > > > (I think the name network/interface was suggested, > > but that suffers from overloading, and at various > > times can mean the network card, the link or > > the IP-level entity). > > > > IP-level interfaces. One instance is used > > to cover all IPv4 and IPv6 physical and logical > > interfaces (the latter are modeled as additional > > addresses) associated with a link. > > > > At the service level, we define the methods, > > property groups, dependencies and > > documentation info for IP interface instances. > > Again we can store IP-wide tunables at the > > service level (see ndd -get /dev/ip ? > > for a rough list, Brussels will be changing > > things here), and set sensible defaults > > for NWAM at the service level for instances > > to inherit/override via property group composition. > > > > Naming: IP interface instances are named for the > > (Clearview) vanity names of the underlying link. > > > > Methods: > > > > - start: plumb the IP interface(s). May need to > > refresh all policy engines, since the user will > > expect a refresh of the instance to > > mean "reapply policy config". In the NWAM case, > > this would mean applying configuration specified > > in the active NCU (network configuration unit) > > associated with the link instance, in the > > non-NWAM case, this would mean refresh > > network/physical:default. > > > > - stop: unplumb the IP interface(s). Again we'd > > need to propogate this event to policy engines. > > > > - refresh: simply propogate refresh to policy > > engines (replumb if not plumbed anymore?) > > > > Restarter: svc:/system/svc/restarter (default > > master restarter) > > > > Property groups: > > > > - NWAM-specific: NCU property group containing > > desired NWAM configuration for IP interface. > > > > Dependencies: > > > > - svc:/network/dlmngt:default > > > > Depends on dlmgmtd, since its initialization > > is required before links can be created. > > svc:/network/ip > > > > - svc:/network/datalink:[vanity_name] > > > > Will probably need to depend on the corresponding > > datalink instance. > > > > 1.3 possible additional services for IP tunnels, Crossbow > > VNICs etc. > > > > Clearview is rationalizing and simplifying the network > > model, and many network objects are becoming classes > > of datalinks. What I'm wondering is if we wish to > > represent those entities as instances of the datalink service > > described in 1.1, or do we wish to have separate instances > > for VNICs, tunnels etc? One advantage of having separate > > instances is that we can define sensible defaults for those > > entities at the service level, but do we want to underline > > that all of these entities are datalinks in the representation? > > My only concern about doing so is that I suppose that > > vanity naming could lead to instances having names > > which did not clearly reflect what the entities are, > > whereas using the service name to denote this makes > > things clearer. > > > > 2. Creation and manipulation of SMF network entities > > > > We have seen above that we need to create > > representations of datalinks and IP interfaces > > on the system regardless of policy, so given > > that is the case, it seems reasonable to > > disqualify network/physical:default as > > the instance that creates the appropriate > > representations (as it - at least currently - > > represents the application of a specific > > policy, namely plumb IP interfaces which > > have an /etc/hostname.interface file, do > > wireless autoconf for wireless link etc). > > I would suggest perhaps an additional service: > > > > 2.1 svc:/network/config:default > > > > (better naming suggestions would be appreciated!) > > > > Methods: > > > > - start/refresh: for each link on the system, determine > > if there is a datalink instance and corresponding > > IP interface instance. If not, create them. This > > instance could then be refreshed on hotplug insertion > > for example to create the new associated instance. Note > > we probably shouldn't remove instances on hotplug removal, > > since the card could be later replugged and we would > > not then lose the configuration history. > > > > - stop: do nothing > > > > Dependencies: > > > > The service should depend on network/dlmgmt, > > and specify a restart_on "refresh", "require_all" > > dependency on that service. Note: this service > > will have to run reasonably early in boot, need > > to determine what dependencies we need to > > guarantee service creation will succeed. > > > > 2.2 Policy-agnostic API > > > > In addition to the above-suggested service, > > we will likely need a policy-agnostic API to > > create instances for datalinks, IP interfaces > > etc, to move them (for link renames) - copying > > across internal data from old instance name > > to new, to install dependencies (e.g. IP interface > > link depends on assoicated datalink), and delete > > them. Consumers would include: > > > > - the suggested network/config service: to > > create new datalinks/interface instances. we'd > > probably need a program that consumed a > > library API designed to do the above tasks. > > - dlmgmtd: needs to use such an API for link > > renames > > - NWAM > > > > > > Mike Shapiro wrote: > > > >>> from an implementation perspective, it sounds to > >>> me like with this approach, we don't actually need a > >>> delegated restarter to handle links and interfaces. > >>> regardless of which policy engine is active, links and > >>> interface instances have a start method which simply > >>> initializes the underlying object, and from there the > >>> active policy engine carries out configuration. each > >>> policy engine is responsible for creating the interface/link > >>> instances it needs to manage, but the methods that those > >>> instances run are the same regardless of who does the > >>> managing. have i got this right? > >>> > >>> > >> Yes, correct: certainly nothing like the way we define delegated > >> restarters today. That said, in a clustering scenario there will be > >> some action (namely bringing things IFF_UP or not) which is semantically > >> "delegated" to clustering software. But this can be done using the > >> policy engine model (i.e. just some service that further manipulates > >> these abstractions) rather than needing a delegated restarter. > >> > >> > >> > >>> if i understand this correctly then, the semantics of the > >>> instance states reported by "svcs interface" or "svcs datalink" > >>> represent something along the lines of: > >>> > >>> online: the object (datalink or interface) was initialized and is > >>> being managed by the active policy engine. > >>> > >>> > >> Yes. But note that online say for an interface != IFF_UP. It should > >> only mean that the abstraction has been created and the properties > >> assigned. > >> It is not a replacement for the abstraction's own state machine. > >> > >> > >> > >>> maintenance: initialization of the object failed, or the active > >>> policy engine requires user intervention to fix a configuration > >>> problem, and so marked the instance for maintenance. > >>> > >>> > >> Yes. An example would be if your IPv4 address property contained > >> a syntactically illegal value. > >> > >> > >> > >>> disabled: the object is not active - either the policy engine or > >>> the administrator (via "svcadm disable") has specified it is not > >>> to be used. > >>> > >>> > >> Yes. > >> > >> > >> > >>> so in other words, if a link or interface is reported as "online" > >>> in SMF, it does not necessarily imply the entity is fully > >>> configured - rather that it has been initialized, and that the active > >>> policy engine is operating upon it. does that sound right? > >>> > >>> > >> Yes, exactly. > >> > >> -Mike > >> > >> > >> > > > > _______________________________________________ > > nwam-discuss mailing list > > nwam-discuss at opensolaris.org > > http://mail.opensolaris.org/mailman/listinfo/nwam-discuss > > > _______________________________________________ > nwam-discuss mailing list > nwam-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/nwam-discuss
