Closed aszs closed 2 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
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
andos
capabilities set on the Compute node template.Consider this example from the TOSCA spec:
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). Alsodisk_size
is separate from machine type, that properties should be used to set the boot disk size in the implementation's terraform HCL.