Skip to content
Snippets Groups Projects
  1. Nov 20, 2012
  2. Nov 16, 2012
  3. Nov 15, 2012
    • 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
  4. Nov 14, 2012
  5. Nov 13, 2012
  6. Nov 12, 2012
    • Iustin Pop's avatar
      Remove unsafePerformIO usage · 29a30533
      Iustin Pop authored
      
      We need to change a few things, most importantly CLI options defaults,
      but otherwise we already used the path to files from functions which
      were already in the I/O monad, so we don't have to change much of the
      code flow.
      
      Additionally, Path.hs now has an explicit export list, to stop
      accidental leakage of symbols.
      
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarHelga Velroyen <helgav@google.com>
      29a30533
    • Iustin Pop's avatar
      Change keyToFilename/readSSconfFile interaction · 37904802
      Iustin Pop authored
      
      Currently, keyToFilename uses itself the default config path. In the
      light of making that an function in the IO monad, let's remove the
      "default" path functionality from this function and make it always
      require the config path; its caller, readSSConfFile, can then do the
      maybe/default path change.
      
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
      37904802
    • Iustin Pop's avatar
      Change type of program options to 'IO [Options]' · d66aa238
      Iustin Pop authored
      
      Some options have defaults that depend on the environment, and we
      could handle these in two ways:
      
      - use a place-holder value (e.g. data X a = Default | Custom a) that
        is later read from the environment
      - move the options list to IO monad, where it can read the
        environment, etc.
      
      The second option allows also displaying the actual defaults in the
      `--help' output, even though it's not as nice, so I went with it.
      
      This patch only changes the option types, without actually changing
      any options yet.
      
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarHelga Velroyen <helgav@google.com>
      d66aa238
    • 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
    • Iustin Pop's avatar
      Fix display of results in ==? operator · a309a3b4
      Iustin Pop authored
      
      Doh, this is exactly the opposite of what we wanted… good thing no
      test failed so far :)
      
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
      a309a3b4
  7. Nov 08, 2012
  8. Nov 06, 2012
  9. Oct 26, 2012
  10. Oct 25, 2012
    • Iustin Pop's avatar
      Convert query path from string errors to GanetiException · 5183e8be
      Iustin Pop authored
      
      This patch converts all the call paths from 'Result' (which contains
      just string errors) to 'ErrorResult', which holds
      GanetiException-encoded errors. We can now return proper
      OpPrereq/OpExec errors to the clients of the luxi/query socket.
      
      The patch touches many files as we had to convert the entire call
      chains in a single round. But it should be pretty straightforward
      otherwise:
      
      - change 'Result' into 'ErrorResult'
      - add error annotations: change "Bad msg" into "Bad (XXXEror msg)"
      - add a helper function for confd, where we don't send to client
        formatted exceptions, to convert back from ErrorResult into Result
      - change tests similarly, where needed
      
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
      5183e8be
    • Iustin Pop's avatar
      Add an Errors module mirroring the Python one · ef3ad027
      Iustin Pop authored
      
      As described in the module doc string, while writing this it dawned
      upon me that we're mixing all errors together into a single hierarchy
      (well, type on the Haskell side), which is not good. Some errors are
      used purely within noded, some in the CLI frontends, etc. so these
      should not be the same type; frontend functions should only be able to
      raise frontend errors, not backend ones.
      
      As to this patch itself, I've used again Template Haskell to generate
      both the data type and the serialisation functions, as the initial
      version, hand-written, seemed too prone to errors due to string
      matching.
      
      A small unittest for checking serialisation consistency is also added.
      
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
      ef3ad027
  11. Oct 22, 2012
  12. Oct 18, 2012
  13. Oct 17, 2012
    • Iustin Pop's avatar
      Generalise the Result type · 93be1ced
      Iustin Pop authored
      
      Currently, our error monad—Result—has a plain string error type. This
      is not good, as we don't have structured errors, we can't pass back
      proper error information to Python code, etc.
      
      To solve this, we generalise this type as 'GenericResult a', and make
      Result an alias to 'GenericResult String' for compatibility with the
      old code. New error hierarchies will be introduced as different
      types. Furthermore, we generalise our helper functions too, so that
      they can work on any 'GeneralInstance a' type, not only Result.
      
      There are two small drawbacks to this generalisation. First, a Monad
      instance requires (at least for the way we use it) a 'fail :: String
      -> m a' instance, so we need to be able to build an 'a' value from a
      string; therefore, we can implement the Monad instance only for a
      newly-introduced typeclass, 'FromString', which requires the needed
      conversion function. Second, due to the fact that 'String' is a type
      alias (for [Char]) instead of an actual type, we need to enable the
      FlexibleInstances language pragma; as far as I know, this has no
      significant drawbacks.
      
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
      93be1ced
  14. Oct 15, 2012
    • Iustin Pop's avatar
      Cleanup HTools.Types/BasicTypes imports · 01e52493
      Iustin Pop authored
      
      Before we reorganised the source tree, the 'Result' type was exported
      from HTools/Types.hs. This changed during the reorg, but at that time
      we didn't change the exports; instead, we kept re-exporting it from
      the old module for compatibility.
      
      In light of future changes to the Result type, let's stop this
      re-export and cleanup the imports of the other modules.
      
      One test is slightly rewritten with explicit types declaration (part
      of the values already needed one, let's make it explicit).
      
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
      01e52493
  15. Oct 11, 2012
Loading