Skip to content
Snippets Groups Projects
  1. Aug 19, 2010
  2. Aug 18, 2010
  3. Aug 17, 2010
  4. Aug 13, 2010
  5. Aug 10, 2010
  6. Aug 05, 2010
  7. Jul 30, 2010
  8. Jul 29, 2010
    • Iustin Pop's avatar
      Change handling of non-Ganeti errors in jqueue · 599ee321
      Iustin Pop authored
      
      Currently, if a job execution raises a Ganeti-specific error (i.e.
      subclass of GenericError), then we encode it as (error class, [error
      args]). This matches the RAPI documentation.
      
      However, if we get a non-Ganeti error, then we encode it as simply
      str(err), a single string. This means that the opresult field is not
      according to the RAPI docs, and thus it's hard to reliably parse the
      job results.
      
      This patch changes the encoding of a failed job (via failure) to always
      be an OpExecError, so that we always encode it properly. For the command
      line interface, the behaviour is the same, as any non-Ganeti errors get
      re-encoded as OpExecError anyway. For the RAPI clients, it only means
      that we always present the same type for results. The actual error value
      is the same, since the err.args is either way str(original_error);
      compare the original (doesn't contain the ValueError):
      
        "opresult": [
          "invalid literal for int(): aa"
        ],
      
      with:
      
        "opresult": [
          [
            "OpExecError",
            [
              "invalid literal for int(): aa"
            ]
          ]
        ],
      
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
      599ee321
Loading