1. 22 Jul, 2010 1 commit
  2. 21 Jul, 2010 1 commit
  3. 19 Jul, 2010 9 commits
  4. 18 Jul, 2010 3 commits
  5. 17 Jul, 2010 2 commits
  6. 16 Jul, 2010 9 commits
  7. 15 Jul, 2010 13 commits
  8. 14 Jul, 2010 2 commits
    • Leigh B Stoller's avatar
      Minor bug fix. · 2cd9ae73
      Leigh B Stoller authored
      2cd9ae73
    • Leigh B Stoller's avatar
      Version 1 of the event clients. See attached message. · 2364ad56
      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