Additional flexibility when identifying storage pools in Storage Class definition

[acsulli]

Storage pool selection is currently limited to statically specifying the pools desired using either the storagePools or additionalStoragePools attributes in the storage class definition. To enable greater flexibility, having a number of other selection (or exclusion) criteria would be ideal:

• Specify all pools from a backend. For example, using an asterisks or simply leaving the list empty:

   parameters:
     storagePools: "<backend_name>:*"
  

• Exclude specific pools (and/or backends when used with the above item).

  parameters:
    storagePools: "<backend_name>:*;<backend2_name>:*"
    excludeStoragePools: "<backend_name>:aggr1,aggr2;<backend2_name>:aluminum"
  

• Prioritize pool selection based on an arbitrary order. Particularly when used in conjunction with The ontap drivers should have more intelligent volume placement #64.
• Specify a naming pattern for the pool(s) to be included or excluded.

  parameters:
    storagePools: "<backend_name>:*bronze*;<backend2_name>:*copper*"
  

• Use a selector pattern for backends. When used in conjunction with the backendType this makes it easy to select common pools, e.g. SolidFire QoS policies.

  backendType: "solidfire-san"
  parameters:
    storagePools: "*:bismuth"
  

• And, combining the two together: using a pattern to select both the backend and the storage pool.

  media: "ssd"
  parameters:
    storagePools: "sf1|sf2:*unobtanium*;aff*:*"
  

  This would also be improved by Assign QoS policies to ONTAP volumes provisioned by Trident #108, allowing same/similar performance expectations across platforms.

Andrew

[pmeyer34]

+1

[kangarlou]

Closed per b161ca4.