Re: [Freeipmi-devel] IPMI power control utility description

[Anand Babu]

Hi Al,
,---- Albert Chu <address@hidden> writes:
| AB, I couldn't find too much IPMI code on the FreeIPMI website, for
| the most part, I wrote an IPMI library from scratch (of course caring
| only for those packets and functionality I required for power
| control).  The API allows the user to:
| 
| - set data in individual packets
| - get packet data values from packet responses
| - dump packet data to stderr
| - check packets for correct completion code, network function response,  
|   command type, checksums, outbound sequence numbers, and requester  
|   sequence numbers.
`----
All the blame goes to me. I still have all the code in my laptop and
hesitant to check-in without freezing the framework. I promise I will
do it in a day or two. Compare your library and the libfreeipmi
library and submit a patch for the enhancements.

,----
| Based on the library, the tool creates appropriate packets, checks
| responses for correctness, deals with errors, polls/sends packets, and
| gives a snazzy command line interface.  Due to lack of creativity, I
| called the tool ipmipower too.
`----
Question:
Should ipmipower be maintained a separate utility apart from fish?

Fish shell provides an interface to achieve the same what ipmipower
can do, but it may be too heavy. Most of the times while calling from
other applications or scripts, ipmipower or direct libfreeipmi library
will be faster and simple.

I think we can standardize on your implementation. Just wait for the
libfreeipmi release. I want your ipmipower to be built on top of
libfreeipmi as a FreeIPMI sub-project.

,----
| The tool has two "modes", interactive and non-interactive.  If you
| specify some power command on the command line (--on, --off, --stat,
| --reset, --cycle) ipmipower runs the command on specified remote nodes
| then exits.  
| 
| If no power commands are specified on the command line, an "interactive
| mode" is entered, where you get a command prompt and can type in various
| power commands.  This was specifically implemented for ipmipower to work
| with powerman.
`----

Fish provides an interactive command interface and scheme based
scripting interface. 

Question:
How important it is to have additional command-line interface apart
from the above two interfaces?

I think it will be nice to have command-line interface too, to most
commonly used features. 

It was never considered that critical so far, because much of higher
level stuff and user interface is written in scheme and currently
there is no way to register dynamic command line interface from
scheme. So doing it (interfacing the ipmi commands to command line
argument processing) will require implementation in C inside fish core
there by heavily limiting the extensibility.

I think this problem is solvable by easily capturing dynamically
registered commands (from scheme) and throwing them as command line
arguments as well.


More info on how I implement UI for internal C ipmi functions:
--------------------------------------------------------------
For every new functionality that goes into Fish, I add a scheme
procedure or hook or variable binding. Then I handle much of the UI
from scheme as an extension module. 

Once scheme binding is available, it is very easy to make it available
as a command.

Like this:

(define (discover args)
  "discovers list of IPMI compatible systems and caches them"
  (set! args (list->strlist args))
  (if (= (length args) 2)
      (fi-discover! (car args) (cadr args))
      (display "discover: wrong number of arguments, type \"help
      discover\" for more info\n")))
                                                                                
            
(fi-register-command!
 '("discover"
   "discover IPADDR-START IPADDR-END \n\t- discover IPMI compatible systems"))

The above code will a shell command like this:

fish# discover 192.168.1.10 192.168.1.200

192.168.1.10 -> IPMI v1.5
192.168.1.11 -> IPMI v1.5
192.168.1.12 -> No response
192.168.1.13 -> IPMI v1.5
...
...
fish# help discover
discover IPADDR-START IPADDR-END
        - discover IPMI compatible systems

But the actual code behind this implementation is written in C inside
libfreeipmi and fish core. 

You can also interface to the ipmi procedures by writing your own
scripts and execute them as independent executables with
#!/usr/bin/fish, or fish -s /path/to/myscript.scm 

It is also possible to evaluate scheme code from command line like
this
# fish -e "(fi-power-on '192.168.1.27)"

,----
| As for the actual IPMI protocol, I setup a session, run a power command,
| then close the session.  Due to various design/implementation/time
| reasons, I elected not to program our tool to keep IPMI sessions open.
`----
Your choice is correct. libfreeipmi doesn't manage sockets. It lets
the user to establish the session and just provide sockfd to the
library. It is upto the user to choose between session per job and
all in one session. By this way it ensures thread-safety also.

Handling all in one session needs session tracking, buffer flushing
..,  and is too cumbersome. Otherwise you will get unexpected results
which are hard to debug. On the other hand, all in one session is
faster. 

Debate between correctness and speed?
Fish chose to use all in one session model, simply because of
speed. One of the design goal of Fish is speed and
scalability. Correctness can be achieved over time. But ipmipower
should lean towards correctness and stability at this point just to
ensure manageability of Thunder project from the very beginning.

It would be nice to evaluate how long it takes to 
   for (i=0; i<1024; i++) {
      socket(SOCK_DGRAM)
      bind 
     close 
   }

,----
| Packet responses are checked for proper checksums, completion code,
| network function, command, outbound sequence number, and requester
| sequence number.  Right now, I use the requester sequence number to
| store both a "transaction id" and a "sequence number", although I'm
| debating if this should be changed.  Old packets or corrupted packets
| are ignored and assumed to be junk.  Error codes are handled
| appropriately when possible.
|  
| Packets will be resent if a proper response doesn't arrive within a
| certain timeout.  The overall power control attempt times out after a
| much larger time period.
`----
Much of my time is spent only in this area. Though I have working code
already, I want to abstract all these details in to the framework
itself (mostly into libfreeipmi). I'm foreseeing lot of trouble in
this area like you do. UDP is stateless, but that also invites
trouble. Remember the other end of connection is a dumb BMC firmware
and not enterprise class management agent software. 

I'm getting varying results while trying to tune between timeout and
retry count. I left that parameter as a configurable value.

libfreeipmi provides a nice errno type of error handling. Every call
should set appropriate errno value and you can get the string
description of the error using ipmi_strerror_r (...) call.

,----
| That's a general overview, but perhaps not so general b/c this
| e-mail is way long.
`----
I think we will be coding more than we talk once the framework is
established :D. 

Give me your savannah.gnu.org user id. I think you will be a good
contributor to this project.

Happy Hacking
-- 
 _.|_ 
(_||_)
Free as in Freedom <www.gnu.org>