Jeff Schroeder wrote:
On Tue, Mar 17, 2009 at 3:14 PM, Tom Brown <tom(a)ng23.net>
wrote:
> Robert Lazzurs wrote:
>
>> Thinking about this in terms of what is 'really' there...
>>
>> The power control interface is just an entry of what address to
>> connect to for controlling the power for a system so it should not be
>> in there and I don't think we should be taking DHCP information from
>> there, this seems 'unclean'.
>>
>> However the DRAC and iLO cards are network interfaces on the systems
>> from a hardware point of view so either these should be treated as
>> systems them selfs or as network interfaces of the parent system. Now
>> this is what I am doing at the moment because I figured in the future
>> cobbler could host 'images' for upgrading devices like these, switches
>> or routers lets say. This makes a lot of sense to me and fits in the
>> current model, what do other people think?
>>
>>
> i would class them as part of the main system or as some kind of sub
> system - maybe using the system they are attached to as a parent?
>
> you cant really have a drac or iLo without a parent system even though
> they do run their own OS etc - Having one main system and these cards as
> part of that main system seems like the right way to me but be
> interested in what others thought
>
Instead of DRAC for dell, ILO for HP, and ILOM/ALOM for sun servers,
why not have a generic interface name? Something like mgmt? If there
were "multiple" ones for some very bizzare reason you could just
append a number to it but that is pretty unlikely.
Something like:
root@cobbler1: ~ # cobbler system report --name servername.location
system : servername.location
profile : Fedora-10-x86_64
comment :
created : Tue Feb 3 21:56:04 2009
gateway : 10.101.200.1
hostname : servername.location
image :
kernel options : {}
kernel options post : {}
kickstart : <<inherit>>
ks metadata : {}
mgmt classes : []
modified : Tue Mar 17 18:16:38 2009
name servers :
name servers search : <<inherit>>
netboot enabled? : True
owners : ['admin']
server : <<inherit>>
template files : {'/srv/templates/gmond.conf-init.location':
'/etc/gmond.conf', '/srv/templates/snmpd.conf.location':
'/etc/snmp/snmpd.conf', '/srv/templates/ntp.conf.location':
'/etc/ntp.conf', '/srv/templates/ldap.conf.location':
'/etc/ldap.conf'}
virt cpus : <<inherit>>
virt file size : <<inherit>>
virt path : <<inherit>>
virt ram : <<inherit>>
virt type : <<inherit>>
power type : ipmitool
power address :
power user :
power password :
power id :
interface : eth0
mac address : 00:11:43:E0:7A:E4
bonding :
bonding_master :
bonding_opts :
is static? : True
ip address : 192.168.109.254
subnet : 255.255.255.0
static routes : []
dns name : servername.location
dhcp tag :
virt bridge :
interface : mgmt
mac address : 00:13:43:E5:7C:E2
bonding :
bonding_master :
bonding_opts :
is static? : True
ip address : 10.143.200.250
subnet : 255.255.255.0
static routes : []
dns name : servername-mgmt.location
dhcp tag :
virt bridge :
Then add something in the network configuration snippet to skip over
writing out /etc/sysconfig/ifcfg-mgmt*. Actually this would be pretty
cool for cobbler to do. Its not even much of a code change. What do
you think?
Works for me, I still want to know what people expect to do with them
though. Do you just want to DHCP manage them?
If we were to do that, a field on the interface that says
--management=True/False (default False) could suffice.
Snippets would need updating, but not bad.
Show we what you'd want to do with the data.