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 > >
