Actually it's computerloadlog

The computerloadlog table has three purposes.
It also has two dependent tables computerloadflow and computerloadstate

1) Provides information to the user about what state user request is in, where it's at in loading, performing post install tasks, adding user acct, etc. This information is seen on the current reservations page by the user clicking on the pending link. This link opens a ajax based window and will provided the state the load is in. At some point during your load routine - you'll want to add these type of calls in the appropriate places.

insertloadlog($reservation_id, $computer_id, "startload", "$computer_node_name $image_name");

But this isn't required to get a provision module functional. It's a nice feature, so the user can be aware of what's going on. We'll put together information on how to best use the insertloadlog.

2) If a new|reload request is started and the computer state is reload or reloading. The forked request process will use that table to determine what to do. Either take over, fail, or let the current owning process complete.

3) It is also used in vcld to prevent duplicate or competing processes.

It gets cleaned out on a per-reservation basis. When a reservations goes into the inuse state and when a reservation is removed from the db.

In your case, since your just testing your module, just manually empty the computerloadlog table as needed.


--On February 6, 2009 11:20:47 AM -0500 Brian Bouterse <> wrote:

What is the purpose of the loadlog table?  Currently the ESX provisioning
module doesn't update any information in the loadlog table, and the
provisioning works fine.  We're working on the capture() portions now,
and when we go through the web interface to have it "capture" our
reservation, vcld warns saying:

| 25052|72:72|image| ---- WARNING ----
| 25052|72:72|image| 2009-02-06
| 11:19:56|25052|72:72|image|vcld:main(272)|reservation 72 is already
| being processed 25052|72:72|image| ( 0), notify (line: 683)
| 25052|72:72|image| (-1) vcld, main (line: 272)

Is this normal for the "image update" process?


Brian Bouterse
Secure Open Systems Initiative

Reply via email to