+++ Perry N. Myers [12/09/08 15:28 -0400]:
The relationship between Host and Bonding is a one-to-many, so we're alreadyable to do the multiple Bondings. I don't want to do the relationship from the Host to the Bonding through the Nic though 'cause that's not a naturalway of thinking about it to me; i.e., the Bonding is an aspect of the Host soit should be hung there.Ok. So initially a Host can have multiple Bondings and each Bonding on a Host must have the same BondingType. Eventually we'll support multiple Bondings on each host with independent BondingTypes. This right?
We won't need to change the model at all: we support multiple bondings right now. The limitation is just in the user interface design. But if Tim can do a design taking those multiples into consideration, we won't need to change any of the backend code I've written for the server.
Or something like that. Bonded interfaces all need to be on the same physical network (so have the same label) and the Label associated with a set of bonded interfaces is the same as the underlying interfaces.For the bondings that would be the alias. For the nics we could have a fieldnext to each mac address where the admin could enter an alias for that and have it persisted.Well, the alias should be a rollup of the labels for the bonded interfaces. i.e. if you have 2 NICs bonded and each of them are labelled "LAN A" the alias for the bond should also be LAN A
Ah, okay, I see what you're saying. Not a problem. We can get the alias from the Bonding pretty easily through the Nic. -- Darryl L. Pierce, Sr. Software Engineer Red Hat, Inc. - http://www.redhat.com/ oVirt - Virtual Machine Management - http://www.ovirt.org/ "What do you care what other people think, Mr. Feynman?"
Description: PGP signature