Ok, so I was working on some snippets the other day for configuring our Dell DRAC interfaces (similar to HP iLO, etc.) using ksmeta variables, when it occurred to me that it would be a better idea to use the interfaces capability of the system object to store this information. For example:
cobbler system edit --name=foo --interface=DRAC --ip=1.2.3.4...
In this way, we could use the built-in error checking, and not have to worry about ks-meta accidently being blown away by an admin who doesn't know about --in-place. Obviously, this presents an issue with the existing snippets and koan's functionality, which would have to be taught to ignore interfaces named after certain key words, or to add a configuration command option to mark certain interfaces as "virtual", along the lines of bonded interfaces.
We could then write an OOB network snippet to configure the hardware for HP, IBM, Dell, or whatever other manufacturers that may have similar setups.
Thoughts?
+1 This would be huge for me. I know some (most) would prefer to KISS, but IMHO adding a small amount of code would save a whole lot of kludgey workarounds.
Owen Mann Interactive Data Real Time Services Email: owen.mann@interactivedata.com
James Cammarata jimi@sngx.net Sent by: cobbler-devel-bounces@lists.fedorahosted.org 03/17/2009 02:19 PM Please respond to jimi@sngx.net; Please respond to cobbler development list cobbler-devel@lists.fedorahosted.org
To cobbler development list cobbler-devel@lists.fedorahosted.org cc
Subject Creating non-standard interfaces
Ok, so I was working on some snippets the other day for configuring our Dell DRAC interfaces (similar to HP iLO, etc.) using ksmeta variables, when it occurred to me that it would be a better idea to use the interfaces capability of the system object to store this information. For example:
cobbler system edit --name=foo --interface=DRAC --ip=1.2.3.4...
In this way, we could use the built-in error checking, and not have to worry about ks-meta accidently being blown away by an admin who doesn't know about --in-place. Obviously, this presents an issue with the existing snippets and koan's functionality, which would have to be taught to ignore interfaces named after certain key words, or to add a configuration command option to mark certain interfaces as "virtual", along the lines of bonded interfaces.
We could then write an OOB network snippet to configure the hardware for HP, IBM, Dell, or whatever other manufacturers that may have similar setups.
Thoughts?
On 03/17/2009 07:19 PM, James Cammarata wrote:
Ok, so I was working on some snippets the other day for configuring our Dell DRAC interfaces (similar to HP iLO, etc.) using ksmeta variables, when it occurred to me that it would be a better idea to use the interfaces capability of the system object to store this information. For example:
cobbler system edit --name=foo --interface=DRAC --ip=1.2.3.4...
In this way, we could use the built-in error checking, and not have to worry about ks-meta accidently being blown away by an admin who doesn't know about --in-place. Obviously, this presents an issue with the existing snippets and koan's functionality, which would have to be taught to ignore interfaces named after certain key words, or to add a configuration command option to mark certain interfaces as "virtual", along the lines of bonded interfaces.
We could then write an OOB network snippet to configure the hardware for HP, IBM, Dell, or whatever other manufacturers that may have similar setups.
Thoughts?
Can't we just add two extra fields (subnet/gateway) to the power stuff for this? Or maybe I'm missing the whole point. :)
On Tue, 17 Mar 2009 20:14:43 +0100, Jasper Capel capel@stone-it.com wrote:
On 03/17/2009 07:19 PM, James Cammarata wrote:
Ok, so I was working on some snippets the other day for configuring our Dell DRAC interfaces (similar to HP iLO, etc.) using ksmeta variables, when it occurred to me that it would be a better idea to use the interfaces capability of the system object to store this information. For example:
cobbler system edit --name=foo --interface=DRAC --ip=1.2.3.4...
In this way, we could use the built-in error checking, and not have to worry about ks-meta accidently being blown away by an admin who doesn't know about --in-place. Obviously, this presents an issue with the existing snippets and koan's functionality, which would have to be taught to ignore interfaces named after certain key words, or to add a configuration command option to mark certain interfaces as "virtual", along the lines of
bonded
interfaces.
We could then write an OOB network snippet to configure the hardware for HP, IBM, Dell, or whatever other manufacturers that may have similar setups.
Thoughts?
Can't we just add two extra fields (subnet/gateway) to the power stuff for this? Or maybe I'm missing the whole point. :)
Perhaps, I'm not that familiar with the power stuff, though that would mean people would also need to install CMAN in order to do OOB management interfaces, wouldn't it? I know fencing uses these same objects, but fencing also supports a lot of other stuff that would not qualify for this, nor would many people use it.
There is definitely some cross over here though, question is simply which would we prefer handle this?
James Cammarata wrote:
On Tue, 17 Mar 2009 20:14:43 +0100, Jasper Capel capel@stone-it.com wrote:
On 03/17/2009 07:19 PM, James Cammarata wrote:
Ok, so I was working on some snippets the other day for configuring our Dell DRAC interfaces (similar to HP iLO, etc.) using ksmeta variables, when it occurred to me that it would be a better idea to use the interfaces capability of the system object to store this information. For example:
cobbler system edit --name=foo --interface=DRAC --ip=1.2.3.4...
In this way, we could use the built-in error checking, and not have to worry about ks-meta accidently being blown away by an admin who doesn't know about --in-place. Obviously, this presents an issue with the existing snippets and koan's functionality, which would have to be taught to ignore interfaces named after certain key words, or to add a configuration command option to mark certain interfaces as "virtual", along the lines of
bonded
interfaces.
We could then write an OOB network snippet to configure the hardware for HP, IBM, Dell, or whatever other manufacturers that may have similar setups.
Thoughts?
Can't we just add two extra fields (subnet/gateway) to the power stuff for this? Or maybe I'm missing the whole point. :)
Perhaps, I'm not that familiar with the power stuff, though that would mean people would also need to install CMAN in order to do OOB management interfaces, wouldn't it?
It would not. I'm suggesting we rename the field to "management_interface", or even "management_interfaces". Field renaming in cobbler on upgrades is possible, and we could keep the API supporting both if needed for consistency.
I know fencing uses these same objects, but fencing also supports a lot of other stuff that would not qualify for this, nor would many people use it.
There is definitely some cross over here though, question is simply which would we prefer handle this?
James Cammarata wrote:
Ok, so I was working on some snippets the other day for configuring our Dell DRAC interfaces (similar to HP iLO, etc.) using ksmeta variables, when it occurred to me that it would be a better idea to use the interfaces capability of the system object to store this information. For example:
cobbler system edit --name=foo --interface=DRAC --ip=1.2.3.4...
In this way, we could use the built-in error checking, and not have to worry about ks-meta accidently being blown away by an admin who doesn't know about --in-place. Obviously, this presents an issue with the existing snippets and koan's functionality, which would have to be taught to ignore interfaces named after certain key words, or to add a configuration command option to mark certain interfaces as "virtual", along the lines of bonded interfaces.
We could then write an OOB network snippet to configure the hardware for HP, IBM, Dell, or whatever other manufacturers that may have similar setups.
Thoughts?
DRAC is not using the ksmeta info, there are seperate variables assigned to power management.
Given, I know this isn't just about power, in which case, it might make sense to rename the variable to something more generic, like "management_address" instead of "power_address", though I suppose it's possible something might have seperate power and seperate remote consoles, as there are remote console cards that do that.
Anyone else have comments? I'm generally amenable to change, but don't particularly like the idea of calling it a network interface -- the network interface snippets are too complicated as is, I don't want to make them more so.
On 03/17/2009 08:42 PM, Michael DeHaan wrote:
Anyone else have comments? I'm generally amenable to change, but don't particularly like the idea of calling it a network interface -- the network interface snippets are too complicated as is, I don't want to make them more so.
+1 on this one, I really don't feel comfortable about having to add exceptions there, it took a lot of effort to get 'em to where they are now. :)
-Jasper
Anyone else have comments? I'm generally amenable to change, but don't particularly like the idea of calling it a network interface -- the network interface snippets are too complicated as is, I don't want to make them more so.
would this be able to offer the IP via DHCP as we have _some_ DRACS, LOM, iLo etc that use DHCP and some that dont.
having all these come from cobblers DHCP would be vvv good
On Tue, 17 Mar 2009 20:46:10 +0100, Jasper Capel capel@stone-it.com wrote:
On 03/17/2009 08:42 PM, Michael DeHaan wrote:
Anyone else have comments? I'm generally amenable to change, but don't
particularly like the idea of calling it a network interface -- the network interface snippets are too complicated as is, I
don't want to make them more so.
+1 on this one, I really don't feel comfortable about having to add exceptions there, it took a lot of effort to get 'em to where they are now. :)
-Jasper _______________________________________________ cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
I agree, I didn't know the power stuff was this generic (I thought it was much more specific to fencing and generating the cluster configuration), so using this should be fine with possibly some enhancements as Tom notes for things like DHCP support for the interface.
On Tue, 17 Mar 2009 15:05:08 -0500, James Cammarata jimi@sngx.net wrote:
On Tue, 17 Mar 2009 20:46:10 +0100, Jasper Capel capel@stone-it.com wrote:
On 03/17/2009 08:42 PM, Michael DeHaan wrote:
Anyone else have comments? I'm generally amenable to change, but
don't
particularly like the idea of calling it a network interface -- the network interface snippets are too complicated as is,
I
don't want to make them more so.
+1 on this one, I really don't feel comfortable about having to add exceptions there, it took a lot of effort to get 'em to where they are now. :)
-Jasper _______________________________________________ cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
I agree, I didn't know the power stuff was this generic (I thought it was much more specific to fencing and generating the cluster configuration),
so
using this should be fine with possibly some enhancements as Tom notes
for
things like DHCP support for the interface.
One other thing I've noticed in checking out the power stuff, besides lacking support for DHCP, it does not offer any option to set the gateway or DNS servers for the power devices. While not all power devices would support these, many do, so we'd probably want to add those features.
James Cammarata wrote:
On Tue, 17 Mar 2009 15:05:08 -0500, James Cammarata jimi@sngx.net wrote:
On Tue, 17 Mar 2009 20:46:10 +0100, Jasper Capel capel@stone-it.com wrote:
On 03/17/2009 08:42 PM, Michael DeHaan wrote:
Anyone else have comments? I'm generally amenable to change, but
don't
particularly like the idea of calling it a network interface -- the network interface snippets are too complicated as is,
I
don't want to make them more so.
+1 on this one, I really don't feel comfortable about having to add exceptions there, it took a lot of effort to get 'em to where they are now. :)
-Jasper _______________________________________________ cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
I agree, I didn't know the power stuff was this generic (I thought it was much more specific to fencing and generating the cluster configuration),
so
using this should be fine with possibly some enhancements as Tom notes
for
things like DHCP support for the interface.
One other thing I've noticed in checking out the power stuff, besides lacking support for DHCP, it does not offer any option to set the gateway or DNS servers for the power devices. While not all power devices would support these, many do, so we'd probably want to add those features.
It seems clumsy, yes, but --management-gateway and --management-dns seems like something we'd want to add in this case.
With regard to repurposing the address field, migrating variables in cobbler is /kind of/ tricky, but there are plenty of forwards compat places in the code where we do it.
With the templates, folks just need to be aware of .rpmnew files on upgrades for when variables change.
--Michael
cobbler-devel@lists.fedorahosted.org
-
James Cammarata -
Jasper Capel -
Mann, Owen -
Michael DeHaan -
Tom Brown