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 = ...

@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.