Tosca

location.yaml

    aws-instance:
      type: seaclouds.Nodes.Compute
      properties:
        location-configuration:
          hardwareId: d2.2xlarge
          location: "aws:ec2"
          region: "us-west-1"
          credentials: “user/pwd, token, whatever”
          aws-ec2.identity = ...
          aws-ec2.credential = ...

mostly okay. for simplicity i suggest more closely following the brooklyn pattern, e.g. in TOSCA we would say

type: org.apache.brooklyn.tosca.location.JcloudsLocation
properties:
  provider: aws-ec2
  region: us-west-1
  hardwareId: ...

another piece to consider is how this is used.

• it could be a subtype derived_from tosca.nodes.Compute. if we do this, then, in the usual TOSCA way, every software process would explicitly declare that it is hosted_on org.apache.brooklyn.tosca.location.JcloudsLocation. unfortunately if we follow this approach, a challenge arises when we try to run stock TOSCA blueprints which talk about hosted_on tosca.nodes.Compute. there is no information in the t.n.Compute item to specify what type of cloud it should run on, so it means we would have to do major changes all the stock TOSCA examples, specifying o.a.b.t.l.JcloudsLocation instead of t.n.Compute throughout. thus we lose the ability to have portable plans.
• we could instead think of org.apache.brooklyn.tosca.location.JcloudsLocation as a machine-provider aka cloud, rather than as a machine spec (which is basically what Compute does currently). and any time Brooklyn is asked to create a t.n.Compute, it walks up the containment topology looking for a running_in_location L relationship, and treating L as a machine-provider which it uses to instantiate t.n.Compute. this would allow us to use any plan, ensuring portability, simply by referring to the plan and adding an additional requirement:

      node_templates:
        my-app:
          type: ... # a tosca example, using t.n.Compute but not specifying a cloud
          requirements:
            cloud_endpoint:
              id: aws
              relationship: running_in_location
        aws:
          type: org.apache.brooklyn.tosca.location.JcloudsLocation
          properties:
            provider: aws-ec2
            region: us-west-1
            identity: ...
            credential: ...
            hardwareId: ...

• finally another option, which is used at present in brooklyn-tosca and by others, is to expect policies to tell us how t.n.Compute should be instantiated; this gives us portability, but (to me at least) it feels slightly awkward, that we have to drag in policies simply to provide this type of essential configuration information (i mean, you could use policies to do anything, including specifying the amount of RAM to use or the fact that a DB should be provisioned; it is an open question when should you use policies, but i think there the answer is for when there is smarts that you want to apply, such as how to pick a target environment, or when to scale; and simply saying "deploy to AWS" doesn't qualify as smarts)

all the above options are compatible so we could support all of them; we already support the latter, and i believe o.a.b.t.l.JcloudsLocation can be derived_from both t.n.Compute (to support the first option) and some kind of seaclouds.nodes.Cloud (which could be used to support the second option).

@ahgittin Thanks for your reply.

I proposed this approach following the same goal that you have described on your first point, however as you have mentioned, we will lost portability.
Your second point is very interesting too, it could be more portable.

In any case, I proposed encapsulate the location configuration properties in a single property map. I think it is important to avoid define a NodeType for each provider or a big NodeType (Jclouds configkeys, PaasLocation...). For example, AWS requires a set of properties such as region, user, loginUser, etc. If we add these properties directly to org.apache.brooklyn.tosca.location.JcloudsLocation NodeType properties declaration,

node_types:
  org.apache.brooklyn.tosca.location.JcloudsLocation:
      derived_from: tosca.nodes.Root
      description: >
        Location description
      properties:
        region:
          type: string
          required: false
        user:
          type: string
          required: false

we will find a problem when we will use a different provider which requires different properties. For example, HP will require a different set of properties, such as selinux.disabled, jclouds.openstack-nova.auto-create-floating-ips, jclouds.openstack-nova.auto-generate-keypairs, etc. But these properties are not supported by o.a.b.t.l.JcloudsLocation because they were not defined from NodeType definition. In this case we should define a new NodeType for HP provider which contains the expected properties.

Then, I proposed to use a map for containing all location properties, so any provider's property could be described using this NodeType. The following NodeType should allow to describe any location provider because the provider's properties will be added to the location-configuration map. Please, note that it is only a first NodeType definition

node_types:
  org.apache.brooklyn.tosca.location.JcloudsLocation:
      derived_from: tosca.nodes.Compute
       #derived_from could be tosca.nodes.Root using the second Alex' solution
      description: >
        Location description
      properties:
        location-configuration:
          type: map
          required: false
          entry_schema:
            - type: string

For example, we could define the properties for AWS and HP using the same NodeTemplate.

my-app:
  type: tosca.nodes.SoftwareComponent
  # this template could be added hosted on aws or hp using any solution proposed by Alex
  #for example for first Alex's solution
  requirements:
  - host: aws/hp

aws:
  type: org.apache.brooklyn.tosca.location.JcloudsLocation
  properties:
    location-configuration:
      provider: aws-ec2
      region: us-west-1
      identity: ...
      credential: ...
      hardwareId: ...

hp:
  type: org.apache.brooklyn.tosca.location.JcloudsLocation
  properties:
    location-configuration:
      provider: hp-cloud
      region: region-b.geo-1
      jclouds.openstack-nova.auto-create-floating-ips: true
      openstack-nova.auto-generate-keypairs: true
     securityGroups: universal

does it make sense?
Of course a set of common properties could be fixed on top level properties, for example provider, region, loginUser (all brooklyn.location.jclouds.JcloudsLocation) could be defined directly as o.a.b.t.l.JcloudsLocation's properties.

Open Issues

• Moreover, we should take in account the PaasLocations that use a different set of properties, so probably we should use a generic Location NodeType (e.g. org.apache.brooklyn.tosca.location.Location).

About, what solution should be support I also think that all of them may be supported easily.