[et-mgmt-tools] Cobbler: defining network profiles

[Michael DeHaan]

Peter Wright wrote:
>
> Hristov, Georgi wrote:
>> This reminds me a lot of AIX NIM (Network Installation Manager
>> http://www.redbooks.ibm.com/abstracts/sg247296.html). NIM has similar
>> functionality. Actually, NIM would even setup a static route on a
>> provisioned system if the system is being installed via a secondary NIC.
>> This functionality is made possible via the knowledge of networks,
>> similar to what is being discussed here.
>>   
> Hmm - I think this is a little different, unless I misunderstand the 
> proposal.  Since I think most sites are using dhcp reservations, I 
> think the proposed patch is to break out the IP management 
> functionality from the "cobbler system" command set.
>
> -pete

Pete's correct though I haven't looked into the above much.   It would 
work for static configs as well as DHCP reservations.  Certaintly DHCP 
reservations are preferred and much much easier, though in the static 
case, all of the added variables are still very nice to have for 
kickstart templates.

To get a bit technical, the previous way of working will still work.

cobbler system add --name=foo --ip=foo1 --mac=foo2 --gateway=foo3 
--subnet=foo4

Except that (as proposed) I see this as having each interface will now 
have an additional shortcut that will fill in the others if they are not 
already set.

cobbler system add --name=foo --network=alpha

This would not actually store the IP and data with each system, but 
would fill them in from the alpha part.

Possibly this could be smart enough to pick ips's from within the 
netmask.  If doing this, we probably do something internally like 
assigning the --ip field to a special counter like maybe "*1", "*2", and 
so on, and then let blender() in utils.py calculate it using the 
netmask.    For those not familiar with the point of blender, it's that 
in Cobbler, everything is generated from a tree that overrides things on 
the way down.   Systems override profiles, subprofiles if present 
override their parents, profiles override distros.   This function 
ensures that all of the variables that appear in DHCP and elsewhere 
represent that configuration once it is evaluated.

So this would in theory allow reassigning the subnet with a:

"cobbler network edit --name=alpha --subnet=foo5 && cobbler sync"

And then not having to update any of the system objects.   We'd just 
need to have a way to give them all nice unique ID's so the DHCP 
reservations remain intact when we add new records, so something like 
assigning the first free increasing integer to the system and storing it 
there and then doing some simple math to align those with the subnets 
should be sufficient.

We'd want to make sure that if we added a two hundred systems, then 
deleted a hundred, the next one added starts back at the first free 
slot, and that adding systems didn't move the reservations around.  This 
is probably pretty simple to do.

More people here probably have better network management expertise than 
I do, so let me know if I'm missing something in terms of use cases and 
so forth.

cobbler could also probably ship with "default" networking parameters in 
/etc/cobbler/settings too, so many people would not have to create their 
own networking object.   I handle kernel options something like this, so 
if someone defines their subnet there and enables DHCP management, 
reservations would then start working and automatically handing out 
IPs.   We'd probably also want an additional configuration setting to 
decide whether or not to start handing them out in the block, probably 
defaulted off, with good comments in the settings file about how that 
would all play together.

Very interesting idea folks!

--Michael