search

onecommons / unfurl-examples

1 stars 1 forks source link

Map to tosca.nodes.Compute properties to the example GCP and AWS implementations #1

Closed aszs closed 2 years ago

aszs commented 3 years ago

This repository to contains two implementations of TOSCA 1.3's 5.9.3 tosca.nodes.Compute for AWS and GCP, here: https://github.com/onecommons/unfurl-examples/blob/main/cloud/aws/compute.yaml and here: https://github.com/onecommons/unfurl-examples/blob/main/cloud/gcp/compute.yaml

Currently these examples just hardcode the machine type and require the provider specific boot image property be set. Instead they should have defaults that set those values based on the host and os capabilities set on the Compute node template.

Consider this example from the TOSCA spec:

  db_server:
     type: tosca.nodes.Compute
     capabilities:
        # Host container properties
        host:
           properties:
             num_cpus: 1
             disk_size: 10 GB
            mem_size: 4096 MB
       # Guest Operating System properties
      os:
        properties:
          # host Operating System image properties
          architecture: x86_64
          type: linux 
          distribution: rhel 
          version: 6.5

For the boot image It could deduce that by having a dependency on a BootImage node that queries with GCP or AWS with the os properties (there is already similar examples in the above templates.).

It is more unclear how to choose the best machine type from the host properties. Those could be statically determined from a table of machine types with their attributes for each cloud provider and with luck someone has already done that work in a library somewhere? And an error should occur if the properties specify a machine that can't be fulfilled (e.g. too much memory). Also disk_size is separate from machine type, that properties should be used to set the boot disk size in the implementation's terraform HCL.

aszs commented 3 years ago

Because the logic to figure out the best machine type is mostly likely complicated it might be best to put that in a python code. We can do that by using the experimental (and undocumented) "decorators" TOSCA extension I added recently. The best place to see how it works is tests/test_overlay.py -- but this implementation would probably end up looking something like:

decorators:
 unfurl.nodes.ComputeAbstract:
   properties:
      machine_type:
        eval:
           python: helpers.py#chooseMachineType

where chooseMachineType() would look something like:

 def chooseMachineType(ctx):
    props = ctx.currentResource.capabilities['host'].properties
    return machine_type # figure out from props