Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Enhancement]: Add SVM QoS Policy Activation #346

Open
wants to merge 5 commits into
base: integration/main
Choose a base branch
from

Conversation

acch
Copy link

@acch acch commented Dec 3, 2024

Adds ability to configure qos_policy parameter of SVMs.

Needs to be a dedicated resource, as creating a QoS Policy scoped to an SVM, and then activating it for the SVM, is a 2-step process. See documentation for details.

Closes #301.

Acceptance tests WIP:

$ TF_ACC=1 go test ./internal/provider/svm/svm_qos_policy_activation_resource_test.go -v
=== RUN   TestAccSvmQosPolicyActivationResource
--- PASS: TestAccSvmQosPolicyActivationResource (2.96s)
PASS
ok      command-line-arguments  2.967s

Example Terraform Configuration WIP:

resource "netapp-ontap_svm_qos_policy_activation" "example" { 
  svm = {
    name = "svm01"
  }
  qos_policy = {
    name = "performance_svm01"
  }
}

@acch acch force-pushed the 301-svm-qos-policy-activation branch from ae7e93e to 8c5e7f1 Compare December 9, 2024 13:35
@acch acch marked this pull request as ready for review December 9, 2024 13:42
@acch acch changed the title Add SVM QoS Policy Activation [Enhancement]: Add SVM QoS Policy Activation Dec 9, 2024
@carchi8py carchi8py added the enhancement New feature or request label Dec 9, 2024
@carchi8py carchi8py added this to the 2.1 milestone Dec 9, 2024
@carchi8py carchi8py added New Resource New Request for an ONTAP Resource and removed enhancement New feature or request labels Jan 6, 2025
Copy link
Contributor

@carchi8py carchi8py left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So do you expect users to ever pass in the UUID vs name?

When we wrote the Ansible/Terraform modules/resource, we've already assume users would always use name, and we would treat UUID as more of a internal thing. As a user is having both name and UUID useful?

Optional: true,
Computed: true,
},
"id": schema.StringAttribute{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We try to use name all the time, as UUID is not something user friendly, and name itself can handle all functionality, so we have used name in all our Ansible/Terrafrom modules/resources. Unless you have an explicit case, let us know

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
New Resource New Request for an ONTAP Resource
Projects
Status: 2.1
Development

Successfully merging this pull request may close these issues.

[New Resource]: SVM QoS Policy Activation
3 participants