hippo-module's Introduction

hippo-module

Prototype for representing ARM modules using jsonnet.

Getting started

Running examples

Clone the repository
Make sure that you have jsonnet installed and on your path
Run jsonnet <example file> -J <root of repository>

How to contribute

Structure of the repository

<root>
+-- core
    +-- module.libsonnet    # Main module file exposing module
    +-- moduledef.libsonnet # Structure of a module
    +-- resource.libsonnet  # Structure for an individual resource
+-- example_consumers
    +-- vmss_cli.jsonnet    # Intended to be a module used by the azure cli vmss create command
+-- <other modules>
    +-- module.libsonnet

Module

A module is a folder that contains the following files:

modulename 
+-- module.libsonnet
+-- parameters.schema.json
+-- <additional libsonnet files>

where modulename is the name of the module.

module.json

The structure of a module is a json object with two required properties; resources and outputs.

local core = import 'core/module.libsonnet';

{
    resources: {
      resource1: core.Module {
      },
      resource2: core.Module {
      }
    },
    outputs: {
    }
}

hippo-module's People

Contributors

Watchers

hippo-module's Issues

How should parameter metadata be represented for a module?

Current thinking; json schema for parameters in module (parameters.schema.json)

How to deal with secrets/parameters

We don't want secrets end up being expanded/getting the literal values into the expanded templates since that would allow for subsequent retrieval of the values from ARM. Somehow we need to have a mechanism like secureString/secureObject type parameters for ARM templates.

Should parameters be top level (hidden) attributes of a module?

...or should we have a single well-known parameters attribute for parameters? Currently, they are top level, but that may cause problems with actual resource top level attributes (i.e. name, sku, type etc.)

Recommend Projects