Jeff Schroeder wrote:
On Tue, Mar 17, 2009 at 3:14 PM, Tom Brown tom@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.