feat(storage): extend application schema for storage flag

[anvial]

Description

This PR introduces significant enhancements to our Terraform provider for Juju. The main changes include extending of the application schema to support the storage flag in the Terraform provider for Juju.

The schema now includes various attributes for configuring the storage constraints of a Juju application.

Fixes:

Type of change

• Change existing resource

Environment

• Juju controller version: -

• Terraform version: -

Plan example

terraform {
  required_providers {
    juju = {
      source  = "juju/juju"
      version = "0.12.0"
    }
  }
}
provider "juju" {}

resource "juju_model" "storage-model" {
  name = "storage-model"
}

resource "juju_application" "postgresql" {
  name  = "postgresql"
  model = juju_model.storage-model.name

  charm {
    name     = "postgresql"
    channel  = "latest/stable"
  }

  storage = [
    {
      pool  = "lxd"
      label = "pgdata"
      size  = "8M"
      count = 1
    }
  ]

  units = 1
}
...

[Aflynn50]

Is it possible to do CRUD operations on all the storage parameters? If not would we have to use a data source instead?

[Aflynn50]

From reading the storage constraints docs, it seems to me that size is not required. From what I can tell you can choose to leave out any of size, pool and count.

I guess it would technically be fine if the user left out all three, it should just have no effect.

[anvial]

Hm, and where we said that this is optional...

Knowing that we do not support dynamic size volumes, I wonder how the "size" could be optional.

[hmlanigan]

Find the default that juju uses and make that the default. Then the attribute can be optional.

Default: stringdefault.StaticString("str"),

I'm not sure if setting a default in the schema is possible or not. Charm metadata can optionally define a MinimumSize for storage:

	// There is no default MinimumSize; if left unspecified, a provider
	// specific default will be used, typically 1GB for block storage.

[Aflynn50]

Here is the doc I was looking at https://juju.is/docs/juju/storage-constraint

[cderici]

Couple of comments and a suggestion:

• I'm not sure if I understand what label is for, and why it is required? also the name "label" might get confused with the label for block devices in the context of storages.
• why is the size required?
• it might be a good idea to have some validation in the schema with a ValidateConfig (example here) against small stuff (like size being positive, or count defaults to 1 if size is specified, etc) (format here).

Also it would great if you can provide an example resource_application in the PR description that includes the use of this storage SetNestedAttribute so it would be clear what it'll look like.

[anvial]

Couple of comments and a suggestion:

• I'm not sure if I understand what label is for, and why it is required? also the name "label" might get confused with the label for block devices in the context of storages.

Here we mimic under StorageContraints defined in storage.go (in Juju):

// StorageConstraints contains the user-specified constraints for provisioning
// storage instances for an application unit.
type StorageConstraints struct {
	// Pool is the name of the storage pool from which to provision the
	// storage instances.
	Pool string `bson:"pool"`

	// Size is the required size of the storage instances, in MiB.
	Size uint64 `bson:"size"`

	// Count is the required number of storage instances.
	Count uint64 `bson:"count"`
}

where label is "middle part" of storage-tag: storage-<storage-label>-NUM

• why is the size required?

In Juju, we have a policy that "storage constraints require at least one field to be specified." However, this is difficult to provide in the declarative nature of TF. So, as a solution to be more strict about size.

• it might be a good idea to have some validation in the schema with a ValidateConfig (example here) against small stuff (like size being positive, or count defaults to 1 if size is specified, etc) (format here).

thx I'll have a look

Also it would great if you can provide an example resource_application in the PR description that includes the use of this storage SetNestedAttribute so it would be clear what it'll look like.

I'll add example in the description.

[hmlanigan]

Find the default that juju uses and make that the default. Then the attribute can be optional.

Default: stringdefault.StaticString("str"),

I'm not sure if setting a default in the schema is possible or not. Charm metadata can optionally define a MinimumSize for storage:

	// There is no default MinimumSize; if left unspecified, a provider
	// specific default will be used, typically 1GB for block storage.

[hmlanigan]

On reflection, we may want to make these plan modifiers on each attribute, rather than on the object themselves. I need to understand the difference better.

Our goal is to mimic the behavior of juju deploy --storage and juju refresh --storage.

Scenarios to consider

1. A new application resource with storage is created -> the application is deployed with storage.
2. Storage attribute is added to an existing application resource without a new charm revision to refresh to. -> We should fail ?? Or recreate the application?
3. Storage attribute is added to an existing application resource WITH a new charm revision to refresh to. -> Refresh the charm and add the storage.
4. An existing storage attribute is removed from the plan -> recreate the application without the storage.

[hmlanigan]

@Aflynn50 :

Is it possible to do CRUD operations on all the storage parameters? If not would we have to use a data source instead?

A resource or data source for storage is beyond the scope of the current storage project. The goal is to provide the functionality of juju deploy --storage and juju refresh --storage only.

We need to enhance the documentation to be clear on this point.

[hmlanigan]

Approved once the two items have been addressed.