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 <[email protected]> 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 > [email protected] > https://fedorahosted.org/mailman/listinfo/cobbler >
_______________________________________________ cobbler mailing list [email protected] https://fedorahosted.org/mailman/listinfo/cobbler
