Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
aszs opened this issue Mar 2, 2021 · 1 comment
Assignees

Comments

@aszs
Copy link
Member

aszs commented Mar 2, 2021

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
Copy link
Member Author

aszs commented Mar 6, 2021

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 

jozo added a commit that referenced this issue Jun 3, 2021
jozo added a commit that referenced this issue Jun 4, 2021
jozo added a commit that referenced this issue Jun 4, 2021
jozo added a commit that referenced this issue Jun 4, 2021
jozo added a commit that referenced this issue Jun 9, 2021
aszs added a commit that referenced this issue Jun 9, 2021
jozo added a commit that referenced this issue Jun 14, 2021
jozo added a commit that referenced this issue Jun 14, 2021
aszs added a commit that referenced this issue Jun 14, 2021
#1 - Fix output attributes of GCP
jozo added a commit that referenced this issue Jun 16, 2021
jozo added a commit that referenced this issue Jun 16, 2021
jozo added a commit that referenced this issue Jul 7, 2021
@aszs aszs closed this as completed in b0d43c0 Sep 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants