From: Leigh Stoller <stoller@flux.utah.edu>
Date: July 1, 2010 11:35:08 AM MDT
Subject: Re: Event System Issues

Mike and I exchanged a couple of email messages. Mike has indicated
that we should drop all Elvin support. A nice goal, but not possible
cause of the basic mistake I made in "version 0" of the event code.

What we *can* do is stop *generating* the elvin hashes completely in
Version 1. We also drop the elvin_gateway, thus no longer supporting
ancient images that are still using the real elvin libraries. I am
okay with this. Comment if you have objections.

Version 0 elvin-compat (these are pubsub clients with ELVIN_COMPAT=1)
binaries will work cause of the magic ___elvin_ordered___ flag, which
actually tells the client that the hmac is a pubsub ordered hmac. (I
know, I am just great at naming things). I just add this little flag
to events in version 1.

Version 0 non-elvin-compat binaries will not work, but this is okay.
The only case this matters right now is Protogeni, where we need to be
able to talk to non-elvin-compat binaries at remote sites. I have
solved this with a version0 gateway as described in the previous
message. ops will run a secondary pubsubd on another port, and the
protogeni client startup code will have clients connect to that
pubsubd instead. This is mostly tested, and it can roll out to other
sites as needed, once we roll out cooked mode.

Version 1 clients are fully interoperable.

Lastly, we still need to be able to compare elvin HMACs coming from
existing version 0 elvin-compat binaries (from our many many system
and custom images). Thats cause all those images are still going to be
generating the HMACs in elvin order, and so the server programs on ops
(event scheduler, tevc, etc) need that elvin hashing code built into
it. See first paragraph.

Anyway, I have all this done and tested on my elabinelab. I had wanted
to make it in time for code freeze, but not enough time to get proper
debugging, so I will push once code freeze is over.

Lbs