Peter Memishian wrote:
> This is great, thanks for writing this up. A few ideas and comments
> that occurred to me along the way:
Thanks for the review.
>
> * In the "main benefits" bullet list, a related case is using
> vanity naming to insulate the system from non-hardware changes
> too -- e.g. deployments of aggregations and VLANs can be done
> seamlessly.
True, I thought about this, but was worried about complicating the wording
to a point that it would become meaningless to the ley reader. I've
attempted to be more general in bullet 2 to address this. Let me know what
you think.
>
> * Second paragraph of Example 1: s/isn't't/isn't/
Fixed.
>
> * After the "dladm create-aggr" in Example 1: "Any name can be
> chosen" isn't quite true. We should mention the namespace
> format requirements and also s/name/unused name/.
Fixed.
> * General comment: persistence isn't covered in the whitepaper.
> We should probably mention that (like other dladm subcommands)
> dladm rename-link will persist unless -t is used.
Sure, I can mention that, but I don't want to give specific examples of
usage with -t. I don't want this to be the comprehensive documentation for
dladm, but rather a launching point for people to see what's possible and
what the benefits are. They can go from here to read the documentation and
complete their understanding.
> Also, at
> least for example 1, we should mention that any files with the
> old names (such as the list mentioned in Example 2) would need
> to be located and updated.
I understand what you're suggesting, but I'm not sure where the best place
to say this is in example 1. I've added a note at the end of the example,
is this what you had in mind?
> * Regarding Example 2: if the rename-link is done after the
> "cfgadm -c configure", will IP get properly reconfigured with
> public0's configuration? In other words, will the dladm
> rename-link cause the IP RCM module to get run again and thus
> make use of /etc/hostname.public0? (IIRC, another way to do
> Example 2 is to do the dladm rename-link before the cfgadm
> configure).
I'm basing the order of the commands in this example on the following text
in Cathy's UV design doc:
# cfgadm -c disconnect PCI8
remove bge0 and insert ce0
# cfgadm -c configure PCI8
# dladm rename-link ce0 net0
Note that the order of the cfgadm and rename-link operations will
not matter, i.e., following configuration steps will achieve the
same result:
# cfgadm -c disconnect PCI8
remove bge0 and insert ce0
# dladm rename-link ce0 net0
# cfgadm -c configure PCI8
I'm assuming that the two are equivalent. The first order makes a ton more
sense to me, as you may not know what to rename until you plugin the new NIC
and run "cfgadm -c configure ...". Maybe someone who has done DR testing
with UV can confirm. Cathy, can you provide input on this?
> * Regarding Example 3: Is migration impossible, or just difficult
> and error-prone? Or, phrased differently, if this is
> impossible, then the lab router configuration in Example 1
> (where we renamed links and then hunted down any affected files)
> also seems impossible. Or am I missing your point?
It's not impossible, my wording is way too strong. I've changed this. It's
more complicated than example 1 because in addition to the configuration
files within the zone filesystem, we'd also have to go tweak the zone
configuration itself with zonecfg to change which IP interface is being
used. It's not impossible indeed.
-Seb
