Tal Liron created ARIA-346:
------------------------------
Summary: Policy-based approach for multi-cloud-platform support
Key: ARIA-346
URL: https://issues.apache.org/jira/browse/ARIA-346
Project: AriaTosca
Issue Type: Story
Reporter: Tal Liron
Let's start with a Proof-of-Concept before creating a PR to merge into ARIA.
The problem is this: it's currently hard to move a service template from one
cloud infrastructure to another, e.g. from AWS to Cloudstack, let alone to
container-based solutions like Docker and Kubernetes. The main reason is that
all of our current solutions are based on inheriting new node types from
{{tosca.nodes.Compute}}, and these have very different properties that map
quite directly to the platform APIs. The same problem exists is for block
storage nodes, networking, and security groups.
There are several problems with this approach:
1) This means that you can't just take the same service template and install it
on both AWS and Openstack. You need to create a new template. Over time it
means maintaining several versions of the same template.
2) By inheriting Compute, we are making it difficult for service template
writers to create their own Compute sub-types. Because there's no multiple
inheritance in TOSCA, they would have to derive their types from the correct
platform types, again making it harder to maintain multiple versions.
3) Our approach ignores TOSCA 1.0's solutions: the capability types
{{tosca.capabilities.Container}} and {{tosca.capabilities.OperatingSystem}}.
These are admittedly generic, limited, and inflexible (based on explicit
properties) but they are still part of TOSCA.
My idea is to try to solve this without inheriting from Compute and while using
the existing capability types. How would this be done? By filling in the
missing data in a policy rather than a new node type. The plugin would take
into account the capabilities as they are.
For example, here's how we currently do an AWS VM node template:
{code}
toplogy_template:
node_templates:
my_vm:
type: aria.aws.nodes.Instance
properties:
image_id: { get_input: image_id }
instance_type: { get_input: instance_type }
name: aria-aws-hello-world-instance
parameters:
key_name: { get_attribute: [ keypair, aws_resource_id ] }
{code}
What I suggest instead is something like this:
{code}
toplogy_template:
node_templates:
my_vm:
type: tosca.nodes.Compute
capabilities:
os:
properties:
architecture: x86_64
type: linux
distribution: ubuntu
version: 14.04
host:
properties:
mem_size: 4 GB
policies:
vm:
type: aws.VM
targets: my_vm
properties:
key_name: { get_attribute: [ keypair, aws_resource_id ] }
image_ids:
- id: 123456789
architecture: x86_64
type: linux
distribution: ubuntu
version: 14.04
- id: 121232354325
architecture: i686
type: linux
distribution: ubuntu
version: 14.04
...
{code}
In this case there is an explicit mapping of image IDs to the capability
properties. Of course the basic aws.VM type could already have sensible
defaults, making it easier to use.
As stated, we can start with a PoC for this and see where to go from there.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
