haskell-kubernetes

This project contains haskell bindings to the v1 Kubernetes api generated via swagger-codegen. The client and (mock) server generated use the servant project, thanks to the work of Masahiro Yamauchi!

About the Generated Code

• all fields are strict
• aeson instances are generated for each type with the appropriate keys
• Lenses are generated for every field, with plain names for each lens (e.g. min, object, etc.). So be careful with unqualified imports.
• Fields specified as "not required" (missing a "required" field in the swagger description) are represented as a Maybe, even when that field refers to a list (e.g. Maybe [Foo]). This is done for consistent JSON parsing of the generated aeson instances.
• In lieu of suitable Default instances, builder methods are exported. Each datatype has a corresponding mk{{datatype}} method to construct it, requiring only required fields.
• API coverage is almost full. As servant-0.7.1 lacks support for HEAD and OPTIONS endpoints, those endpoints were excluded from the client and server implementation (any related datatypes are still generated).
• client bindings were only spot tested (PR's welcomed!).
• the mock-server was only spot tested (PR's welcomed!).

Dependencies

haskell-kubernetes depends on the following software:

• Glasgow Haskell Compiler 7.8.4 or 7.10.*
• for code generation: swagger-codegen.
• for code generation: stylish-haskell to clean up the generated code.
• for code generation: GNU sed (code generation may not work with the sed shipped with Mac OS X)

Documentation

In addition to the README (this file), there is a directory of additional documentation:

• The Getting started information helps to understand limitations of the library, nuances about the generated datatypes, and the code generation process in general.
• The Contributing to haskell-kubernetes page lists severals ways that you can improve haskell-kubernetes.
• The list of potential improvements are prioritized.

Versioning

haskell-kubernetes adheres to Semantic Versioning 2.0.0. If there is a violation of this scheme, report it as a bug.Specifically, if a patch or minor version is released and breaks backward compatibility, that version should be immediately yanked and/or a new version should be immediately released that restores compatibility. Any change that breaks the public API will only be introduced at a major-version release. As a result of this policy, you can (and should) specify any dependency on by using the Pessimistic Version Constraint with two digits of precision.

Licensing

See the LICENSE file for details.