In order to configure a NIC and also use bonding/fail-over, we need a way to:
1. associate one or more BondingType objects to the Host via the Bonding
class.
2. associate which of the Host's Nic objects will be a part of each Bonding
object.
3. set the ip address, netmask, etc. for a Nic that's not enslaved.
Here's a crude ASCII of what I"m thinking.
[ Select a bonding type v ] [ Add ]
Bonded interface alias: _bond0_____________________ [ Remove ]_
Bonded interface name: _ovbond0____________________
Network Interfaces:
00:11:22 [ ] Enslave to ovbond0 IP Address: _______ Netmask: ____ |
11:22:33 [X] Enslaved to ovbond0
22:33:44 [X] Enslaved to ovbond0
[ Save Changes ]
1. The user selects a bonding type and clicks "Add". The bonded
interface
fields are displayed.
2. The user clicks "Remove" to destroy the interface. When that
happens, any
enslaved Nic is released but not destroyed.
3. If the user clicks the checkbox to enslave an interface then the IP
address and netmask fields go away.
--
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?"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://listman.redhat.com/archives/ovirt-devel/attachments/20080912/4ac8f43e/attachment.sig>
Darryl L. Pierce wrote:> In order to configure a NIC and also use bonding/fail-over, we need a > way to: > > 1. associate one or more BondingType objects to the Host via the Bonding > class.Should we model this by associating a BondingType to a set of NICs rather than a Host? I know initially we're only going to support on BondingType per Host as to simplify things, but it might make sense to structure the data model to make it easier to transition to the more flexible approach. For the time being we can make the restriction that once you're created one set of bonded interfaces and have selected Type X for those interfaces that all other interfaces on the Host can only use type X. That's a simple restriction in the UI that doesn't affect the data model.> 2. associate which of the Host's Nic objects will be a part of each Bonding > object. > 3. set the ip address, netmask, etc. for a Nic that's not enslaved.Or allow DHCP, right?> Here's a crude ASCII of what I"m thinking. > > > [ Select a bonding type v ] [ Add ] > > Bonded interface alias: _bond0_____________________ [ Remove ]_ > Bonded interface name: _ovbond0____________________ > > Network Interfaces: > 00:11:22 [ ] > Enslave to ovbond0 IP Address: _______ Netmask: ____ | > 11:22:33 [X] Enslaved to ovbond0 > 22:33:44 [X] Enslaved to ovbond0 > > [ Save Changes ] > > > 1. The user selects a bonding type and clicks "Add". The bonded interface > fields are displayed. > 2. The user clicks "Remove" to destroy the interface. When that happens, > any > enslaved Nic is released but not destroyed. > 3. If the user clicks the checkbox to enslave an interface then the IP > address and netmask fields go away.So is this a UI that appears on an 'Edit Node' page? How does the user get to this page? And how would it look if there were multiple Bond objects? (i.e. is Bonded Interface Alias a drop down list?) What about configuring the IP addresses statically for interfaces that are not bonded? As an aside, we should probably allow interfaces to be 'labeled'. i.e. For each Interface object associate a label that can be used by a hardware Admin to know what physical network that interface is attached to. Interface with MAC 11:22:33:44:55:66 is on "LAN A" 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. Perry