1. 25 Aug, 2010 6 commits
  2. 24 Aug, 2010 7 commits
  3. 23 Aug, 2010 12 commits
  4. 20 Aug, 2010 11 commits
  5. 19 Aug, 2010 4 commits
    • Iustin Pop's avatar
      Explicitly add dry-run to some commands · db5a8a2d
      Iustin Pop authored
      Based on manual inspection (that the command only does a submit of some
      jobs/opcodes), we re-add the dry-run option on a subset of the existing
      commands.
      
      A few more commands could use dry-run, but the code doesn't deal nicely
      with no results, so fixing those is left for later patches.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
      db5a8a2d
    • Iustin Pop's avatar
      Stop adding the dry-run option by default · a0a6ff34
      Iustin Pop authored
      Currently cli.py unconditionally adds the dry-run option. This patch
      disables this, and exports dry-run as a normal option.
      
      The other alternative I tried to implement (adding a new fake option for
      disabling the auto-add per individual command) would require changes in
      more places, as the list of options is no longer a homogeneous list.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
      a0a6ff34
    • Iustin Pop's avatar
      Fix a few commands behaviour with dry-run · 48418fea
      Iustin Pop authored
      These commands use or display the result from the LU, so in case of
      dry-run, they will crash or display just 'None'. At least checking that
      the result is 'true' (in the boolean sense) will make them work better.
      
      As for gnt-os modify, it didn't pass the 'opts' parameter properly to
      SubmitOpCode, so the dry-run option was silently ignored.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
      48418fea
    • Michael Hanselmann's avatar
      jqueue: Remove lock status field · 9bdab621
      Michael Hanselmann authored
      With the job queue changes for Ganeti 2.2, watched and queried jobs are
      loaded directly from disk, rendering the in-memory “lock_status” field
      useless. Writing it to disk would be possible, but has a huge cost at
      runtime (when tested, processing 1'000 opcodes involved 4'000 additional
      writes to job files, even with replication turned off).
      
      Using an additional in-memory dictionary to just manage this field turned
      out to be a complicated task due to the necessary locking.
      
      The plan is to introduce a more generic lock debugging mechanism in the
      near future. Hence the decision is to remove this field now instead of
      spending a lot of time to make it working again.
      Signed-off-by: default avatarMichael Hanselmann <hansmi@google.com>
      Reviewed-by: default avatarIustin Pop <iustin@google.com>
      9bdab621