Additional storage account properties

It would be great to have some more common attributes on storage accounts, such as, ‘tier’, ‘kind’, and ‘properties’. Also Management polices for blob lifecycle management would be great (moved to #312)

// Create a storage account with a container
let myStorageAccount = storageAccount {
    name storageName
    sku Storage.Premium_LRS
    // tier Premium
    // kind "BlockBlobStorage"
    //   "properties": {
    //     "supportsHttpsTrafficOnly": true,
    //     "accessTier": "Hot"
    //   },
    // managementPolicies
}

[isaacabraham]

@BrianVallelunga @onionhammer @tehmufifnman OK. So having read through the docs, this is what I see the reality of the situation in terms of relationship between SKU and Kind:

type Sku = Standard_LRS | Standard_GRS | Standard_RAGRS | Standard_ZRS | Standard_GZRS | Standard_RAGZRS | Premium_LRS | Premium_ZRS
type BlobStorageSku = Standard_LRS | Standard_GRS | Standard_RAGRS
type StorageAccountKind =
    | StorageV1 of Sku
    | StorageV2 of Sku
    | BlobStorage of BlobStorageSku
    | FileStorage
    | BlockBlobStorage

FileStorage and BlockBlobStorage don’t need any options because they only support Premium_LRS anyway, so when we emit to ARM we can hard-code that into the emitter.

Does this all make sure? If so, I can push through a beta release next week for you to test out.

The main Storage Account builder won’t change - we’ll keep that “locked” to StorageV2 - but you’ll be able to manually create StorageV1 resources etc. as needed.

For VMs and Functions, thinking about this, I don’t really want to change that behaviour now as this would be a breaking change at the ARM level (which I’m concerned about) - but we could potentially add that as an option in the future (or in the next major release change it up).

[onionhammer]

Sounds great as long as I can specify kind of “BlockBlobStorage” and tier of “Premium”!