ARIA-166 Update README file

ARIA-199 Add "services outputs" CLI command

* Also add an output to hello world example

ARIA-213 sporadic tests failures over locked database issue

Increased the timeout for acquiring database lock (for sqlite based db).

ARIA-262 Inconsistent node attributes behavior

Inroduced a more comprehensive way to instrument relationship attributes.

Old behavior instrumented attributes only if they were accessed directly from the
parent model. Traversing the storage made the access to an attribute inconsistent.

The new solution enables encapsulating the attributes disregarding the way they
were retrieved.

ARIA-64 Remove PyYAML dependency

ARIA-180 Separate Parameter models and change relationships

First, the Parameter model was separated in 6 individual models:
Input, Output, Property, Attribute, Configuration, Argument.

The first four models are TOSCA-related, and we needed to separate them
as according to the TOSCA spec, all four of these represent different
things, and have different fields.

The other two models (Configuration, Argument) are
orchestration-related, as and such are not supposed to represent the
same object as the TOSCA-related objects.

Second, up until now, the relationships of the then-Parameter models
were many-to-many to any other object related to them. This was a problem,
as logically the relationships were one-to-many (from the other models
to the Parameter models).
In this commit, we changed them to one-to-many. In addition, separating
the Parameter models allowed us to more accurately represent the relationship of each individual Parameter-model with its related models.

ARIA-149 Enhance operation configuration

* Also fixes ARIA-121, ARIA-190
* Parse special "dependencies" configuration parameters as YAML and
  treat as Parameter models, allowing them full use of intrinsic
  functions, type coersions, and validations
* Rename various functions that process "properties" to more generically
  process "parameters" (properties, inputs, attributes, arguments, etc.)
* The "configuration" field in OperationTemplate and Operation models
  is now now a dict of Parameter models
* Add "function" and "arguments" fields to Operation model to preserve
  user data (in "implementation" and "inputs") and to clearly demarcate
  orchestration data from user data; update task API accordingly
* Some cleanup of parser code touched by this commit
* Rename "create_parameters" to "merge_parameter_values" and improve

ARIA-268 Add NOTICE file

ARIA-261 Single-source ARIA version

ARIA-258 Convert runtime_properties to attributes

NullPool logging messages appear during execution

ARIA-162 Upgrade Colorama library version

Upgraded the Colorama library version - This should
take care of the closed-stream error that appeared
sporadically after test runs.

ARIA-208 Fix models relationships

ARIA-259 Updated README install section for ArchLinux

ARIA-171 service_template.services type inconsistency

As opposed to service_template.node_templates and service.nodes
which have a dict interface, service_template.services
had a list interface. That seemed inconsistent, so the former
interface was changed to a dict interface as well.

ARIA-148 Enhance CLI show commands

* Allow "--full" flag to provide a complete dump
* Allow "--json" and "--yaml" flags for dump in those formats
* Support for node graph and type hierarchies
* Some fixes for YAML dump for our custom types
* Also closes ARIA-186: "aria services show" command

ARIA-139 Support attributes

* Fully implement attribute support in parser
* New intrinsic function evaluation mechanism
* Implemented more intrinsic functions, including get_attribute
* Fix to one-on-one relationship back population
* Fixes to TOSCA use case examples
* Indirectly related: re-enabled node_filter mechanism and reworked
filter constraints in order to make them serializable
* utils/type is much more robust now and consolidates all conversions
and names
* Moved dsl_specification to new utils/specification (because utils/type
uses it)

ARIA-213 Sporadic tests failures over locked database issue

Move from 2 different sessions - one for the log, and the other for general model operations,
to one single session, while utilizing the keep tracking of changes mechanism for both logs and node/task states.

ARIA-157 Failing CLI service-templates store tests on Windows

Three tests from `aria service-templates store` failed on Windows, but
not on Linux.

The reason for this failures was differing implementation of
os.path.dirname across the platforms.

Python implements os.path.dirname in the ntpath module. There, somewhere
down the line of calls, (a part of) the argument of dirname is tested
for membership in a string (using `in`). In these three tests, the
argument of dirname is of type MagicMock, and an error is raised since
only a string can be tested for membership in a string.

The solution was to mock the dirname calls.

ARIA-62 Apply pylint on extensions

ARIA-140 Version utils

Provided mainly to support version comparisons for plugins in order to
select the highest version of available plugins that would match a
plugin specification. In the future may be useful for other version
comparisons.

ARIA-210 Handle relative paths in CLI service-templates

This was a rather simple change, mainly involving adding absolute path
references.

The problems were only in `service-templates store` and in
`service-templates create-archive`.
`service-templates validate` was not affected.

ARIA-160 Tests fail spordically over parameter binding

ARIA-165 Make node name suffix UUIDs become more readable

ARIA-230 Dry execution doesn't log empty operations

ARIA-214 Dry execution changes the state of non implemented operations

ARIA-215 Refactor plugin-related code into PluginManager

Refactored plugin-related code from ProcessExecutor into PluginManager.
Additionally, renamed plugin_prefix to plugin_dir in PluginManager.

ARIA-160 Operation toolbelt unit tests fail spordically

Inroduced a filesystem based data holder

ARIA-156 Better handle exceptions in the process executor

Previously, if an exception was raised during the starting of a task,
the task's process was permanently blocked on receiving a message.

The reason was that the exception caused the 'listener thread' to
not send a response to the task's process, as the exception was not
handled inside the 'with' block of the listener thread.

The first change I introduced was to wrap the yielding of the message and
the response inside a try-except-finally block, so the exception will be
handled within the 'with' scope, and to ensure a response is sent to the
task's process.

The second change is to move the sending of the 'task started' message in
the task's process to a place where encountering an exception will be
handled via sending a 'task failed' message back to the listener thread.

ARIA-209 Fix create-archive CLI command help

ARIA-163 Update node state for empty tasks

Additional changes:
 * removed `for_node` and `for_relationship` from the api OperationTask.
 * api based OperationTask could also have an empty implementation.
 * each core task wields its own executor.
 * Reordered some of the helper functions for creating tasks.
 * intoduced 2 new executors: StubTaskExecutor (for stub tasks) and EmptyOperationExecutor (for empty tasks)

ARIA-161 Disable end2end tests on Windows

ARIA-155 Clean models from unused fields

ARIA-158 Restore support for relationship ordering

ARIA-146 Support colorful execution logging

ARIA-154 Create end-to-end test for the Nodecellar example

ARIA-153 Write end-to-end tests for ARIA

Created infrastructure for end-to-end tests,
plus a test for the hello-world example.

Improve execution cancelling

Unhandled execution status transitions resulting from cancelling an
execution via the CLI, that we indentified and tried to address:

1. TERMINATED -> CANCELLING
You cancel the execution, but by the time we try to set the status to
CANCELLING, the execution thread had already finished, and therefore,
in SUCCEEDED status.

2. FAILED -> CANCELLING
You cancel the execution, but by the time we try to set the status to
CANCELLING, the execution thread had already encountered an error,
and therefore, in FAILED state.

3. TERMINATED -> CANCELLED
Similar to #1, but with CANCELLED instead of CANCELLING.

4. FAILED -> CANCELLED
Similar to #1, but with CANCELLED instead of CANCELLING.

In all of the above cases (#1-#4), we skip updating the execution
status, and log that the execution already succeeded/failed before we
were able to cancel it.

5. CANCELLING -> STARTED
You cancel the execution while it is still in pending state. Meanwhile,
while the execution status was already set to CANCELLING, we try to set
the execution status

6. CANCELLED -> STARTED
Similar to #5, but after the status is set to CANCELLING, it also gets
set to CANCELLED before attempting to set it to STARTED.

In cases #5-#6, we skip updtating the execution status, and nothing
is logged.

ARIA-150 Fixed simple hello-world example

The simple hello-world example had a missing host node,
which caused an error at service creation phase.
The example now uses custom types which do not require
the extra host node.

ARIA-138-Make-logging-more-informative

ARIA-145 deploying CLI config file at installation

ARIA-142-defaults-missing-for-execution-plugin

ARIA-48 Revamped ARIA CLI

This is a large commit which revolves mostly around creating the
new CLI, but is also tying ARIA's various components together
for real for the first time - allowing a complete run of the
"hello-world" example and more.

This commit introduces a few other important modules:
 - aria/core.py - used for managing service-templates and services.
 - aria/orchestator/workflow_runner.py - used for managing
   a workflow execution on a service.
 - aria/orchestrator/dry.py - a "dry executor", used for
   dry-executing workflows and printing the tasks that would run.

Other fixes that were required for the successful usage of
ARIA end-to-end have also been introduced in this commit, but
there have been too many to list; Review the commit for more info.

ARIA-92 Automatic operation task configuration

ARIA-127 Make use of in-memory sqlite more robust

ARIA-128 Make test_engine more robust

ARIA-134 Parser populates service workflows

ARIA-137-Support-for-predicate-based-queries-in-the-SQL-mapi

ARIA-132-fixed-support-for-cascading-deletion

ARIA-136-ctx-binary-doesnt-get-installed-via-pip-install

ARIA-125-Filtering-returns-the-wrong-models

ARIA-86-Create-a-basic-Hello-World-blueprint-example

ARIA-135-Add-plugin-field-to-MockTask

ARIA-133 Add status-related properties to the Execution, Task and Node models

We are adding these properties so it will be easier to filter those models
from storage according to their status, and to not make use of the their
`status` constants outside of the models themselves.

It should be noted, since we currently have the concept of `StubTasks`
(that are not part of the model), we had to implement the same logic for
them, although they don't direct access to the state constants of the
task model. We did this since they are treated as 'regular' model tasks
in some parts of the code.

ARIA-132-Models-cascading-deletion-raises-constraint-errors

Additional fixes:
- The relationships are now defined on both sides. we no longer use backref, but back_populates.

ARIA-120-Builtin-workflows-relationship-operations-execution-order

ARIA-126 Add node states

1. The states are described in section 3.3.1 of the TOSCA spec.

2. The state is changed if a standard lifecycle operation runs of the
node, as described in sections 5.7.4.1, 5.7.4.4.1, and 5.7.4.4.2 of the TOSCA spec.

3. We did not address the 'error' state yet.
This state is defined as part of the possible node states in the model, but currently no execution path leads to setting a node's state to 'error'.

4. No validation of state transiontions.
For example, we do not validate if a node goes from 'created'
to 'started' without going through the 'configured' state in between.

ARIA-83 Support ARIA profile for TOSCA

ARIA-131-Make-demand-for-networkx-more-strict

ARIA-96 Improve our requirements handling

1. Currently, don't vendor any library.

2. Use pip-tools (specifically, pip-compile) to manage our dependencies
   requirement files.

3. requirements.in:
   The requirements.in will be read into `install_requires`, and includes
   loose dependencies (as possible, and only direct dependencies), as is
   common when installing using a setup.py file.
   Since we haven't tested ARIA with many versions of our dependencies, our
   dependencies are not very loose, but we are hoping to improve this as
   our project matures.
   Currently, when we provide an upper bound, it is either because of python
   2.6 compatibility, or according to a semantic versioning (i.e. future
   versions that could break the current API). Lower boundaries are
   usually the lowest version that we tested with ARIA, or because version
   before are lacking functionality we are using.

4. requirements.txt:
   The requirements.txt is generated from requirements.in via pip-compile,
   and includes fixed-version dependencies, including all transitive
   dependencies, in order to provide an stable environment that ARIA is
   ensured to work on.

ARIA-130-Passing-inputs-from-the-workflow-to-the-operation-changes-the-inputs

ARIA-105 Integrate parser and orchestrator models

ARIA-117-Log-model-should-have-an-Task-field

ARIA-115-Log-model-should-have-an-Execution-field

ARIA-116-Missing-type_hierarchy-in-relationship

ARIA-106-Create-sqla-logging-handler

ARIA-108 Add API for deleting a resource for resource storage

ARIA-79-concurrent-modifications

ARIA-88 Add TOSCA use-case examples

ARIA-44 Merge parser and storage model

Additional Changes:
  * As a part of this task the name to address the model has been changes to the __tablename__ (or __mapiname__ if specified)
  * All of the relationships return a query, so accessing the entire list should be done via all()

ARIA-42-Generic-ctx-serialization-mechanism

ARIA-99 Straightforward end-to-end tests for parser and built-in workflow

ARIA-98 Updated two dependencies to support a range of versions

ARIA-95-pip-wheel-for-aria-ignores-dependencies

ARIA-81-Install-execution-plugin-ctx-entry-point-by-default

ARIA-66-Convert-custom-parser-fields-into-sqla-based-fields

ARIA-61 Initial version of CLI "workflow" command

ARIA-36 plugin workdir

ARIA-73 Transfer parser's TOSCA model to storage

ARIA-12 New "Runner" class for simple workflow executions

ARIA-68 Update runtime properties during operation

ARIA-72 Rework built-in workflows to match TOSCA normative lifecycle

ARIA-74 Add process executor extension registration hooks

ARIA-70 fix task plugin_name

ARIA-65 Add validation for relationship assignment type

ARIA-46 Execution plugin

ARIA-63 Implement attribute tracking for subprocesses

ARIA-60 Fix use of thread locals in parser context

ARIA-59 Inherit default interfaces in relationships

ARIA-52-Support-order-management-in-relationships

ARIA-56 Implement ip property on node instance model

ARIA-34 Adding get/download resource and render API (as jinja template)

ARIA-55 Implement task retry and abort mechanism

ARIA-58-Storage-model-to_dict-creates-symbolic-links

As part of this commits, ARIA will use the builtin MutableDict and List

ARIA-57-Custom executions state transition support

As part of this commit, a new valid transition was added between  cancelling
and force cancelling

ARIA-53 Add badges to README file

ARIA-39-Genericize-storage-models

ARIA-41 Provide (initial) means for serializing an operation context object

ARIA-26 Implement operation plugin mechanism

ARIA-31 Add registry mechanism for extensions