[email protected] wrote:
right, and in the current model, "ipadm show-prop -P" will display
the information pertaining to persistent information.
As I pointed out, the missing aspect is orthogonal to
persistent/temporary since with DR interfaces can disappear without a
reboot.
Thus I think -P is the wrong tool here.
Displaying properties for missing interfaces by default makes more sense.
Note that the "missing" aspect is orthogonal to "persistent across
reboots vs. temporary" since with DR we could even have "temporary"
properties (should we decided we need to support such beasts) end up
referring to missing IP interfaces.
Given that the property is maintained by the system and can be shown, it
would also make sense for the admin to at least be able to destroy it
(in case the admin really doesn't want it to be applied when bge0 is
plugged back in.) and probably also be able to change it.
True. in fact "dladm delete-interface -P" should be the functional
equivalent of "dladm create-interface -t"- both would not change the
saved-config to hold the interface info, but will change the running
config.
Let's not confuse persistent/temporary with missing; they are orthogonal.
And for consistency reasons, since the system can have properties for
interfaces that have disappeared, it probably makes sense to optionally
allow the creation of properties for interfaces that does not (yet)
exist, but relying on a force flag to avoid a typo in the name of the IP
interface being interpreted as a reference to a non-existing interface.
For example:
# ipadm set-prop -p mtu=1400 -m ip bge1
dladm: interface "bge1" does not exist; use -F to set property
for non-existent interfaces
# ipadm set-prop -F -p mtu=1400 -m ip bge1
If that general approach is sensible for ipadm properties, it probably
also makes sense for IP address management, and it might make sense to
apply it to dladm as well.
this part, while a neat idea, would need some careful design to be
consistently available across all the adminstrative levels. Particularly,
recovering from (or even reporting) badly constructed commands must
be done with care..
I don't understand what you mean with badly constructed. Do you have an
example?
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
