[et-mgmt-tools] Pending support for multiple NICs in cobbler/koan (FYI)

[Michael DeHaan]

Ok... so it's about done, but not quite :)

So lots of folks have expressed interest in being able to provision 
hardware with Multiple NICs (for instance you might want to use cobbler 
to manage DHCP for both of them), as well as create virtual machines 
that way.  For those that are so interested, read on.   This is 
describing how things work upstream now (in git) as I work on polishing 
this up.  I would not recommend trying the codebase at this point, 
though it should be ready for experimentation soon enough. 

It's going to work much like before.  In the interest of readability, 
I'm giving command line examples, though this will all work through the 
Web UI also.
All the old commands and the old templates you have will still work.   
Upgrades will be seamless also.

Here's how it works now: 

cobbler system add --name=test1234 --mac=AA:BB:CC:DD:EE:FF 
[--ip=192.168.1.50] [--hostname=test12345.example.com] [--dhcp-tag=...] 
[...]

If you want more NICs, it's:

cobbler system add --name=test1234 --mac=AA:BB:CC:DD:EE:FF 
[--ip=192.168.1.50] [--hostname=test12345.example.com]
                                [--mac1=...] [--ip1=...] 
[--hostname1=...] [--dhcp-tag=...]

Koan looks the same, basically (for both Xen or KVM, depending on your 
virt type setting in cobbler).   Notice these are unchanged:

koan --server=cobbler.example.org --virt --profile=profileXYZ
koan --server=cobbler.example.org --virt --system=test1234

However, if you need to override the virtual bridge to be used, you can 
only do so for --profile (not --system) in koan.   (Also, for profiles, 
the restriction is that you'll only get one NIC with a random MAC.    
You can't get two.).   This is so that we don't inflate koan with a lot 
of options that duplicate things in Cobbler.

So, the virtualization provisioning by profile remains as:

koan --server=cobbler.example.org --virt --profile=profileXYZ 
[--virt-bridge=mybridge0]

If you wanted to specify a cobbler system that used two seperate 
bridges,  you now have to do that in cobbler.   If you don't define 
them, cobbler will
need to try and guess, and most likely you do not want that...  Besides, 
with this much information it will be good to keep it all centrally:

cobbler system add --name=test1234 --mac=AA:BB:CC:DD:EE:FF 
[--ip=192.168.1.50] [--hostname=test12345.example.com] 
[--virt-bridge0=xenbr0]
                                [--mac1=...] [--ip1=...] 
[--hostname1=...] [--virt-bridge1=xenbr1]

I'll make this much more clear on the Wiki as things go on.   I don't 
think it really complicates things in practice as if you don't want 
multiple NICs for virtual machines,
this is all largely optional... and for those that do, the Web UI will 
make it easy enough to understand.   I wanted to bring this up now for 
those that had an idea
how they thought multiple NICs might work from a user perspective to 
speak up if this really wouldn't work for them.

Another topic -- Earlier there was the discussion of having overrides 
for things like the virtual mac address in koan.   Given the complexity 
of all of the above, and wanting to keep things simple and centrally 
managed, this is most likely not going to happen as it would 
overcomplicate the model a bit too much.   Again, these are things that 
are easily
enough expressed in cobbler.

Right now we can override -virt-name, --virt-path, and --virt-type in 
koan ... which will likely stay for now, though since they are all 
settable in cobbler they may become
deprecated.  - -virt-name can be controlled by creating a system object, 
--virt-path can be set in profile and/or system objects, and --virt-type 
can be set globally and in the various objects.

For hardcore templating users, variables like $mac_address can be used 
for the first entry (backwards compatibility), though 
$mac_address_intf1, and $mac_address_intf2 will also work. Or you'll be 
able to walk the interfaces as they are exposed to templating as a hash.

If anyone is manually generating YAML to create Cobbler files, this does 
imply a format change, so it would be a good time to switch over to the 
cobbler API.   (I know a few people are mapping Cobbler from LDAP this 
way...which is not really a version-safe way to go).

Hopefully I did not confuse anyone too much by the above. 

Again, the WUI code is not in git yet, and koan isn't completely tested, 
but that is my best guess as to how the above will look at this point.   
More info on the Wiki later.


--Michael