On Tue, 23 Sep 2008 15:53:14 -0700
Renee Danson <Renee.Danson at Sun.COM> wrote:
> An issue that has come up repeatedly in our discussions is how to handle
> renaming of objects, particularly of NCUs. We'd like to be able to include
> support for the vanity naming of links from within your nwam profile; but to
> what extent should those renames be reflected across the entire config? How
> much should be changed when a link name changes? That also leads to the
> technical question of how do we bundle all those changes (to different
> objects)
> into an atomic transaction? How do we guarantee that a fault in the middle
> won't leave the nwam profile repository in an inconsistent state?
You don't bring up the atomic issue again below. I think the broad
brushstrokes of the solution are built around nwamcfgd. It deals with
changes to the configuration using transaction boundaries. Then when
writing the configuration out it uses revision numbers to keep things
consistent.
>
> I'll start with the most fundamental question: what exactly should users be
> able to do when it comes to changing names of nwam profile objects?
>
> For link-type NCUs, there are really two different types of renames:
>
> * I have a link NCU whose linkname is net0, and I want to change the name
> to wired0.
>
> * I have a physical device, bge0, which has linkname net0. I need to swap
> out the bge card for an nge card, but I want the same configuration to
> apply to the new physical link nge0.
>
> In the first case, you would probably want any existing dependencies in the
> system, or an ip ncu that's plumbed above the link, to be changed as well,
> to reflect the new name; that is, you want to replace occurrences of 'net0'
> with 'wired0' throughout the configuration.
>
> In the latter case, the administrator likely does *not* want the new name to
> filter throughout the config; what they want is to move a specific link name
> from one link ncu to another, and have all the configuration that was built
> on that link name move with it.
>
> Ideally, nwam would be able to support both types of changes. However, there
> are several technical challenges in supporting the first case. There are the
> synchronization issues I mentioned above; all of these changes need to be made
> as a single transaction. There's also the issue that changing all the
> occurrences within the nwam config is not sufficient; ipfilter or ipsec rules
> may need to be updated as well, and nwam is not yet magic enough to handle
> that. Finally, there is a user interface concern: how does NWAM determine
> which of these two types of changes the user wants? In both cases, the action
> taken by the user would be the same: change the name of a link ncu. The only
> difference is the goal, and therefore expectations, of the user.
Turning this upside down I think the first thing we have to determine
is how to know which case we are then. Only after that can decide how
to solve each case.
>
> My proposal, then, is that in phase 1, NWAM do the following:
>
> * Phys link ncus (ncus that represent physical devices in the system) have
> a read-only device-name property. Upon creation (when a physical device
> is discovered), the ncu name will be the same as the device-name.
>
> * Changing the [link]name of any ncu will not result in changes beyond that
> ncu. If you change phys link foo0's name to bar0, and have an ip ncu named
> foo0 (with 'under' property set to 'datalink:foo0' and implicit dependency
> on datalink:foo0), that ip ncu will no longer be able to be active, as its
> activation condition will no longer be met.
>
> A useful feature in a UI consumer of libnwam would be a warning when the
> user attempts to change the name of an ncu, noting that a) the link will
> need to be quiesced in order to complete the name change, and that b) the
> name change will only be local to the ncu, it will not affect other parts
> of the configuration. Establishing and making this behavior clear will
> help when adding support for the other type of name change; a tick-box to
> "make this name change globally," for example, will make more sense if one
> first understands the local-only behavior.
The "parameter" that might be indicate this bound vs no bound behavior
might be using the linkid in the under property. If the linkid is used
then the configuration follows independent of the linkname. If the
linkname is used then a separate move is needed.
We had talked a little about using linkid and rejected it but I hadn't
thought about it being useful to differentiate between these two cases.
>
> * The name of an ip ncu will be read-only; changing the 'under' property of
> an ip ncu has the effect of changing the name. These two must be the same;
> an ip interface cannot have a name other than that of the underlying link.
I wanna dislike this. But I can't come up with a good reason. Is
there administrative value in being able to name these objects
separately?
>
> * The current design of the phase 1 gui hides from the user the distinction
> between a link and the ip interface plumbed above it--an entirely
> appropriate
> simplification for this particular user interface. However, this means that
> when a gui user changes a link name, the gui will need to update both the
> link and ip ncus as a single transaction--in effect, a very constrained
> version of the "global change" case. libnwam/netconfigd will support this
> by providing transaction_start and transaction_end functions; changes made
> between these markers will be bundled, and netconfigd will ensure that the
> entire set of updates are made to the repository.
>
> * NWAM must treat 'dladm rename-link' changes the same as changes (insertion/
> removal) to the available physical devices. We need to work with the
> clearview team to figure out how we can use the EC_DATALINK sysevents to
> learn about these events; ideally we would see either a single rename event
> or a remove/add pair, which would allow us to either update or delete/add
> the appropriate phys link ncu(s).
>
>
> As always, comments/questions are welcome.
mph
>
> -renee
> _______________________________________________
> nwam-discuss mailing list
> nwam-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/nwam-discuss
