From: Philip Joseph Date: Sun, 2 Oct 2016 18:19:12 +0000 (+0530) Subject: Move VyOS charm to juju-charms repo X-Git-Tag: v2.0.2~6^2~30 X-Git-Url: https://osm.etsi.org/gitweb/?a=commitdiff_plain;h=f3222757939b60cdbe3702ac866507e965d4bcc5;p=osm%2Fdevops.git Move VyOS charm to juju-charms repo Signed-off-by: Philip Joseph --- diff --git a/Makefile b/Makefile index da511cb7..78acdffc 100644 --- a/Makefile +++ b/Makefile @@ -76,5 +76,9 @@ $(VNFD_BUILD_DIR)/6wind_vnf/charms/vpe-router: $(VNFD_BUILD_DIR)/6wind_vnf $(BUI # Copy the PE Charm into the PE vnf package directory before packaging cp -rf $(BUILD_DIR)/juju-charms/builds/vpe-router $(VNFD_BUILD_DIR)/6wind_vnf/charms -$(BUILD_DIR)/vnfd_pkgs/%.tar.gz: $(VNFD_BUILD_DIR)/% $(VNFD_BUILD_DIR)/ims_allin1_2p_vnf/charms/clearwater-aio-proxy $(VNFD_BUILD_DIR)/6wind_vnf/charms/vpe-router +$(VNFD_BUILD_DIR)/VyOS_vnf/charms/VyOS-proxy: $(VNFD_BUILD_DIR)/VyOS_vnf $(BUILD_DIR)/juju-charms + # Copy the PE Charm into the PE vnf package directory before packaging + cp -rf $(BUILD_DIR)/juju-charms/builds/VyOS-proxy $(VNFD_BUILD_DIR)/VyOS_vnf/charms + +$(BUILD_DIR)/vnfd_pkgs/%.tar.gz: $(VNFD_BUILD_DIR)/% $(VNFD_BUILD_DIR)/ims_allin1_2p_vnf/charms/clearwater-aio-proxy $(VNFD_BUILD_DIR)/6wind_vnf/charms/vpe-router $(VNFD_BUILD_DIR)/VyOS_vnf/charms/VyOS-proxy src/generate_descriptor_pkg.sh -d $(BUILD_DIR)/vnfd_pkgs $< diff --git a/src/vnfd/VyOS_vnf/charms/VyOS-proxy/Makefile b/src/vnfd/VyOS_vnf/charms/VyOS-proxy/Makefile deleted file mode 100644 index a1ad3a5c..00000000 --- a/src/vnfd/VyOS_vnf/charms/VyOS-proxy/Makefile +++ /dev/null @@ -1,24 +0,0 @@ -#!/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/src/vnfd/VyOS_vnf/charms/VyOS-proxy/README.ex b/src/vnfd/VyOS_vnf/charms/VyOS-proxy/README.ex deleted file mode 100644 index b6816b22..00000000 --- a/src/vnfd/VyOS_vnf/charms/VyOS-proxy/README.ex +++ /dev/null @@ -1,65 +0,0 @@ -# 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/src/vnfd/VyOS_vnf/charms/VyOS-proxy/README.md b/src/vnfd/VyOS_vnf/charms/VyOS-proxy/README.md deleted file mode 100644 index 0337c83b..00000000 --- a/src/vnfd/VyOS_vnf/charms/VyOS-proxy/README.md +++ /dev/null @@ -1,221 +0,0 @@ -# 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.