Hi James,

That power stuff is unfortunate timing for me.  I actually just had to build a set of new power script to handle the HP bladesystem C-7000's for a group who didn't have ILO and weren't able to use any of the existing fence modules available.

Any suggestions on how I might be able to preserve their functionality of being able to define custom power templates? 

Also, any thoughts from the community on being able to poll systems for power status via the power commands?  (ie ipmitool power status ) and then present it as a green / red light?

Thanks,

James

On Sun, May 6, 2012 at 9:42 PM, James Cammarata <jimi@sngx.net> wrote:
I've just merged two major branches of work into master. Neither of
these will be in 2.2.3, but will be in 2.4.x.

First is the branch containing changes to the power commands, which
going forward will use STDIN to pass arguments to the fence commands.
In addition to this, going forward only the fence_* commands will be
available for use through cobbler. The biggest impact of this will be
the fact that ipmitool can no longer be used directly, so people will
need to migrate to the fence_ipmilan tool (which uses ipmitool under
the hood anyway). I believe that was the only non-fence agent utility
that was available for use, but if there are others they will require
the same forced migration.

The biggest benefit of this new method is no more templates will be
required for simple use. Templates can be used optionally by creating
an /etc/cobbler/power/fence_<cmd> template, which will let you set
more options than the defaults required.

Second is the capability to change settings dynamically without a
restart of cobblerd has been merged in as well.

# cobbler setting --help
usage
=====
cobbler setting edit
cobbler setting report

In order to use this capability, you must add the option
"allow_dynamic_settings: 1" to /etc/cobbler/settings and then restart
cobblerd. From that point on, you can use the edit command or the web
GUI to change settings and they will take effect immediately without a
restart.

The largest caveat for using dynamic settings is the possibility of
corrupting your settings file. Right now, we're using augeas to
regenerate the YAML config, but due to the fact that the settings file
has grown organically over the years, it has very inconsistent white
space indents for lists and hashes. Augeas uses a fixed width and
won't touch existing lines, so it can break things when the white
space isn't consistent. To fix this, "cobbler check" will suggest this
command to cleanup the settings file:

"sed -i 's/^[[:space:]]\+/ /' /etc/cobbler/settings"

If you use dynamic settings, you should run this command (after making
a backup of course) to ensure you won't run into issues.

This is a stop-gap solution, and I'm considering making 2.4 the
version that will finally move settings to a JSON file. A recent
contribution enabled "pretty printing" of JSON, so it makes the files
much more readable than they are currently. Combined with the ability
to change settings dynamically (and to get info about them on the
fly), there really isn't a need for the YAML config anymore, which
will greatly simplify things. I had already hacked in the capability
to store the settings along with everything else in MongoDB, so having
all of cobbler's data in the same format will allow more things like
that.

Anyway, enjoy, and feedback is always appreciated!
_______________________________________________
cobbler mailing list
cobbler@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler