[jira] [Created] (ARIA-346) Policy-based approach for multi-cloud-platform support

["Tal Liron (JIRA)" <ji...@apache.org>]

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)