1. 20 Oct, 2010 4 commits
  2. 19 Oct, 2010 3 commits
  3. 15 Oct, 2010 6 commits
  4. 14 Oct, 2010 6 commits
    • Iustin Pop's avatar
      Merge branch 'stable-2.2' · 744061f3
      Iustin Pop authored
      
      
      * stable-2.2:
        Release 2.2.1~rc1
        Require aclocal 1.11.1 or above for devel/release
        Revert "Require aclocal 1.11.1 or above for autogen.sh"
        Add mising --units in gnt-instance list man page
        Set list of trusted SSL CAs for client to verify
        Require aclocal 1.11.1 or above for autogen.sh
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
      744061f3
    • Iustin Pop's avatar
      Brown-bag fix for leftover comment · 76917d97
      Iustin Pop authored
      
      
      I did forgot this in the original patch. Sorry!!!!
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
      76917d97
    • Iustin Pop's avatar
      Rework QA interaction with the watcher · 8201b996
      Iustin Pop authored
      
      
      The interaction with cron-launched watcher is a well-known failure mode of QA:
      
      ---- 2010-10-14 06:54:55.464839 time=0:00:56.764827 Test tools/move-instance
      
      For the following tests it's recommended to turn off the ganeti-watcher cronjob.
      
      ---- 2010-10-14 06:54:55.465255 start Test automatic restart of instance by ganeti-watcher
      …
      Error: Domain 'instance1' does not exist.
      Command: ssh -oEscapeChar=none -oBatchMode=yes -l root -t -oStrictHostKeyChecking=yes
        -oClearAllForwardings=yes -oForwardAgent=yes node2 'ganeti-watcher -d'
      2010-10-13 23:55:04,479:  pid=1659 ganeti-watcher:626
       ERROR Can't acquire lock on state file /var/lib/ganeti/watcher.data: File already locked
      ---- 2010-10-14 06:55:04.513948 time=0:00:09.048693 Test automatic restart of instance by ganeti-watcher
      
      In order to fix this, we disable the watcher during these tests, and
      re-enable it afterwards. To protect against watcher being disabled, we
      enable it unconditionally at the start of the QA (we do want it enabled,
      in order to see the interaction between the watcher and many
      creation/disk replace jobs, etc.).
      
      Note: even after this patch, if a cron-watcher was started and is still
      running during the test, we'll have locking issues. I think for now this
      is OK, we'll have to see how often that happens.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
      8201b996
    • Iustin Pop's avatar
      Add a new watcher option --ignore-pause · 46c8a6ab
      Iustin Pop authored
      
      
      During cluster maintenance, when the watcher is disabled, it's useful to
      run it just once. This is incovenient to do currently, as the watcher
      needs to be unpaused, then run, then paused again.
      
      This patch adds an option “--ignore-pause” that can be used to ignore
      the cluster-level setting. Also the man page is updated as it was
      missing the options available.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
      46c8a6ab
    • Iustin Pop's avatar
      Release 2.2.1~rc1 · 24440be4
      Iustin Pop authored
      
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
      24440be4
    • Iustin Pop's avatar
      Merge branch 'stable-2.2' into devel-2.2 · 7dcadb74
      Iustin Pop authored
      
      
      * stable-2.2:
        Require aclocal 1.11.1 or above for devel/release
        Revert "Require aclocal 1.11.1 or above for autogen.sh"
        Set list of trusted SSL CAs for client to verify
        Require aclocal 1.11.1 or above for autogen.sh
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
      7dcadb74
  5. 13 Oct, 2010 10 commits
  6. 12 Oct, 2010 9 commits
  7. 11 Oct, 2010 2 commits
    • Iustin Pop's avatar
      Merge branch 'devel-2.2' · 69750d44
      Iustin Pop authored
      
      
      * devel-2.2:
        RPC: disable curl's Expect header
      
      Conflicts:
      	lib/rpc.py (trivial, copyright header)
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
      69750d44
    • Iustin Pop's avatar
      RPC: disable curl's Expect header · 8e29563f
      Iustin Pop authored
      
      
      This patch solves the very slow (~8-9 seconds) gnt-instance modify
      behaviour. Well, it solves in general the slow RPC behaviour, but it was
      most visible in that LU.
      
      It seems that curl's behaviour with regard to file uploads (via PUT) and
      the 'Expect' header are interacting badly with our http server.
      
      First, our http server doesn't properly handle this header. According to
      RFC 2616:
      
        Requirements for HTTP/1.1 origin servers: Upon receiving a request
        which includes an Expect request-header field with the "100-continue"
        expectation, an origin server MUST either respond with 100 (Continue)
        status and continue to read from the input stream, or respond with a
        final status code.
      
      Our server doesn't do this, and hence it triggers this behaviour in curl
      (from the curl FAQ):
      
        4.16 My HTTP POST or PUT requests are slow!
      
        libcurl makes all POST and PUT requests (except for POST requests with a
        very tiny request body) use the "Expect: 100-continue" header. This header
        allows the server to deny the operation early so that libcurl can bail out
        already before having to send any data. This is useful in authentication
        cases and others.
      
        However, many servers don't implement the Expect: stuff properly and if the
        server doesn't respond (positively) within 1 second libcurl will continue
        and send off the data anyway.
      
        You can disable libcurl's use of the Expect: header the same way you disable
        any header, using -H / CURLOPT_HTTPHEADER, or by forcing it to use HTTP 1.0.
      
      This behaviour was detected by watching the captured traffic (in non-SSL
      mode), where between the initial HTTP headers (ending with the Expect
      one), there was a ~1-2 second pause until curl was sending the body.
      Properly RTFM-ing would have saved ~1 day of digging around, but hey…
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
      8e29563f