1. 16 Jan, 2013 2 commits
  2. 15 Jan, 2013 2 commits
    • Michael Hanselmann's avatar
      Link man pages in documentation · 5ce58234
      Michael Hanselmann authored
      This patch depends on “Option to include man pages in documentation”. In
      the documentation build including man pages, all “:manpage:`…`”
      references are converted to links. For man pages not provided by Ganeti,
      Sphinx' standard formatting is used.
      A small dance is necessary to hook into Sphinx' processing of man page
      roles and to generate automatically resolved links. The code converts
      “:manpage:`…`” for known man pages to the data structure equivalent of
      “:doc:`$name($section) <man-$name>`”. Additionally it checks the section
      numbers and formatting of references (in all builds).
      Signed-off-by: default avatarMichael Hanselmann <hansmi@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
    • Michael Hanselmann's avatar
      Option to include man pages in documentation · 41806ef4
      Michael Hanselmann authored
      Before this patch, HTML versions of man pages (man/*.rst) were already
      built. However, since they are separate from the normal documentation,
      their content is not indexed for Sphinx' search functionality.
      Additionally it would simply be nice to have everything in one place.
      To this end a new configure-time option is added to enable the inclusion
      of man pages into the documentation. A dedicated option is necessary to
      still be able to provide a static documentation build in the tarball
      (not including man pages) as man pages contain build-specific paths and
      values. The documentation with man pages is written to the directory
      A future patch will extend Sphinx to link occurences of “:manpage:`…`”
      to these man pages.
      Signed-off-by: default avatarMichael Hanselmann <hansmi@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
  3. 14 Jan, 2013 1 commit
  4. 10 Jan, 2013 2 commits
    • Michael Hanselmann's avatar
      Generate documentation from build directory · 7cf58cad
      Michael Hanselmann authored
      When man pages should be included they need to be copied from man/*.rst.
      This means documentation can no longer be built from the static reST
      files alone (which are referenced using “abs_top_srcdir”). Similar to
      Python files, automake doesn't copy or link the input files for
      documentation into the build tree.
      This patch adds all files required to build the documentation to
      “srclink_files”, renames the “docrst" variable to “docinput”, and then
      references the files in the build tree using “abs_top_builddir”.
      Signed-off-by: default avatarMichael Hanselmann <hansmi@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
    • Michael Hanselmann's avatar
      Add script to check man page references · 58997abb
      Michael Hanselmann authored
      This script checks for some of the most obvious mistakes when formatting
      man page references (which should have the form “**ganeti**\(7)”). While
      this works now, it is very hard to avoid ambiguities (e.g. references
      within verbatim blocks) when using regular expressions.
      Also fixes a typo in Makefile.am by replacing “harcoded” with
      Signed-off-by: default avatarMichael Hanselmann <hansmi@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
  5. 09 Jan, 2013 3 commits
  6. 08 Jan, 2013 6 commits
  7. 07 Jan, 2013 2 commits
  8. 04 Jan, 2013 1 commit
  9. 28 Dec, 2012 1 commit
  10. 27 Dec, 2012 7 commits
  11. 24 Dec, 2012 1 commit
  12. 22 Dec, 2012 5 commits
  13. 21 Dec, 2012 2 commits
  14. 20 Dec, 2012 2 commits
    • Michele Tartara's avatar
      Add Confd client to the Haskell code base · 04063ba7
      Michele Tartara authored
      The client queries all the master candidates in parallel, until the minimum
      number of replies, defined in the constant file, is received.
      A timeout prevents the waiting from being of indefinite length.
      The reply to be returned to the function that made the query is decided
      according to the Confd design document.
      Signed-off-by: default avatarMichele Tartara <mtartara@google.com>
      Reviewed-by: default avatarIustin Pop <iustin@google.com>
    • Constantinos Venetsanopoulos's avatar
      Implement the External Storage Interface · 376631d1
      Constantinos Venetsanopoulos authored
      With this commit we introduce the External Storage Interface
      to Ganeti, abbreviated: ExtStorage Interface.
      The ExtStorage Interface provides Ganeti with the ability to interact
      with externally connected shared storage pools, visible by all
      VM-capable nodes. This means that Ganeti is able to handle VM disks
      that reside inside a NAS/SAN or any distributed block storage provider.
      The ExtStorage Interface provides a clear API, heavily inspired by the
      gnt-os-interface API, that can be used by storage vendors or sysadmins
      to write simple ExtStorage Providers (correlated to gnt-os-interface's
      OS Definitions). Those Providers will glue externally attached shared
      storage with Ganeti, without the need of preprovisioned block devices
      on Ganeti VM-capable nodes as confined be the current `blockdev' disk
      To do so, we implement a new disk template called `ext' (of type
      DTS_EXT_MIRROR) that passes control to externally provided scripts
      (the ExtStorage Provider) for the template's basic functions:
       create / attach / detach / remove / grow
      The scripts reside under ES_SEARCH_PATH (correlated to OS_SEARCH_PATH)
      and only one ExtStorage Provider is supported called `ext'.
      The disk's logical id is the tuple ('ext', UUID.ext.diskX), where UUID
      is generated as in disk template `plain' and X is the disk's index.
      Signed-off-by: default avatarConstantinos Venetsanopoulos <cven@grnet.gr>
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      [iustin@google.com: small simplification in bdev code, pylint fixes]
      Reviewed-by: default avatarIustin Pop <iustin@google.com>
  15. 19 Dec, 2012 3 commits
    • Guido Trotter's avatar
      Add hroller htools personality · 3504d6c8
      Guido Trotter authored
      This is a new personality that for the moment doesn't do anything.
      Signed-off-by: default avatarGuido Trotter <ultrotter@google.com>
      Reviewed-by: default avatarIustin Pop <iustin@google.com>
    • Iustin Pop's avatar
      Add support for job queries in hconfd · a7e484c4
      Iustin Pop authored
      This adds support for job queries, including (basic) unit-tests.
      I've tested this for memory and cpu usage as follows:
      - 3600 jobs (live queue):
        - via masterd, default: ~1.1s (masterd: ~60MB ram)
        - via confd,   default: ~1.1s (hconfd:  ~25MB ram)
        - via masterd, id only: ~1.0s (masterd: ~57MB ram)
        - via confd,   id only: ~0.2s (hconfd:  ~15MB ram)
      - all jobs (128K in total, around 570MB size on disk):
        - via masterd, default: 1m22s (masterd cpu: 48s), masterd: 1.4G ram
        - via confd,   default: 1m16s (hconfd  cpu: 51s), hconfd:  570MB ram peak
          (peak only right before starting luxi send, hconfd decreases in RSS as
          results are streamed over luxi, back to ~18MB after the send)
        - via masterd, id only:  ~49s (masterd cpu: 45s), masterd: 1.3G ram
        - via confd,   id only:  ~39s (hconfd cpu: 35s),  hconfd:  110MB ram peak
          (right before luxi send, decreasing as results are sent, back to ~14MB
          after the send)
      Given this, and that in production it's not likely to have hundreds of
      thousand of job files, I believe the implementation is safe from this
      point of view.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarHelga Velroyen <helgav@google.com>
    • Iustin Pop's avatar
      Add a read-only job queue module · aa79e62e
      Iustin Pop authored
      This patch adds implementation for a read-only job queue module,
      together with "full" test (as full as can be in a lazy language…).
      One note about the behaviour of the job queue is the handling of
      opcodes that fail validation: the 'input' opcode actually is a
      meta-type, which can hold either a real opcode or a plain JSValue, so
      that we can still load jobs with invalid opcodes for querying. The
      only downside of this is that, as opposed to Python code, we can't
      show the correct summary for such an opcode - we try to parse the
      OP_ID but not the extended OP_DSC_FIELD-equivalent.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarHelga Velroyen <helgav@google.com>