ariatosca-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject incubator-ariatosca git commit: ARIA-166 Update README file [Forced Update!]
Date Thu, 08 Jun 2017 15:45:05 GMT
Repository: incubator-ariatosca
Updated Branches:
  refs/heads/ARIA-166-update-readme 98676df53 -> 9e8e2f079 (forced update)

ARIA-166 Update README file


Branch: refs/heads/ARIA-166-update-readme
Commit: 9e8e2f079bf557d723b7ecb018a9d62b637945a6
Parents: 5afa2f7
Author: Ran Ziv <>
Authored: Thu Jun 8 18:26:29 2017 +0300
Committer: Ran Ziv <>
Committed: Thu Jun 8 18:44:59 2017 +0300

---------------------------------------------------------------------- | 219 +++++++++++++++++----------------------------------------
 1 file changed, 66 insertions(+), 153 deletions(-)
diff --git a/ b/
index e534645..ba0a4ae 100644
--- a/
+++ b/
@@ -4,198 +4,111 @@ ARIA
 [![Build Status](](
 [![Appveyor Build Status](](
+[![PyPI release](](
+![Python Versions](
+[![Open Pull Requests](](
+[![Closed Pull Requests](](
-[ARIA]( is a minimal TOSCA orchestrator, as well as a platform for
-TOSCA-based products. Its features can be accessed via a well-documented Python API.
+[ARIA]( is a an open-source, lightweight, library
and CLI for orchestration that open-source projects can consume to build TOSCA-based orchestration
solutions for resources and services orchestration. It supports NFV and hybrid Cloud scenarios.
-On its own, ARIA provides built-in tools for blueprint validation and for creating ready-to-run
-service instances. 
+ARIA can be utilized by any organization that wants to implement TOSCA-based orchestration
in its solutions, whether a multi-cloud enterprise application, or an NFV or SDN solution
for multiple virtual infrastructure managers.
-ARIA adheres strictly and meticulously to the
-[TOSCA Simple Profile v1.0 cos01 specification](,
-providing state-of-the-art validation at seven different levels:
+With ARIA, you can utilize TOSCA's cloud portability out-of-the-box, to test and run your
applications, from template to deployment. 
-<ol start="0">
-<li>Platform errors. E.g. network, hardware, or even an internal bug in ARIA (let us
-	please!).</li>
-<li>Syntax and format errors. E.g. non-compliant YAML, XML, JSON.</li>
-<li>Field validation. E.g. assigning a string where an integer is expected, using a
list instead of
-	a dict.</li>
-<li>Relationships between fields within a type. This is "grammar" as it applies to
rules for
-    setting the values of fields in relation to each other.</li>
-<li>Relationships between types. E.g. referring to an unknown type, causing a type
-    loop.</li>
-<li>Topology. These errors happen if requirements and capabilities cannot be matched
in order to
-	assemble a valid topology.</li>
-<li>External dependencies. These errors happen if requirement/capability matching fails
due to
-    external resources missing, e.g. the lack of a valid virtual machine, API credentials,
-    </li> 
-Validation errors include a plain English message and when relevant the exact location (file,
-column) of the data the caused the error.
-The ARIA API documentation always links to the relevant section of the specification, and
-we provide an annotated version of the specification that links back to the API documentation.
+ARIA is [available on PyPI](    
+ARIA requires Python 2.6/2.7. Python 3+ is not currently supported.
-Quick Start
+ARIA itself is in a `wheel` format compatible with all platforms. 
+Some dependencies, however, might require compilation (based on a given platform), and therefore
possibly some system dependencies are required as well.
-You need Python 2.6 or 2.7. Python 3+ is not currently supported.
+On Ubuntu or other Debian-based systems:
-To install, we recommend using [pip]( and a
+	sudo apt install python-setuptools python-dev build-essential libssl-dev libffi-dev
-In Debian-based systems:
+On Archlinux:
-	sudo apt install python-setuptools
-	sudo -H easy_install pip
-	sudo -H pip install virtualenv
-	virtualenv env
+	sudo pacman -S python-setuptools
-Or in Archlinux-based systems:
-	pacman -S python2 python-setuptools python-pip
-	pip install virtualenv
-	virtualenv env -p $(type -p python2)
+To install ARIA directly from PyPI (using a `wheel`), use:
-To install the latest development snapshot of ARIA:
+    pip install aria
-	. env/bin/activate
-	pip install git+
-To test it, let's create a service instance from a TOSCA blueprint:
+To install ARIA from source, download the source tarball from [PyPI](,
+extract it, and then when inside the extracted directory, use:
-	aria parse blueprints/tosca/node-cellar/node-cellar.yaml
-You can also get it in JSON or YAML formats:
+    pip install .
+The source package comes along with relevant examples, documentation,
+`requirements.txt` (for installing specifically the frozen dependencies' versions with which
ARIA was tested) and more.
-	aria parse blueprints/tosca/node-cellar/node-cellar.yaml --json
-Or get an overview of the relationship graph:
+Note that for the `pip install` commands mentioned above, you must use a privileged user,
or use virtualenv.
-	aria parse blueprints/tosca/node-cellar/node-cellar.yaml --graph
-You can provide inputs as JSON, overriding default values provided in the blueprint
+Getting Started
-	aria parse blueprints/tosca/node-cellar/node-cellar.yaml --inputs='{"openstack_credential":
{"user": "username"}}'
+This section will describe how to run a simple "Hello World" example.
-Instead of providing them explicitly, you can also provide them in a file or URL, in either
-YAML. If you do so, the value must end in ".json" or ".yaml":
+First, provide ARIA with your service-template, naming it `my-service-template`:
-	aria parse blueprints/tosca/node-cellar/node-cellar.yaml --inputs=blueprints/tosca/node-cellar/inputs.yaml
+	aria service-templates store examples/hello-world/helloworld.yaml my-service-template
+Now create a service based on this service-template, naming it `my-service`:
+	aria services create my-service -t my-service-template
+Finally, start an `install` workflow execution on `my-service` like so:
+	aria executions start install -s my-service
+You should now have a simple web-server running on your local machine.
+You can try visiting http://localhost:9090 to view your deployed application.
-Though ARIA is fully exposed as an API, it also comes with a CLI tool to allow you to work
from the
+To uninstall and clean your environment, follow these steps:
-	aria parse blueprints/tosca/node-cellar/node-cellar.yaml instance
+    aria executions start uninstall -s my-service
+    aria services delete my-service
+    aria service-templates delete my-service-template
-The `parse` command supports the following directives to create variations of the default
-* `presentation`: emits a colorized textual representation of the Python presentation classes
-   wrapping the blueprint.
-* `model`: emits a colorized textual representation of the complete service model derived
from the
-   validated blueprint. This includes all the node templates, with their requirements satisfied
-   the level of relating to other node templates.
-* `types`: emits a colorized textual representation of the type hierarchies.
-* `instance`: **this is the default command**; emits a colorized textual representation of
-   service instance instantiated from the service model. Here the node templates are each
used to
-   create one or more nodes, with the appropriate relationships between them. Note that every
-   you run this consumer, you will get a different set of node IDs. Use `--graph` to see
just the
-   node relationship graph.
-For all these commands, you can also use `--json` or `--yaml` flags to emit in those formats.
-Additionally, The CLI tool lets you specify the complete classname of your own custom consumer
-chain at the end of the default consumer chain, after `instance`.
+You are welcome and encouraged to participate and contribute to the ARIA project.
-Your custom consumer can be an entry point into a powerful TOSCA-based tool or application,
such as
-an orchestrator, a graphical modeling tool, etc.
+Please see our guide to [Contributing to ARIA](
+Feel free to also provide feedback on the mailing lists (see [Resources](#user-content-resources)
-Instead of installing with `pip`, it would be easier to work directly with the source files:
-	pip install virtualenv
-	virtualenv env
-	. env/bin/activate
-	git clone ariatosca
-	cd ariatosca
-	pip install -e .
+* [ARIA homepage](
+* [ARIA wiki](
+* [Issue tracker](
-To run tests:
+* Dev mailing list:
+* User mailing list:
-	pip install tox
-	tox
+See information on how to subscribe to mailing list [here](
-Here's a quick example of using the API to parse YAML text into a service instance:
+For past correspondence, see the [dev mailing list archive](
-	from aria import install_aria_extensions
-	from aria.parser.consumption import ConsumptionContext, ConsumerChain, Read, Validate, Model,
-	from aria.parser.loading import LiteralLocation
-	def parse_text(payload, file_search_paths=[]):
-	    context = ConsumptionContext()
-	    context.presentation.location = LiteralLocation(payload)
-	    context.loading.file_search_paths += file_search_paths
-	    ConsumerChain(context, (Read, Validate, Model, Instance)).consume()
-	    if not context.validation.dump_issues():
-	        return context.modeling.instance
-	    return None
-	install_aria_extensions()
-	print parse_text("""
-	tosca_definitions_version: tosca_simple_yaml_1_0
-	topology_template:
-	  node_templates:
-	    MyNode:
-	      type: tosca.nodes.Compute 
-	""")
-Parser API Architecture
-ARIA's parsing engine comprises individual "consumers" (in the `aria.parser.consumption`
-that do things with blueprints. When chained together, each performs a different task, adds
its own
-validations, and can provide its own output.
-Parsing happens in five phases, represented in five packages:
-* `aria.parser.loading`: Loaders are used to read the TOSCA data, usually as text. For example
-  UriTextLoader will load text from URIs (including files).
-* `aria.parser.reading`: Readers convert data from the loaders into agnostic raw data. For
-  example, `YamlReader` converts YAML text into Python dicts, lists, and primitives.
-* `aria.parser.presentation`: Presenters wrap the agnostic raw data in a nice
-  Python facade (a "presentation") that makes it much easier to work with the data, including
-  utilities for validation, querying, etc. Note that presenters are _wrappers_: the agnostic
-  data is always maintained intact, and can always be accessed directly or written back to
-* `aria.parser.modeling.model`: Here the topology is normalized into a coherent structure
-  node templates, requirements, and capabilities. Types are inherited and properties are
-  The service model is a _new_ structure, which is not mapped to the YAML. In fact, it is
-  to generate the model programmatically, or from a DSL parser other than TOSCA.
-* `aria.parser.modeling.instance`: The service instance is an instantiated service model.
-  templates turn into node instances (with unique IDs), and requirements are satisfied by
-  them to capabilities. This is where level 5 validation errors are detected (see above).
-The phases do not have to be used in order. Indeed, consumers do not have to be used at all:
-can be used to _produce_ blueprints. For example, it is possible to fill in the
-`aria.parser.presentation` classes programmatically, in Python, and then write the presentation
-to a YAML file as compliant TOSCA. The same technique can be used to convert from one DSL
-it) to another (write it).
-The term "agnostic raw data" (ARD?) appears often in the documentation. It denotes data structures
-comprising _only_ Python dicts, lists, and primitives, such that they can always be converted
to and
-from language-agnostic formats such as YAML, JSON, and XML. A considerable effort has been
made to
-conserve the agnostic raw data at all times. Thus, though ARIA makes good use of the dynamic
-of Python, you will _always_ be able to use ARIA with other systems.
+ARIA is licensed under the [Apache License 2.0](

View raw message