On Tue, Mar 17, 2009 at 3:29 PM, Michael DeHaan <mdehaan(a)redhat.com> wrote:
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.
That was just a quick solution for his idea with minimal code changes.
I personally can't believe anyone wouldn't have the datacenter staff
set these as static ips. You don't want out of band management
dependent on anything but your networking gear but that is just me.
--
Jeff Schroeder
Don't drink and derive, alcohol and analysis don't mix.
http://www.digitalprognosis.com