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

Add support for user configured state object names in swift containers #17465

Merged
merged 1 commit into from
Jul 10, 2019
Merged

Add support for user configured state object names in swift containers #17465

merged 1 commit into from
Jul 10, 2019

Conversation

Elethiomel
Copy link
Contributor

Currently in the swift backend, the object state name is hardcoded to "tfstate.tf". This PR makes that configurable via a "state_name" option. The option is optional and defaults to "tfstate.tf". This puts the backend more in line with the S3 backend and will allow users to have one container with multiple states.

I'm not 100% happy with the option name. I'd prefer to use "key" or something similar, but the backend already uses that internally for the Openstack key and I didn't want to have the option and internal struct members named differently. Any suggestions?

I, of course still need to update the documentation and test it a bit more, so this is very much a WIP.

@Elethiomel Elethiomel changed the title [WIP] Add support for user configured state object names in swift containers Add support for user configured state object names in swift containers Apr 12, 2018
@Elethiomel
Copy link
Contributor Author

I've now updated the documentation. I think this is ready for someone else to take a look at now :)

Type: schema.TypeString,
Optional: true,
Description: descriptions["state_name"],
},
Copy link
Contributor

Choose a reason for hiding this comment

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

Could you set a default value in here with the original value?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hi Paul, I actually set a default on lines 289 to 293 in keeping with the style of previous code on lines 283 to 286. Is it OK to do it that way?

Copy link
Contributor

Choose a reason for hiding this comment

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

You should set the value here, the difference is that if someone then explicitly writes tfstate.tf as a value I believe it will create a diff, although this is a backend so doesn't have the same implications as a provider. But we should use it consistently.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point, I've made the change and tested it internally. Looks good :)

@@ -19,14 +19,13 @@ Stores the state as an artifact in [Swift](http://docs.openstack.org/developer/s
```hcl
terraform {
backend "swift" {
path = "terraform-state"
path = "terraform-state",
state_name = "terraform.tfstate"
}
}
```
This will create a container called `terraform-state` and an object within that container called `tfstate.tf`.
Copy link
Contributor

Choose a reason for hiding this comment

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

Need to update this line here as well since you changed the example.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Well spotted! I've made a commit to fix the discrepancies. Basically, the old code was hardwired to use "tfstate.tf". Unfortunately, the documentation referred to "terraform.tfstate" in many places. The new commit fixes the docs to reflect the reality that the state has always been "tfstate.tf"

@@ -54,6 +53,9 @@ The following configuration options are supported:
* `path` - (Optional) DEPRECATED: Use `container` instead.
The name of the container to create in order to store the state file.

* `state_name` - (Optional) The path to state file in the container.
Defaults to `terraform.tfstate`.
Copy link
Contributor

Choose a reason for hiding this comment

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

Defaults to tfstate.tf

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed :)

Copy link
Contributor Author

@Elethiomel Elethiomel left a comment

Choose a reason for hiding this comment

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

Thanks for the review Paul. I think I'm ready for another round please :)

Copy link
Contributor

@paultyng paultyng left a comment

Choose a reason for hiding this comment

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

Sorry for the delay here, a couple minor fixes and we are good I think.

Type: schema.TypeString,
Optional: true,
Description: descriptions["state_name"],
},
Copy link
Contributor

Choose a reason for hiding this comment

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

You should set the value here, the difference is that if someone then explicitly writes tfstate.tf as a value I believe it will create a diff, although this is a backend so doesn't have the same implications as a provider. But we should use it consistently.

// RemoteClient implements the Client interface for an Openstack Swift server.
type RemoteClient struct {
client *gophercloud.ServiceClient
container string
state_name string
Copy link
Contributor

Choose a reason for hiding this comment

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

please change this to stateName: https://golang.org/doc/effective_go.html#mixed-caps

@@ -238,6 +246,7 @@ type Backend struct {
archiveContainer string
expireSecs int
container string
state_name string
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

@Elethiomel Elethiomel left a comment

Choose a reason for hiding this comment

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

I've updated state_name to stateName as suggested to keep with Go's mixedCaps style

Type: schema.TypeString,
Optional: true,
Description: descriptions["state_name"],
},
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point, I've made the change and tested it internally. Looks good :)

Copy link
Contributor

@paultyng paultyng left a comment

Choose a reason for hiding this comment

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

LGTM! Thanks again for the PR. The merging of this will probably have to wait to be rebased on the 0.12 work currently ongoing, but will be merged once the core of that work lands.

@dariakts
Copy link

Hello,

Any updates for this pull request ?

@Elethiomel
Copy link
Contributor Author

Elethiomel commented Apr 29, 2019 via email

@apparentlymart apparentlymart added this to the v0.12.1 milestone Apr 29, 2019
@pselle pselle modified the milestones: v0.12.1, TBD Jun 4, 2019
@pselle
Copy link
Contributor

pselle commented Jul 9, 2019

Hi @Elethiomel! Might I ask for an update to this PR to resolve its conflicts? Thanks so much for your patience here.

@Elethiomel
Copy link
Contributor Author

Quite a few changes have been made to the swift backend to support locking and environments, but I'll give it a go over the next week. I'm pretty swamped at work, but I would really like this PR to be accepted so I'll try me best :)

@pselle
Copy link
Contributor

pselle commented Jul 10, 2019

Great @Elethiomel! We're keeping an eye on it now, happy to review (and get this in) when you've had the chance to revisit it!

@Elethiomel Elethiomel closed this Jul 10, 2019
@Elethiomel Elethiomel reopened this Jul 10, 2019
@hashicorp-cla
Copy link

hashicorp-cla commented Jul 10, 2019

CLA assistant check
All committers have signed the CLA.

@hashicorp-cla
Copy link

CLA assistant check

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes


Colin Fowler seems not to be a GitHub user.
You need a GitHub account to be able to sign the CLA. If you already have a GitHub account, please add the email address used for this commit to your account.

Have you signed the CLA already but the status is still pending? Recheck it.

@Elethiomel
Copy link
Contributor Author

@pselle Rebased and CLA signed :)

Copy link
Contributor

@pselle pselle left a comment

Choose a reason for hiding this comment

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

Great!

@pselle pselle merged commit 9f9ac1b into hashicorp:master Jul 10, 2019
@pselle
Copy link
Contributor

pselle commented Jul 10, 2019

@Elethiomel In my enthusiasm, I missed a key step 😅 for the purposes of making sure we cover our bases, would you mind running the acceptance tests for this backend and posting the results here? This is my bad for moving too soon/not realizing to say this earlier.

Comment updated -- I've been advised by the team that this is ok in this case, but if you do feel inspired to post the results, it would be appreciated! Again, mea culpa.

@ghost
Copy link

ghost commented Aug 13, 2019

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked and limited conversation to collaborators Aug 13, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants