On Tue, 02 Jun 2009 17:29:57 -0400, Michael DeHaan <mdehaan(a)redhat.com>
wrote:
Assuming we wanted to get 2.0 in a state to release in 1.5 months,
anyone interested in woring on the network objects support?
I /could/ do this, but I think it's one of those atomic chunks that may
make a good thing for someone else to work on ... plus it's pretty close
to being stubbed out.
I think a good place to start is looking over item_network.py and seeing
what fields it has, and what fields it /needs/ to have. Then because
of the field storage changes,
the way it keeps the free list of IPs around needs to be implemented
such that it works again.
(Some steps in the middle I'm sure -- one of the catches is what happens
when we delete a network -- is that even legal if systems are attached?
Probably no, and coming up with a way
to remove a system from a network with the edit command --network="" or
some equivalent, and having the IPs then no longer be pulled from there)
Finally we need to tweak the utils.blender code so that objects with a
network assigned fill the variables from the network.
Similarly on the system edit page of the webapp, if an interface belongs
to a network those fields should be hidden that are sourced from the
network or otherwise populated from the network. TBD.
For those that don't grok what I'm talking about, suppose we define the
following IP setup:
cobbler network add --name=foo --cidr=<range1> --gateway=<ip>
--broadcast=<ip> ...
cobbler network add --name=foo --cidr=<range2> --gateway=<ip>
--broadcast=<ip> ...
cobbler system add --name=bar --network=foo --interface=eth0
--network=foo --mac=AA:BB:CC:DD:EE:FF --dns-name="bar.example.org"
cobbler system edit --name=bar --network=foo --interface=eth1
--network=bar --mac=AA:BB:CC:DD:EE:FE --dns-name="bar.lab.example.org"
cobbler system add --name=baz --network=foo --mac=AA:BB:CC:DD:EE:FD
--dns-name="baz.example.org"
If you notice in the above case, we didn't bother to assign IPs to any
of the systems, yet we were able to assign hostnames directly, because
the network object assigns IPs for us.
There are other applications, such as being able to assign the DHCP/DNS
generator for certain servers to only do it for certain networks, for
instance we could centrally manage everything for an organization at a
central point but a regional/datacenter cobbler server could know to
only template out DHCP/DNS for those systems that were local to it (as
configured in settings). This would also mean we could tell cobbler
replicate to not pull down systems for "foreign" networks.
I could also see a way to flag the network as static, so we wouldn't
have to specify each network as static, and do some nice things there as
well.
If there are no takers I'll probably start looking into this, but even
then some help would be great -- also if you have any additional ideas
about network objects and how they might be able to help you out, let us
know.
My personal network object todo list:
* add --dhcp-able=0/1 flag for network
* add other fields required/recommended for dhcp to network object
- bootp range
- address range
- router/name server/ntp/etc. fields
* update dhcp template to generate network blocks if --dhcp-able=1
* add attached network field to system interface (per-interface)
* move/add server override field to interface
I didn't think about zone management, but that makes perfect sense if for
this too if doing DNS management.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.