[et-mgmt-tools] Question regarding api.sync and the necessity of using MAC addresses as system.name in dhcp templating

[Adam Rosenwald]

Is the requirement of using MAC addresses as system.name as a prerequisite
for DHCP templating necessary?  I'm trying to understand the reason for the
decision to enforce this policy.  Hardware addresses should all be
considered 'unique', so the problem lies with duplicate virtual MAC
addresses (at least those attached to the systems provisioned with cobbler),
no?  If this is the reason, I would recommend a resolution as follows:

By default make virtual MAC addresses randomly assigned.  The script from
http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Virtualization-en-US/ch19s21.htmldoes
the job.  Maintain an array of cobbler-provisioned MACs and check
against the array before assigning a new, random MAC address to a
provisioned virtual system.  The default behavior can be overridden by the
use of another (optional) command line argument to 'cobbler system
(add|edit)'.  This frees up system.name to be any valid hostname and mirrors
the behavior of 'xm create'.  A more robust solution would be to have a
/var/lib/cobbler/macs file (bound to the array) which would allow users to
manually provision virtual servers and add the noncobbler-provisioned MACs
to the list if they so desired.

If there is another reason for depriving dhcp templating (and tied-in
arguments; e.g. xen domU names) of anything other than MAC addresses, I
would be curious to understand why.

Thanks,

 - Adam.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/et-mgmt-tools/attachments/20070426/b6b0e46f/attachment.htm>