sowmini.varadhan at sun.com 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
