1. 15 Jan, 2013 1 commit
  2. 24 Dec, 2012 1 commit
  3. 20 Dec, 2012 3 commits
  4. 19 Dec, 2012 3 commits
  5. 11 Dec, 2012 1 commit
  6. 07 Dec, 2012 1 commit
  7. 06 Dec, 2012 1 commit
  8. 04 Dec, 2012 1 commit
    • Iustin Pop's avatar
      Rework custom fields handling · fa10983e
      Iustin Pop authored
      
      
      This patch changes a bit the handling of custom fields. Since in
      general we use custom fields to aggregate multiple entries in the JSON
      object into a safer data-type, we should also have a way to declare
      which extra entries this field covers (so that in the future we can
      say what are all the JSON keys for an object).
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
      fa10983e
  9. 30 Nov, 2012 3 commits
  10. 21 Nov, 2012 1 commit
  11. 20 Nov, 2012 1 commit
    • Iustin Pop's avatar
      Create a new Ganeti/Types.hs module · 5e9deac0
      Iustin Pop authored
      There are already three cases where we copied type definitions between
      the htools-specific types into the main ganeti code. Let's stop doing
      this 
      
       and create a common types module that holds these.
      
      Note that there already exists BasicTypes.hs, but that refers to very
      low-level types, and can't use TH derivation itself.
      
      A side effect of this unification is that there is a small conflict
      between AdminStatus/AdminOffline and InstanceStatus/AdminOffline. As
      such, I renamed AdminOffline and AdminDown to StatusOffline/StatusDown
      in the InstanceStatus type.
      
      The patch also moves the tests related to these types to a new test
      module.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarAdeodato Simo <dato@google.com>
      5e9deac0
  12. 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
  13. 08 Oct, 2012 1 commit
  14. 26 Sep, 2012 1 commit
  15. 05 Sep, 2012 3 commits
    • Iustin Pop's avatar
      Further hlint fixes · 5b11f8db
      Iustin Pop authored
      Commit 2cdaf225, “Re-enable standard hlint warnings”, got it almost
      right. The only problem is that (confusingly) the default set of hints
      is not in HLint.Default, but in HLint.HLint (it includes Default and
      some built-ins).
      
      After changing the lint file to correctly include the defaults, we had
      another 128 suggestions:
      
        - Error: Eta reduce (2)
        - Error: Redundant bracket (4)
        - Error: Redundant do (17)
        - Error: Redundant lambda (7)
        - Error: Redundant return (1)
        - Warning: Avoid lambda (2)
        - Warning: Redundant $ (42)
        - Warning: Redundant bracket (35)
        - Warning: Use : (1)
        - Warning: Use String (4)
        - Warning: Use camelCase (10)
        - Warning: Use section (3)
      
      which are fixed by the current patch. Note that the 10 "Use camelCase"
      were all due to hlint not “knowing” the idiom of ‘case_’ (it does for
      ‘prop_’), for which I filled
      http://code.google.com/p/ndmitchell/issues/detail?id=558
      
      .
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarRené Nussbaumer <rn@google.com>
      5b11f8db
    • Iustin Pop's avatar
      Add entire ConfigData serialisation tests · 9924d61e
      Iustin Pop authored
      
      
      Using the recently-added genArbitrary, we can now implement Arbitrary
      instances for even "huge" objects like Cluster, so let's use that to
      implement entire ConfigData serialisation tests.
      
      Note that, as we don't have yet proper types for some of the Params
      fields, we have to cheat via FlexibleInstances and
      TypeSynonymInstances, using either empty items or real arbitrary
      values.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarRené Nussbaumer <rn@google.com>
      9924d61e
    • Iustin Pop's avatar
      Add unit test for serialisation of DiskLogicalId and Nodes · 8d2b6a12
      Iustin Pop authored
      
      
      Since the DiskLogicalId type is manually serialised/deserialised (see
      Objects.hs, `encodeDLid' and `decodeDLId'), let's add a test that
      checks that these are idempotent when combined.
      
      Since we're at it, let's add the same test for Node serialisation,
      which already has an Arbitrary instance.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarRené Nussbaumer <rn@google.com>
      8d2b6a12
  16. 04 Sep, 2012 1 commit
  17. 03 Sep, 2012 6 commits
  18. 28 Aug, 2012 6 commits
  19. 19 Jul, 2012 1 commit
    • Iustin Pop's avatar
      Add disk logical ID support in Objects.hs · 2e12944a
      Iustin Pop authored
      
      
      This is a complex field, so we have to do a lot of manual work for now.
      
      The complexity arises from the fact that the contents of the field,
      and the way to parse it, depends on the disk type field, so we don't
      have a single, static way of parsing it. Hence we needed the
      extensions to the Template Haskell code.
      
      Since we now can both load and save the disk type, we can remove the
      in-memory (duplicate) disk type from the disk objects, relying only on
      the logical ID to hold the type information.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarRené Nussbaumer <rn@google.com>
      2e12944a
  20. 13 Mar, 2012 1 commit
    • Iustin Pop's avatar
      htools: add partial implementation of lib/objects.py · b1e81520
      Iustin Pop authored
      
      
      This is partial since not all object types can be easily converted for
      now (will need some changes on the Python side for this).
      
      Most importantly, the *Params types do not have a good solution now:
      the Python code, due to its dynamic typing, hides the fact that we
      actually have two different types at play: a full type which needs to
      have all keys, and the 'partial' type which has slightly different
      behaviour. I've implemented these in Haskell as two different types,
      Full* and Partial*, which are derived automatically from a single
      Parameter type, together with the associated Fill* functions.
      
      Furthermore, HVParams is even more special, as its contents is not
      fixed but varies per hypervisor type, plus it has the HV_GLOBALS part
      which should not be customisable at instance type (yay for
      exceptions). As such, this should be written in Haskell as a
      multi-constructor type, but it's the only one so far and thus we don't
      have support for it yet.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
      b1e81520