[email protected] wrote:
On (04/10/09 21:24), Erik Nordmark wrote:
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.
Then again, thinking about this in the context of the other design-review
discussion (around handing dhcp/static/autoconf addresses) brought up
a question: even though we have an ipadm_create_interface() that
consolidates all the plumbing logic, we are proposing to discard
the '/sbin/ipadm create-interface', and instead make the interface
plumbing to be implicit in addr-creation (be it by dhcp/static/whatever).
Presumably we'd still need a libipadm call to create an IP interface
explicitly since dhcpagent needs to be able to create it without (yet)
having an address to assign to it. (There might be a philosophy that
dhcpagent in fact creates an address object with address 0.0.0.0, and
then later modifies that address or deletes that object should it fail
to obtain a lease, but I don't think we should derive the model from our
current behavior.)
But then, if someone has created configuration on a non-existent
interface, and later the underlying datalink for that interface is
added to the system, how does one activate the latent configuration?
E.g., the net-physical script will need something like
"ipadm create-interface", or "ipadm init-intfprop <intf>" to create
the interface and apply the latent configuration.
That is an implementation matter, right?
For dladm we solve it my keeping the properties for missing interfaces
in user space and some upcall to retrieve them when the object comes
into existence. One could do the same for these missing objects, or one
can keep the objects around in the kernel even though they have
references to objects which do not exist. But in either case, it doesn't
affect what the desired behavior should be for the system.
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?
e.g., with dladm, we only write out the property configuration to
datalink.conf if the attempt to set the property in the kernel succeeds.
So syntax/sanity checking is done at least once, before saving the
configuration. But even with this model, there's a problem reporting
errors during boot, when the driver autoconfigures itself, and sucks
down the persisten properties from dlmgmtd- if an error occurs, say,
when there's a syntax error for a property in an under-link of an
aggregation, error reporting, and recovery from partial configuration
is not easy- its not impossible to do, but not always simple either.
We probably have a lot more non-universal properties in dladm than in
ipadm. But I can think of one for ipadm.
I setup the system with link1 being a pt-pt interface.
Thus I do some
ipadm create-address destination=10.2.2.2 link1/10.1.1.1
Then link1 disappears.
When it reappears, whether or not Vanity naming is involved, it is no
longer a pt-pt type link.
What we'd want for those cases is that the whole create-address that is
triggered by the link reappearing fail. We don't want e.g., that the
address is created and the local address is set, but the destination is
not set.
And we'd need some place to report these errors.
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
