[Ovirt-devel] Re: Configuration NICs

[Perry N. Myers]

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 at redhat.com                      -=|
|=-         Office: +1 412 474 3552   Mobile: +1 703 362 9622         -=|
|=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=|