This morning I had a quick idea that I thought I might throw out and see if anyone else could use it. Basically the idea is having cobbler provision storage for hosts based upon management classes or some other configuration management construct. Cobbler would need to be taught about accessing SAN and NAS devices to construct volumes and SAN luns, and then have those volumes mounted and/or formatted during the provisioning process of the host. Anyone think it is a good idea or have any comments on it?
On Thu, 28 May 2009 13:08:25 -0400, Scott Henson shenson@redhat.com wrote:
This morning I had a quick idea that I thought I might throw out and see if anyone else could use it. Basically the idea is having cobbler provision storage for hosts based upon management classes or some other configuration management construct. Cobbler would need to be taught about accessing SAN and NAS devices to construct volumes and SAN luns, and then have those volumes mounted and/or formatted during the provisioning process of the host. Anyone think it is a good idea or have any comments on it?
Not a bad idea, other than the fact that no company I've ever worked at would allow the linux server read/write access to the SAN/NAS devices :)
On Thu, May 28, 2009 at 10:18 AM, James Cammarata jimi@sngx.net wrote:
On Thu, 28 May 2009 13:08:25 -0400, Scott Henson shenson@redhat.com wrote:
This morning I had a quick idea that I thought I might throw out and see if anyone else could use it. Basically the idea is having cobbler provision storage for hosts based upon management classes or some other configuration management construct. Cobbler would need to be taught about accessing SAN and NAS devices to construct volumes and SAN luns, and then have those volumes mounted and/or formatted during the provisioning process of the host. Anyone think it is a good idea or have any comments on it?
Not a bad idea, other than the fact that no company I've ever worked at would allow the linux server read/write access to the SAN/NAS devices :)
You don't have admin nodes for netapps? It is the best way to manage them.
On Thu, 28 May 2009 10:20:46 -0700, Jeff Schroeder jeffschroed@gmail.com wrote:
On Thu, May 28, 2009 at 10:18 AM, James Cammarata jimi@sngx.net wrote:
On Thu, 28 May 2009 13:08:25 -0400, Scott Henson shenson@redhat.com wrote:
This morning I had a quick idea that I thought I might throw out and
see
if anyone else could use it. Basically the idea is having cobbler provision storage for hosts based upon management classes or some other configuration management construct. Cobbler would need to be taught about accessing SAN and NAS devices to construct volumes and SAN luns, and then have those volumes mounted and/or formatted during the provisioning process of the host. Anyone think it is a good idea or have any comments on it?
Not a bad idea, other than the fact that no company I've ever worked at would allow the linux server read/write access to the SAN/NAS devices :)
You don't have admin nodes for netapps? It is the best way to manage
them.
EMC DMX's and (at my last company) 3PARs. The storage teams at both companies don't like anyone else touching their storage devices.
James Cammarata wrote:
On Thu, 28 May 2009 13:08:25 -0400, Scott Henson shenson@redhat.com wrote:
This morning I had a quick idea that I thought I might throw out and see if anyone else could use it. Basically the idea is having cobbler provision storage for hosts based upon management classes or some other configuration management construct. Cobbler would need to be taught about accessing SAN and NAS devices to construct volumes and SAN luns, and then have those volumes mounted and/or formatted during the provisioning process of the host. Anyone think it is a good idea or have any comments on it?
Not a bad idea, other than the fact that no company I've ever worked at would allow the linux server read/write access to the SAN/NAS devices :)
Suppose there starts to be some where there are significantly less employees because they were replaced by Cobbler, perhaps :)
New motto: Those who fight us will be replaced by small Python scripts!
or perhaps
New motto: We're building SkyNet, please help contribute to building your new evil overlords!
--Michael
Suppose there starts to be some where there are significantly less employees because they were replaced by Cobbler, perhaps :)
New motto: Those who fight us will be replaced by small Python scripts!
or perhaps
New motto: We're building SkyNet, please help contribute to building your new evil overlords!
The codename for 2.0 _needs_ to be SkyNet. :D
James Cammarata wrote:
Suppose there starts to be some where there are significantly less employees because they were replaced by Cobbler, perhaps :)
New motto: Those who fight us will be replaced by small Python scripts!
or perhaps
New motto: We're building SkyNet, please help contribute to building your new evil overlords!
The codename for 2.0 _needs_ to be SkyNet. :D
I was leaning on "MacGyver" [1] or "Snowball" [2], there will be time to add "SkyNet" [3] once it becomes Self Aware [4].
[1] - http://en.wikipedia.org/wiki/MacGyver [2] - http://en.wikipedia.org/wiki/Pinky_and_the_Brain [3] - http://en.wikipedia.org/wiki/Skynet_(fictional) [4] - We need to do something with registering systems via nmap, just because I really like nmap [5] [5] - I have a footnotes problem.
On Thu, May 28, 2009 at 10:08 AM, Scott Henson shenson@redhat.com wrote:
This morning I had a quick idea that I thought I might throw out and see if anyone else could use it. Basically the idea is having cobbler provision storage for hosts based upon management classes or some other configuration management construct. Cobbler would need to be taught about accessing SAN and NAS devices to construct volumes and SAN luns, and then have those volumes mounted and/or formatted during the provisioning process of the host. Anyone think it is a good idea or have any comments on it?
Sounds like something you should wrap around cobbler and not put inside it. At Ticketmaster, we used a tool for this aptly named provision[1]. For virtual machines, libvirtd should do the storage stuff for you. Perhaps someone should rewrite provision in python or just add in hooks to use non-netapp (generic linux) storage. It also seems like the kind of thing Satellite or the open source project it sits ontop of should implement. What do you think?
[1] http://code.ticketmaster.com/index.php?page=provision-overview
Jeff Schroeder wrote:
On Thu, May 28, 2009 at 10:08 AM, Scott Henson shenson@redhat.com wrote:
This morning I had a quick idea that I thought I might throw out and see if anyone else could use it. Basically the idea is having cobbler provision storage for hosts based upon management classes or some other configuration management construct. Cobbler would need to be taught about accessing SAN and NAS devices to construct volumes and SAN luns, and then have those volumes mounted and/or formatted during the provisioning process of the host. Anyone think it is a good idea or have any comments on it?
Sounds like something you should wrap around cobbler and not put inside it. At Ticketmaster, we used a tool for this aptly named provision[1]. For virtual machines, libvirtd should do the storage stuff for you. Perhaps someone should rewrite provision in python or just add in hooks to use non-netapp (generic linux) storage. It also seems like the kind of thing Satellite or the open source project it sits ontop of should implement. What do you think?
[1] http://code.ticketmaster.com/index.php?page=provision-overview
To me, Scott's idea is interesting and gets us out of a rut (that being, where does Cobbler go from here). I'm interested more in finding out who /does/ like it, since silence on a list implies the No. We're likely to try this out and then see who uses it. Namely I'm interested in ideas on where we can take similar ideas.
If we limited ourselves to the conventional view of how things are managed today, we are very unlikely to /change/ the way things are managed. If we stopped at just kickstart, we wouldn't be where we are today. Our goal is simply -- how much can we automate within a very simple framework. Messaging wise, Cobbler is a bunch of glue that makes setting up new systems easier. Usage of lots of parts of it are optional, and not required to be understood for newcomers, or used in all setups... so I think it's fine (and highly beneficial) to experiment and see where we can take things.
As for what should sit where, I can't agree with you.
Libvirt doing storage is done at the wrong level, because we also care about providing storage to hosts. It's also persuing networking configuration, which in many ways is not correct either, as we also care about networking for hosts. Further, while cobbler is consumed by Satellite, we do not limit what deployment/setup/systems-management tasks we can do. We want to do things at a level which are abstracted for both physical and virtual machines.
So, what about Satellite? Satellite is a great app... but one easy reason there -- it's much harder to implement things in Spacewalk/Satellite, it's not a good codebase for rapid prototyping (not the fault of folks that work on it, it just does a LOT). Since we are already doing things like DHCP, DNS, power, puppet-integration, and so forth (resources needed for the machine before it exists) and moving towards Network objects, modelling storage setup also seems useful to me. Things we do for Cobbler /do/ make it into Satellite, as we expose those in the Satellite GUIs and so forth, and make them supportable.
So this "do one thing" thing...
Ultimately our goal is to automate what we can automate, and gather information from people wherever we can find it. In this sense, Cobbler is a snowball for any sort of automating annoying repeated tasks that you need to do to get systems up and running, and makes it especially nice when folks are starting from scratch and needing OSS tools to do this. We want to prevent building custom automation infrastructure by providing a community where we can all share in that development.
If Cobbler's definition expands over time, I see that as progress.
I don't think we want another competing management tool (and adding a subproject adds overhead) when you can use Cobbler without using all of it's features. For instance, DHCP/DNS management today are totally optional. I do think possibly incorporating some of those ideas from your TicketMaster app could be excellent though, and I definitely welcome all of that. We do want to absorb all of the good (Free) ideas wherever they lie and accumulate all that knowledge together.
--Michael
cobbler-devel-bounces@lists.fedorahosted.org wrote on 05/28/2009 03:14:42 PM:
Jeff Schroeder wrote:
On Thu, May 28, 2009 at 10:08 AM, Scott Henson shenson@redhat.com
wrote:
This morning I had a quick idea that I thought I might throw out and
see
if anyone else could use it. Basically the idea is having cobbler provision storage for hosts based upon management classes or some
other
configuration management construct. Cobbler would need to be taught about accessing SAN and NAS devices to construct volumes and SAN
luns,
and then have those volumes mounted and/or formatted during the provisioning process of the host. Anyone think it is a good idea or have any comments on it?
Sounds like something you should wrap around cobbler and not put inside it. At Ticketmaster, we used a tool for this aptly named provision[1]. For virtual machines, libvirtd should do the storage stuff for you. Perhaps someone should rewrite provision in python or just add in hooks to use non-netapp (generic linux) storage. It also seems like the kind of thing Satellite or the open source project it sits ontop of should implement. What do you think?
[1] http://code.ticketmaster.com/index.php?page=provision-overview
To me, Scott's idea is interesting and gets us out of a rut (that being,
where does Cobbler go from here). I'm interested more in finding out who /does/ like it, since silence on a list implies the No. We're likely to try this out and then see who uses it. Namely I'm interested in ideas on where we can take similar ideas.
If we limited ourselves to the conventional view of how things are managed today, we are very unlikely to /change/ the way things are
managed.
If we stopped at just kickstart, we wouldn't be where we are today. Our goal is simply -- how much can we automate within a very simple framework. Messaging wise, Cobbler is a bunch of glue that makes setting up new systems easier. Usage of lots of parts of it are optional, and not required to be understood for newcomers, or used in all setups... so I think it's fine (and highly
beneficial) to experiment and see where we can take things.
As for what should sit where, I can't agree with you.
Libvirt doing storage is done at the wrong level, because we also care about providing storage to hosts. It's also persuing networking configuration, which in many ways is not correct either, as we also care
about networking for hosts. Further, while cobbler is consumed by Satellite, we do not limit what deployment/setup/systems-management tasks we can do. We want to do things at a level which are abstracted for both physical and virtual machines.
So, what about Satellite? Satellite is a great app... but one easy reason there -- it's much harder to implement things in Spacewalk/Satellite, it's not a good codebase for rapid prototyping (not
the fault of folks that work on it, it just does a LOT). Since we are
already doing things like DHCP, DNS, power, puppet-integration, and so forth (resources needed for the machine before it exists) and moving towards Network objects, modelling storage setup also seems useful to me. Things we do for Cobbler /do/ make it into Satellite, as we expose those in the Satellite GUIs and so forth, and make them supportable.
So this "do one thing" thing...
Ultimately our goal is to automate what we can automate, and gather information from people wherever we can find it. In this sense, Cobbler is a snowball for any sort of automating annoying repeated tasks that you need to do to get systems up and running, and makes it especially nice when folks are starting from scratch and needing OSS tools to do this. We want to prevent building custom automation infrastructure by providing a community where we can all share in that development.
If Cobbler's definition expands over time, I see that as progress.
I don't think we want another competing management tool (and adding a subproject adds overhead) when you can use Cobbler without using all of it's features. For instance, DHCP/DNS management today are totally optional. I do think possibly incorporating some of those ideas from your TicketMaster app could be excellent though, and I definitely welcome all of that. We do want to absorb all of the good (Free) ideas
wherever they lie and accumulate all that knowledge together.
--Michael
cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
+1 from here for Scott's idea. I happen to be knee-deep in cobblering 64 HP blades with Emulex FC mezzanine cards connecting multiple volumes triple-multipath to an IBM XIV :-)
Owen.Mann@interactivedata.com wrote:
cobbler-devel-bounces@lists.fedorahosted.org wrote on 05/28/2009 03:14:42 PM:
Jeff Schroeder wrote:
On Thu, May 28, 2009 at 10:08 AM, Scott Henson
shenson@redhat.com wrote:
This morning I had a quick idea that I thought I might throw out
and see
if anyone else could use it. Basically the idea is having cobbler provision storage for hosts based upon management classes or some
other
configuration management construct. Cobbler would need to be taught about accessing SAN and NAS devices to construct volumes and SAN
luns,
and then have those volumes mounted and/or formatted during the provisioning process of the host. Anyone think it is a good idea or have any comments on it?
Sounds like something you should wrap around cobbler and not put inside it. At Ticketmaster, we used a tool for this aptly named provision[1]. For virtual machines, libvirtd should do the storage stuff for you. Perhaps someone should rewrite provision in python or just add in hooks to use non-netapp (generic linux) storage. It also seems like the kind of thing Satellite or the open source project it sits ontop of should implement. What do you think?
[1] http://code.ticketmaster.com/index.php?page=provision-overview
To me, Scott's idea is interesting and gets us out of a rut (that
being,
where does Cobbler go from here). I'm interested more in finding out who /does/ like it, since silence on a list implies the No. We're likely to try this out and then see who uses it. Namely I'm interested in ideas on where we can take similar ideas.
If we limited ourselves to the conventional view of how things are managed today, we are very unlikely to /change/ the way things are
managed.
If we stopped at just kickstart, we wouldn't be where we are today. Our goal is simply -- how much can we automate within a very simple framework. Messaging wise, Cobbler is a bunch of glue that makes setting up new systems easier. Usage of lots of parts of it are optional, and not required to be understood for newcomers, or used in all setups... so I think it's fine (and
highly
beneficial) to experiment and see where we can take things.
As for what should sit where, I can't agree with you.
Libvirt doing storage is done at the wrong level, because we also care about providing storage to hosts. It's also persuing networking configuration, which in many ways is not correct either, as we also
care
about networking for hosts. Further, while cobbler is consumed by Satellite, we do not limit what deployment/setup/systems-management tasks we can do. We want to do things at a level which are abstracted for both physical and virtual machines.
So, what about Satellite? Satellite is a great app... but one easy reason there -- it's much harder to implement things in Spacewalk/Satellite, it's not a good codebase for rapid prototyping
(not
the fault of folks that work on it, it just does a LOT). Since we
are
already doing things like DHCP, DNS, power, puppet-integration, and so forth (resources needed for the machine before it exists) and moving towards Network objects, modelling storage setup also seems useful to me. Things we do for Cobbler /do/ make it into Satellite, as we expose those in the Satellite GUIs and so forth, and make them supportable.
So this "do one thing" thing...
Ultimately our goal is to automate what we can automate, and gather information from people wherever we can find it. In this sense, Cobbler is a snowball for any sort of automating annoying repeated tasks that you need to do to get systems up and running, and makes it especially nice when folks are starting from scratch and needing OSS tools to do this. We want to prevent building custom automation infrastructure by providing a community where we can all share in that development.
If Cobbler's definition expands over time, I see that as progress.
I don't think we want another competing management tool (and adding a subproject adds overhead) when you can use Cobbler without using all of it's features. For instance, DHCP/DNS management today are totally optional. I do think possibly incorporating some of those ideas from your TicketMaster app could be excellent though, and I definitely welcome all of that. We do want to absorb all of the good (Free)
ideas
wherever they lie and accumulate all that knowledge together.
--Michael
cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
+1 from here for Scott's idea. I happen to be knee-deep in cobblering 64 HP blades with Emulex FC mezzanine cards connecting multiple volumes triple-multipath to an IBM XIV :-)
cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
You may be a perfect one to ask for them.
Assuming we added options to cobbler system objects to make this easier (and possibly profiles), what would you envision this looking like?
(Perhaps we could add cobbler "noun" objects to model the devices themselves like we're going to do for networks, I don't know if that would be required -- it could end up being somewhat simpler like how we handle power)
You may be a perfect one to ask for them.
typo, I mean "you may be a perfect one to ask about this then"
Assuming we added options to cobbler system objects to make this easier (and possibly profiles), what would you envision this looking like?
(Perhaps we could add cobbler "noun" objects to model the devices themselves like we're going to do for networks, I don't know if that would be required -- it could end up being somewhat simpler like how we handle power)
cobbler-devel-bounces@lists.fedorahosted.org wrote on 05/28/2009 04:08:22 PM:
Owen.Mann@interactivedata.com wrote:
cobbler-devel-bounces@lists.fedorahosted.org wrote on 05/28/2009 03:14:42 PM:
Jeff Schroeder wrote:
On Thu, May 28, 2009 at 10:08 AM, Scott Henson
shenson@redhat.com wrote:
This morning I had a quick idea that I thought I might throw out
and see
if anyone else could use it. Basically the idea is having
cobbler
provision storage for hosts based upon management classes or some
other
configuration management construct. Cobbler would need to be
taught
about accessing SAN and NAS devices to construct volumes and SAN
luns,
and then have those volumes mounted and/or formatted during the provisioning process of the host. Anyone think it is a good idea
or
have any comments on it?
Sounds like something you should wrap around cobbler and not put inside it. At Ticketmaster, we used a tool for this aptly named provision[1]. For virtual machines, libvirtd should do the storage stuff for you. Perhaps someone should rewrite provision in python
or
just add in hooks to use non-netapp (generic linux) storage. It
also
seems like the kind of thing Satellite or the open source project
it
sits ontop of should implement. What do you think?
[1] http://code.ticketmaster.com/index.php?page=provision-overview
To me, Scott's idea is interesting and gets us out of a rut (that
being,
where does Cobbler go from here). I'm interested more in finding
out
who /does/ like it, since silence on a list implies the No. We're likely to try this out and then see who uses it. Namely I'm interested in ideas on where we can take similar ideas.
If we limited ourselves to the conventional view of how things are managed today, we are very unlikely to /change/ the way things are
managed.
If we stopped at just kickstart, we wouldn't be where we are today. Our goal is simply -- how much can we automate within a very simple framework. Messaging wise, Cobbler is a bunch of glue that makes setting up new systems easier. Usage of lots of parts of it are optional, and
not
required to be understood for newcomers, or used in all setups... so I think it's fine (and
highly
beneficial) to experiment and see where we can take things.
As for what should sit where, I can't agree with you.
Libvirt doing storage is done at the wrong level, because we also
care
about providing storage to hosts. It's also persuing networking configuration, which in many ways is not correct either, as we also
care
about networking for hosts. Further, while cobbler is consumed by Satellite, we do not limit what deployment/setup/systems-management tasks we can do. We want to do things at a level which are
abstracted
for both physical and virtual machines.
So, what about Satellite? Satellite is a great app... but one easy reason there -- it's much harder to implement things in Spacewalk/Satellite, it's not a good codebase for rapid prototyping
(not
the fault of folks that work on it, it just does a LOT). Since we
are
already doing things like DHCP, DNS, power, puppet-integration, and
so
forth (resources needed for the machine before it exists) and moving towards Network objects, modelling storage setup also seems useful
to
me. Things we do for Cobbler /do/ make it into Satellite, as we expose those in the Satellite GUIs and so forth, and make them supportable.
So this "do one thing" thing...
Ultimately our goal is to automate what we can automate, and gather information from people wherever we can find it. In this sense, Cobbler is a snowball for any sort of automating annoying repeated tasks that you need to do to get systems up and running, and makes it especially nice when folks are starting from scratch and needing OSS tools to do this. We want to prevent building custom automation infrastructure by providing a community where we can all share in that development.
If Cobbler's definition expands over time, I see that as progress.
I don't think we want another competing management tool (and adding
a
subproject adds overhead) when you can use Cobbler without using all
of
it's features. For instance, DHCP/DNS management today are totally optional. I do think possibly incorporating some of those ideas
from
your TicketMaster app could be excellent though, and I definitely welcome all of that. We do want to absorb all of the good (Free)
ideas
wherever they lie and accumulate all that knowledge together.
--Michael
cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
+1 from here for Scott's idea. I happen to be knee-deep in cobblering 64 HP blades with Emulex FC mezzanine cards connecting multiple volumes triple-multipath to an IBM XIV :-)
------------------------------------------------------------------------
cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
You may be a perfect one to ask about this then.
Assuming we added options to cobbler system objects to make this easier (and possibly profiles), what would you envision this looking like?
(Perhaps we could add cobbler "noun" objects to model the devices themselves like we're going to do for networks, I don't know if that would be required -- it could end up being somewhat simpler like how we handle power)
cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
Hmm, I'm not the "storage guy", but from what I gather, provisioning the volumes requires the two main steps of 1) allocating the space on the SAN, and 2) setting up the SAN switch ports (similar to setting a VLAN). The main pieces of info needed seem to be the card's WWN (similar to a MAC) and the volume size. I understand that different brands need varying other info, such as RAID groups, etc. On the surface, the actual provisioning could be done similar to cman's "fence_xxx" stuff, but would need some way of keeping track of the volume after it's been created. One hurdle I've come across is that it seems that the only practical way to acquire the WWN's is from the running kernel, so it would seem that the provisioning would have to be done in the %pre section once the WWN's are known. Thus, to keep track of the volume in the cobbler system object, the volume ID (and perhaps also the WWN) would need to get from the %pre section into a cobbler system variable somehow. I'm obviously far from an expert on this, and have a modest programming background (though I did kludge in a "PXE this machine" for HP blades-button into the power control menu - anyone interested?), so anyone please feel free to add to or correct anything I've said. I'll do my best to try or figure out any ideas towards this.
Owen Mann, Interactive Data Real Time Services
On 05/29/2009 09:32 AM, Owen.Mann@interactivedata.com wrote:
Hmm, I'm not the "storage guy", but from what I gather, provisioning the volumes requires the two main steps of 1) allocating the space on the SAN, and 2) setting up the SAN switch ports (similar to setting a VLAN). The main pieces of info needed seem to be the card's WWN (similar to a MAC) and the volume size. I understand that different brands need varying other info, such as RAID groups, etc. On the surface, the actual provisioning could be done similar to cman's "fence_xxx" stuff, but would need some way of keeping track of the volume after it's been created. One hurdle I've come across is that it seems that the only practical way to acquire the WWN's is from the running kernel, so it would seem that the provisioning would have to be done in the %pre section once the WWN's are known. Thus, to keep track of the volume in the cobbler system object, the volume ID (and perhaps also the WWN) would need to get from the %pre section into a cobbler system variable somehow. I'm obviously far from an expert on this, and have a modest programming background (though I did kludge in a "PXE this machine" for HP blades-button into the power control menu - anyone interested?), so anyone please feel free to add to or correct anything I've said. I'll do my best to try or figure out any ideas towards this.
I think the storage provisioning can be broken down into two portions. There is NAS (for me this means NFS) and SAN. As far as NAS goes, we create the volume and give hosts access to the volume in question. We have the ip address of the host, so it should be relatively easy.
As for SAN, there are two steps for us (using NetApps) as far as the filer goes. We need to create the initiator group with the hostname and then create the SAN lun on the proper volume (and create the volume if it doesn't exist, though we may not want to do this part). We need the WWN for the igroup creation, but once we have the igroup created, we use it to give the hosts access to the luns. For getting the WWNs, we have a mapping of MAC address to physical hosts, which then have the WWNs.
There is a wrinkle in it for virtual guests. We would need to find the virtual server hosting the guest and map the volume to that igroup instead. We would then need to expose the lun to the guest, but I would settle for the lun showing up on the virtual server.
Of course, all of the above assumes that the SAN fabric is properly configured and both the filer and the host are logged into the fabric. That is probably outside of cobbler and not something we want to get into.
As for the PXE this machine for HP blades, I would be interested in that. We have IBM blades so I don't know if we could use it, but I think it would be better to put that in the new deploy code instead of the power code. (cobbler deploy --name foo --virt-host bladecenter)
cobbler-devel@lists.fedorahosted.org