From: Philip Joseph Date: Sun, 2 Oct 2016 18:01:02 +0000 (+0530) Subject: Move VyOS charm from descriptor repo to here X-Git-Tag: v2.0.2~7^2~16 X-Git-Url: https://osm.etsi.org/gitweb/?a=commitdiff_plain;h=f9c7222f8eac9bdf3aba6f378532f5f96923c641;p=osm%2Fdevops.git Move VyOS charm from descriptor repo to here Signed-off-by: Philip Joseph --- diff --git a/builds/VyOS-proxy/Makefile b/builds/VyOS-proxy/Makefile new file mode 100644 index 00000000..a1ad3a5c --- /dev/null +++ b/builds/VyOS-proxy/Makefile @@ -0,0 +1,24 @@ +#!/usr/bin/make + +all: lint unit_test + + +.PHONY: clean +clean: + @rm -rf .tox + +.PHONY: apt_prereqs +apt_prereqs: + @# Need tox, but don't install the apt version unless we have to (don't want to conflict with pip) + @which tox >/dev/null || (sudo apt-get install -y python-pip && sudo pip install tox) + +.PHONY: lint +lint: apt_prereqs + @tox --notest + @PATH=.tox/py34/bin:.tox/py35/bin flake8 $(wildcard hooks reactive lib unit_tests tests) + @charm proof + +.PHONY: unit_test +unit_test: apt_prereqs + @echo Starting tests... + tox diff --git a/builds/VyOS-proxy/README.ex b/builds/VyOS-proxy/README.ex new file mode 100644 index 00000000..b6816b22 --- /dev/null +++ b/builds/VyOS-proxy/README.ex @@ -0,0 +1,65 @@ +# Overview + +Describe the intended usage of this charm and anything unique about how this +charm relates to others here. + +This README will be displayed in the Charm Store, it should be either Markdown +or RST. Ideal READMEs include instructions on how to use the charm, expected +usage, and charm features that your audience might be interested in. For an +example of a well written README check out Hadoop: +http://jujucharms.com/charms/precise/hadoop + +Use this as a Markdown reference if you need help with the formatting of this +README: http://askubuntu.com/editing-help + +This charm provides [service][]. Add a description here of what the service +itself actually does. + +Also remember to check the [icon guidelines][] so that your charm looks good +in the Juju GUI. + +# Usage + +Step by step instructions on using the charm: + +juju deploy servicename + +and so on. If you're providing a web service or something that the end user +needs to go to, tell them here, especially if you're deploying a service that +might listen to a non-default port. + +You can then browse to http://ip-address to configure the service. + +## Scale out Usage + +If the charm has any recommendations for running at scale, outline them in +examples here. For example if you have a memcached relation that improves +performance, mention it here. + +## Known Limitations and Issues + +This not only helps users but gives people a place to start if they want to help +you add features to your charm. + +# Configuration + +The configuration options will be listed on the charm store, however If you're +making assumptions or opinionated decisions in the charm (like setting a default +administrator password), you should detail that here so the user knows how to +change it immediately, etc. + +# Contact Information + +Though this will be listed in the charm store itself don't assume a user will +know that, so include that information here: + +## Upstream Project Name + + - Upstream website + - Upstream bug tracker + - Upstream mailing list or contact information + - Feel free to add things if it's useful for users + + +[service]: http://example.com +[icon guidelines]: https://jujucharms.com/docs/stable/authors-charm-icon diff --git a/builds/VyOS-proxy/README.md b/builds/VyOS-proxy/README.md new file mode 100644 index 00000000..0337c83b --- /dev/null +++ b/builds/VyOS-proxy/README.md @@ -0,0 +1,221 @@ +# Overview + +This is the base layer for all charms [built using layers][building]. It +provides all of the standard Juju hooks and runs the +[charms.reactive.main][charms.reactive] loop for them. It also bootstraps the +[charm-helpers][] and [charms.reactive][] libraries and all of their +dependencies for use by the charm. + +# Usage + +To create a charm layer using this base layer, you need only include it in +a `layer.yaml` file: + +```yaml +includes: ['layer:basic'] +``` + +This will fetch this layer from [interfaces.juju.solutions][] and incorporate +it into your charm layer. You can then add handlers under the `reactive/` +directory. Note that **any** file under `reactive/` will be expected to +contain handlers, whether as Python decorated functions or [executables][non-python] +using the [external handler protocol][]. + +### Charm Dependencies + +Each layer can include a `wheelhouse.txt` file with Python requirement lines. +For example, this layer's `wheelhouse.txt` includes: + +``` +pip>=7.0.0,<8.0.0 +charmhelpers>=0.4.0,<1.0.0 +charms.reactive>=0.1.0,<2.0.0 +``` + +All of these dependencies from each layer will be fetched (and updated) at build +time and will be automatically installed by this base layer before any reactive +handlers are run. + +Note that the `wheelhouse.txt` file is intended for **charm** dependencies only. +That is, for libraries that the charm code itself needs to do its job of deploying +and configuring the payload. If the payload itself has Python dependencies, those +should be handled separately, by the charm. + +See [PyPI][pypi charms.X] for packages under the `charms.` namespace which might +be useful for your charm. + +### Layer Namespace + +Each layer has a reserved section in the `charms.layer.` Python package namespace, +which it can populate by including a `lib/charms/layer/.py` file or +by placing files under `lib/charms/layer//`. (If the layer name +includes hyphens, replace them with underscores.) These can be helpers that the +layer uses internally, or it can expose classes or functions to be used by other +layers to interact with that layer. + +For example, a layer named `foo` could include a `lib/charms/layer/foo.py` file +with some helper functions that other layers could access using: + +```python +from charms.layer.foo import my_helper +``` + +### Layer Options + +Any layer can define options in its `layer.yaml`. Those options can then be set +by other layers to change the behavior of your layer. The options are defined +using [jsonschema][], which is the same way that [action paramters][] are defined. + +For example, the `foo` layer could include the following option definitons: + +```yaml +includes: ['layer:basic'] +defines: # define some options for this layer (the layer "foo") + enable-bar: # define an "enable-bar" option for this layer + description: If true, enable support for "bar". + type: boolean + default: false +``` + +A layer using `foo` could then set it: + +```yaml +includes: ['layer:foo'] +options: + foo: # setting options for the "foo" layer + enable-bar: true # set the "enable-bar" option to true +``` + +The `foo` layer can then use the `charms.layer.options` helper to load the values +for the options that it defined. For example: + +```python +from charms import layer + +@when('state') +def do_thing(): + layer_opts = layer.options('foo') # load all of the options for the "foo" layer + if layer_opts['enable-bar']: # check the value of the "enable-bar" option + hookenv.log("Bar is enabled") +``` + +You can also access layer options in other handlers, such as Bash, using +the command-line interface: + +```bash +. charms.reactive.sh + +@when 'state' +function do_thing() { + if layer_option foo enable-bar; then + juju-log "Bar is enabled" + juju-log "bar-value is: $(layer_option foo bar-value)" + fi +} + +reactive_handler_main +``` + +Note that options of type `boolean` will set the exit code, while other types +will be printed out. + +# Hooks + +This layer provides hooks that other layers can react to using the decorators +of the [charms.reactive][] library: + + * `config-changed` + * `install` + * `leader-elected` + * `leader-settings-changed` + * `start` + * `stop` + * `upgrade-charm` + * `update-status` + +Other hooks are not implemented at this time. A new layer can implement storage +or relation hooks in their own layer by putting them in the `hooks` directory. + +**Note:** Because `update-status` is invoked every 5 minutes, you should take +care to ensure that your reactive handlers only invoke expensive operations +when absolutely necessary. It is recommended that you use helpers like +[`@only_once`][], [`@when_file_changed`][], and [`data_changed`][] to ensure +that handlers run only when necessary. + +# Layer Configuration + +This layer supports the following options, which can be set in `layer.yaml`: + + * **packages** A list of system packages to be installed before the reactive + handlers are invoked. + + * **use_venv** If set to true, the charm dependencies from the various + layers' `wheelhouse.txt` files will be installed in a Python virtualenv + located at `$CHARM_DIR/../.venv`. This keeps charm dependencies from + conflicting with payload dependencies, but you must take care to preserve + the environment and interpreter if using `execl` or `subprocess`. + + * **include_system_packages** If set to true and using a venv, include + the `--system-site-packages` options to make system Python libraries + visible within the venv. + +An example `layer.yaml` using these options might be: + +```yaml +includes: ['layer:basic'] +options: + basic: + packages: ['git'] + use_venv: true + include_system_packages: true +``` + + +# Reactive States + +This layer will set the following states: + + * **`config.changed`** Any config option has changed from its previous value. + This state is cleared automatically at the end of each hook invocation. + + * **`config.changed.