[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Ovirt-devel] Re: Configuration NICs



Darryl L. Pierce wrote:
+++ Perry N. Myers [12/09/08 14:56 -0400]:
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.

The relationship between Host and Bonding is a one-to-many, so we're already
able 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 natural
way of thinking about it to me; i.e., the Bonding is an aspect of the Host so
it 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?

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?

Oops, forgot to mention that. If the IP address is nil then the configuration
generator chooses DHCP for the boot protocol.

Ok.



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?)

These are the details that I was afraid to face initially without getting
someone like Tim involved. I think that a dropdown listing the bondings would
be the way to go when we support more than one bonding.

Tim, can you work with Darryl and Scott to do a mockup of what this should look like so we can implement it the right way :)

What about configuring the IP addresses statically for interfaces that are not bonded?

That's the example with mac 00:11:22 above: if the box isn't checked, then
you can enter the ip address and netmask in the field next to the interface.

Ok, the UI diagram above only assumes a single Bond per host... Yeah, we need to work out a UI where multiple Bonds are allowed... It gets more complex then.

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.

For the bondings that would be the alias. For the nics we could have a field
next 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

Perry


--
|=-        Red Hat, Engineering, Emerging Technologies, Boston        -=|
|=-                     Email: pmyers redhat com                      -=|
|=-         Office: +1 412 474 3552   Mobile: +1 703 362 9622         -=|
|=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=|


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]