-
Leigh B Stoller authored
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
2364ad56