I still think that having to specify the methods for every command in the
cluster.txt is too verbose and unnecessary in the general case.

My idea of specifying multiple methods was not trying multiple methods on
the same client, but trying the first method that exist for a given command.
So if you specify "wol,ssh" there is no way to power off a client via wol,
so the next method (ssh) will be used instead.

I don't think that this will lead to errors, since in general specifying
multiple methods would only be used to specify mutual exclusive options.

Also with power commands I think the worst case that can happen is that the
client does not respond to the given command. So having reasonable defaults
would be a good thing especially for people new to SI.

However I can also see the value in specifying the method used for every
command separately.

So, what about keeping the defaultMethod, but using your verbose format for
the "power-control"-node. This way you only need to specify commands in
cluster.txt that differ from the default. If you are still afraid of
unexpected behavior, we could even ship the default powerconfig-file without
any defaults specified.

Anyway these are minor details and I could live fine with all these options,
even if it means a little more typing ;-)

What do you think?

Thomas Krause

-----Ursprüngliche Nachricht-----
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von Andrea
Righi
Gesendet: Sonntag, 4. Mai 2008 12:49
An: [email protected]
Betreff: Re: [sisuite-users] si_power tool

Thomas Krause wrote:
> Ok, first of all the syntax of the si_power tool should be the same
> regardless of the method used IME.
> 
> There should also be a good default that works in most cases (probably the
> ssh way).
> 
> Maybe the best way would be to create a separate si_power configuration
file
> that defines the possible power primitives and the methods used to achieve
> them. In the cluster.txt we would then only specify the name of the method
> to use:
> 
> <group>
>       <name>cluster1</name>
>       <image>RHEL5</image>
>       <override>RHEL5</override>
>       <node>node001-node100</node>
>       <power-control>wol,ssh</power-control>
> </group>
> 
> The si_power config file could look like:
> <command name="on" defaultMethod="wol">
>       <method name="wol">wol %h</method>
>       <method name="ipmi">ipmitool -I lan -A NONE -U USERID -H %H power
> on</method>
> </command>
> 
> <command name="off" defaultMethod="ssh">
>       <method name="ssh">ssh -l root %H init 0</method>
>       <method name="ipmi">ipmitool -I lan -A NONE -U USERID -H %H power
> on</method>
> </command>
> 
> <command name="custom_command">
> ...
> </command>
> 
> si_power would then first find the command node in the config file for the
> action specified on the command line (on, off, etc.). If it has found the
> command, it would try to find the method name given in the cluster.txt. If
> multiple method names are separated by comma (ssh, wol), it will try them
> one by one until it finds a method for this command. If nothing matches or
> if the power-control node in cluster.txt is empty it will use the default
> method.
> 
> Although this is somewhat more difficult to implement, it should be very
> easy to extent. Also since this would not be limited to power management,
we
> could even name this something more general like si_action.
> 
> What do you think?

Agree. Except that IMHO the commands should be more controlled, I mean,
I really like the si_power configuration file to define the basic
primitives, but I wouldn't try multiple methods on the same clients,
this would probably lead to errors or unexpected behaviours. Instead I
would explicitly set all the available/working commands inside the
<power-control> attribute in cluster.xml, removing the "defaultMethod"
attribute.

So, I would rewrite your example in this way:

=== cluster.xml ===

<group>
        <name>cluster1</name>
        <image>RHEL5</image>
        <override>RHEL5</override>
        <node>node001-node100</node>
        <power-control>
                <!--
                  The following primitives are defined in
                  si_power.conf (see below)
                -->
                <on>wol</on>
                <off>ipmi-ibm-e326m</off>
                <reboot>ipmi-ibm-e326m</reboot>
                <shutdown>ssh</shutdown>
        </power-control>
</group>

=== si_power.conf (using a syntax similar to cluster.xml) ===

<!-- %H will be automatically expanded in the hostname of the clients -->
<!-- Define other wildcards here -->
<command>
        <!-- Name of the basic primitive (used in cluster.xml) -->
        <name>on</name>
        <!-- Primitive implementation alternatives -->
        <method>
                <name>wol</name>
                <command-line>wol %H</command-line>
        </method>
        <method>
                <name>ipmi-ibm-e326m</name>
                <command-line>ipmitool -I lan -A NONE -U USERID -H %H power
on</command-line>
        </method>
</command>
<command>
        <!-- Name of the basic primitive (used in cluster.xml) -->
        <name>off</name>
        <!-- Primitive implementation alternatives -->
        <method>
                <name>ssh</name>
                <command-line>ssh %H poweroff</command-line>
        </method>
        <method>
                <name>ipmi-ibm-e326m</name>
                <command-line>ipmitool -I lan -A NONE -U USERID -H %H power
off</command-line>
        </method>
</command>
<command>
        <!-- Name of the basic primitive (used in cluster.xml) -->
        <name>reboot</name>
        <!-- Primitive implementation alternatives -->
        <method>
                <name>ssh</name>
                <command-line>ssh %H init 6</command-line>
        </method>
        <method>
                <name>ipmi-ibm-e326m</name>
                <command-line>ipmitool -I lan -A NONE -U USERID -H %H power
cycle</command-line>
        </method>
</command>
<command>
        <!-- Name of the basic primitive (used in cluster.xml) -->
        <name>shutdown</name>
        <!-- Primitive implementation alternatives -->
        <method>
                <name>ssh</name>
                <command-line>ssh %H init 0</command-line>
        </method>
</command>
...

In this way we can provide a basic skel of officially supported si_power
primitives and each user can easily implement his own preferred methods
(and maybe share them with the community).

-Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javao
ne
_______________________________________________
sisuite-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sisuite-users


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
sisuite-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sisuite-users

Reply via email to