1. 23 Jul, 2013 1 commit
  2. 15 Jul, 2013 1 commit
  3. 20 Jun, 2013 1 commit
    • Thomas Thrainer's avatar
      Index instances by their UUID · da4a52a3
      Thomas Thrainer authored
      
      
      No longer index instances by their name but by their UUID in the cluster
      config. This change changes large parts of the code, as the following
      adjustments were necessary:
       * Change the index key to UUID in the configuration and the
         ConfigWriter, including all methods.
       * External interfaces (command line interface, IAllocator interface,
         hook scripts, etc.) are kept stable.
       * Instance UUID's are resolved in ExpandNames and then stored in the
         OpCode. This allows to check for instance renames if the OpCode is
         reloaded after a cluster restart. This check is currently only done
         for single instance parameters.
       * Instance locking unfortunately can't use instances UUID as
         identifiers. The reasons is that new instances (which have no UUID
         yet) have to be locked as well, so the instance name is used.
       * Variable names are renamed to follow the following pattern:
         - Suffix is 'inst' or 'insts': Variable holds Instance objects
         - Suffix is 'name' or 'names': Variable holds Instance names
         - Suffix is 'uuid' or 'uuids': Variable holds Instance UUID's
       * Tests are adapted.
      Signed-off-by: default avatarThomas Thrainer <thomasth@google.com>
      Reviewed-by: default avatarKlaus Aehlig <aehlig@google.com>
      da4a52a3
  4. 13 Jun, 2013 1 commit
    • Thomas Thrainer's avatar
      Index nodes by their UUID · 1c3231aa
      Thomas Thrainer authored
      
      
      No longer index nodes by their name but by their UUID in the cluster
      config. This change changes large parts of the code, as the following
      adjustments were necessary:
       * Change the index key to UUID in the configuration and the
         ConfigWriter, including all methods.
       * Change all cross-references to nodes to use UUID's.
       * External interfaces (command line interface, IAllocator interface,
         hook scripts, etc.) are kept stable.
       * RPC-calls can resolve UUID's as target node arguments, if the RPC
         runner is based on a ConfigWriter instance. The result dictionary is
         presented in the form the nodes are addressed: by UUID if UUID's were
         given, or by name if names were given.
       * Node UUID's are resolved in ExpandNames and then stored in the
         OpCode. This allows to check for node renames if the OpCode is
         reloaded after a cluster restart. This check is currently only done
         for single node parameters.
       * Variable names are renamed to follow the following pattern:
         - Suffix is 'node' or 'nodes': Variable holds Node objects
         - Suffix is 'name' or 'names': Variable holds node names
         - Suffix is 'uuid' or 'uuids': Variable holds node UUID's
       * Tests are adapted.
      Signed-off-by: default avatarThomas Thrainer <thomasth@google.com>
      Reviewed-by: default avatarKlaus Aehlig <aehlig@google.com>
      1c3231aa
  5. 30 Apr, 2013 1 commit
  6. 22 Apr, 2013 1 commit
  7. 17 Apr, 2013 1 commit
  8. 11 Apr, 2013 2 commits
  9. 21 Mar, 2013 1 commit
  10. 19 Feb, 2013 1 commit
  11. 11 Feb, 2013 1 commit
  12. 24 Dec, 2012 1 commit
  13. 19 Dec, 2012 1 commit
  14. 17 Dec, 2012 4 commits
  15. 07 Dec, 2012 1 commit
  16. 04 Dec, 2012 3 commits
  17. 30 Nov, 2012 10 commits
  18. 21 Nov, 2012 2 commits
  19. 20 Nov, 2012 1 commit
    • Iustin Pop's avatar
      Split OpCode.hs and add module for opcode parameters · 92f51573
      Iustin Pop authored
      
      
      Due to TemplateHaskell stage restrictions, we can't define parameters
      in the same module as we're using them for TH, so we have to define
      all module parameters in a separate module.
      
      This patch therefore splits OpCodes.hs in two, adding that module and
      moves most code there (types, parameters, etc.). The remaining parts
      in OpCodes.hs, the actual opcode definitions, now use more parameters
      instead of direct field definitions (more will come later)
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarAdeodato Simo <dato@google.com>
      92f51573
  20. 15 Nov, 2012 1 commit
    • Iustin Pop's avatar
      Cleanup THH function use from built module namespace · 32a569fe
      Iustin Pop authored
      
      
      Currently, THH.hs "injects" into the built code names of library
      functions like Text.JSON.makeObj, Ganeti.JSON.fromObj, etc. built
      directly from strings, via (e.g.)
      
        varE (mkName "makeObj")
      
      This means that the "makeObj" name must exist in the target module,
      i.o.w. must be imported there. This leads to the strange case of
      having to have imports that do not appear at all in the used
      (template) code, but are needed to satisfy this "hidden" dependency;
      look at Ganeti/Jobs.hs before this patch, for example.
      
      This is also not very obvious, because we usually import Text.JSON
      anyway; I only stumbled upon it while doing some cleanup work.
      
      So to clean this up, the current patch changes the THH.hs to use not
      string-derived, but identifier-derived names («'identifier» versus
      «mkName "identifier"»); this is better, as the names must be
      resolvable when compiling THH itself (once), and not when compiling
      the multiple derived modules. As you can see, this allows removal of
      extraneous imports from various modules.
      
      Background information: an `mkName "foo"` results in a name of flavour
      NameS (“An unqualified name; dynamically bound”) or alternatively to a
      qualified name, but still dynamically bound. Whereas what we want is a
      statically bound name: `'foo` results in a NameG flavour, “Global name
      bound outside of the TH AST: An original name”.
      
      One more explanation: the change is similar to going from 'x = eval
      "map"' to 'x = map'; the name is no longer dynamically evaluated, but
      statically when the module is compiled. In our case, previously names
      were bound at target module compile time, now they are bound at THH.hs
      compile time.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
      32a569fe
  21. 12 Nov, 2012 1 commit
    • Iustin Pop's avatar
      Convert tag objects to a safer type · d8e7c45e
      Iustin Pop authored
      
      
      Currently, we keep information about the "target" of a tag operation
      in a data type similar to (TagKind, Maybe String). This is unsafe, as
      nothing (at the type level) prevents us from accidentally having
      (TagCluster, Just "instance1.example.com"), or (TagInstance, Nothing).
      
      To fix this problem, we rename the current TagObject type to TagType
      (an internal utility type), and create TagObject as a better/safer
      data type (see the definition), which doesn't allow such possibilities
      in the future.
      
      The downside is that, since at encoding level (both opcode and luxi)
      this is done in an ugly way (type elements spread at the same level as
      level as other value), we have to add custom encoders/decoders. The
      encoder is shared between the OpCode and Luxi usage, the decoder is
      different however as Luxi uses custom decoding.
      
      This also fixes the recent breakage in confd w.r.t. QueryTags.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
      d8e7c45e
  22. 08 Nov, 2012 2 commits
  23. 04 Sep, 2012 1 commit