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
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
