-
Notifications
You must be signed in to change notification settings - Fork 77
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
Config var data #109
Config var data #109
Conversation
Don't forget to update the docs. |
Steps: []resource.TestStep{ | ||
{ | ||
Config: testAccCheckHerokuAppConfigVar(appName), | ||
ExpectNonEmptyPlan: true, // todo: why do we get non-empty plans after an apply.... boo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm bummed I had to add this, and I don't know why (advice appreciated). Without this line, this test fails with:
=== RUN TestAccDatasourceHerokuAppConfigVars
--- FAIL: TestAccDatasourceHerokuAppConfigVars (11.15s)
/Users/sbabu/go/src/github.com/terraform-providers/terraform-provider-heroku/heroku/testing.go:518: Step 0 error: After applying this step and refreshing, the plan was not empty:
DIFF:
CREATE: data.heroku_app_config_vars.app_config_vars
all_config_vars.%: "" => "<computed>"
app: "" => "tftest-app-iycoxl7pzx"
UPDATE: heroku_app.app2
config_vars.0.%: "" => "<computed>"
config_vars.0.HOSTEDGRAPHITE_APIKEY: "25da0edc-c571-4664-b578-cae2b6b040e7" => ""
STATE:
heroku_addon.hostedgraphite:
ID = f7666c96-acf5-44d2-9fa5-e97e5ddac1cd
provider = provider.heroku
app = tftest-app-iycoxl7pzx
config_vars.# = 1
config_vars.0 = HOSTEDGRAPHITE_APIKEY
name = hostedgraphite-flat-54405
plan = hostedgraphite:free
provider_id = e790bfc4
Dependencies:
heroku_app.app
heroku_app.app:
ID = tftest-app-iycoxl7pzx
provider = provider.heroku
acm = false
all_config_vars.% = 1
all_config_vars.HOSTEDGRAPHITE_APIKEY = 25da0edc-c571-4664-b578-cae2b6b040e7
config_vars.# = 0
git_url = https://git.heroku.com/tftest-app-iycoxl7pzx.git
heroku_hostname = tftest-app-iycoxl7pzx.herokuapp.com
internal_routing = false
name = tftest-app-iycoxl7pzx
region = us
stack = heroku-16
web_url = https://tftest-app-iycoxl7pzx.herokuapp.com/
heroku_app.app2:
ID = tftest-app-iycoxl7pzx-2
provider = provider.heroku
acm = false
all_config_vars.% = 1
all_config_vars.HOSTEDGRAPHITE_APIKEY = 25da0edc-c571-4664-b578-cae2b6b040e7
config_vars.# = 1
config_vars.0.% = 1
config_vars.0.HOSTEDGRAPHITE_APIKEY = 25da0edc-c571-4664-b578-cae2b6b040e7
git_url = https://git.heroku.com/tftest-app-iycoxl7pzx-2.git
heroku_hostname = tftest-app-iycoxl7pzx-2.herokuapp.com
internal_routing = false
name = tftest-app-iycoxl7pzx-2
region = us
stack = heroku-16
web_url = https://tftest-app-iycoxl7pzx-2.herokuapp.com/
Dependencies:
data.heroku_app_config_vars.app_config_vars
FAIL
FAIL github.com/terraform-providers/terraform-provider-heroku/heroku 11.348s
Error: Tests failed.
For the life of me, I can't understand why the subsequent plan
after running apply
comes back trying to create data.heroku_app_config_vars.app_config_vars
, where app2
managed to pull off the right config values off the new data resource.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have a direct answer for you, but may I suggest running the tests with TF_LOG=DEBUG
or TF_LOG=TRACE
?
(https://github.com/terraform-providers/terraform-provider-heroku/blob/master/TESTING.md)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@shirdoo I suspect it's because config_vars
are marked as Computed: true
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We've also ran into situations where the API returns a success, but async operations haven't completed behind the scenes. Unsure if that might apply to application config vars.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
finally narrowed it down, the issue is using depends_on
. For some reason, when that attribute is set, the data source is not saving any remote state, so all the apply
's in the world still have the data source coming up as a new resource to create.
@bernerdschaefer, quick review when you get a chance? I'm not happy with the changes outstanding after running apply, any ideas why I'm getting that would be great |
|
||
data "heroku_app_config_vars" "app_config_vars" { | ||
app = "${heroku_app.app.name}" | ||
depends = ["${heroku_addon.hostedgraphite.app}"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not too happy about this, there's a bug somewhere in the terraform provider that breaks a data source when used in conjunction with depends_on.
Instead I'm sticking a dummy attribute to stick inferred dependencies on other terraform resources, so the data resource waits until the addon is added, before trying to slap configs onto downstream resources (ie: app2 doing a lookup of data.heroku_app_config_vars.app_config_vars
before the hosted graphite addon getting attached. I should see if there's an outstanding issue in terraform
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess I'm looking for advice on whether we want to document this depends attribute to reflect this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
voila, here's the issue I hit: hashicorp/terraform#11806
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@talbright @bernerdschaefer @joestump for another quick reivew, thanks in advance!
## Example Usage | ||
|
||
```hcl | ||
# Look up a Heroku Private Space's peering info. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess you copied this example hcl from somewhere else :P
app = "${heroku_app.foo.name}" | ||
} | ||
|
||
# Initiate a VPC peering connection request. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same here
Type: schema.TypeMap, | ||
Computed: true, | ||
}, | ||
"depends": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would consider changing depends
to maybe wait_for_resources
or wait_for
. depends
seems a bit too close to depends_on
and could confuse users.
Additionally I think if we were to move forward with this attribute, I suggest changing the Type
to schema.TypeSet
so that the ordering doesn't matter.
…vider-heroku into config_var_data
|
||
func dataSourceHerokuAppConfigVarsRead(d *schema.ResourceData, m interface{}) error { | ||
client := m.(*heroku.Service) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If m doesn't hold a value of type *heroku.Service it will panic.
you can check the type to make sure a panic doesn't happen if the type doesn't convert.
client, ok := m.(*heroku.Service)
and proceed if okay is true.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its a valid point, that being said we aren't checking the type conversion anywhere else in the code base, so I wouldn't necessarily ding this PR for that.
|
||
func testAccCheckHerokuAppConfigVar(appName string) string { | ||
return fmt.Sprintf(` | ||
resource "heroku_app" "app" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you can turn on gofmt in your ide to fix the formatting indentation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
format passes fine for me:
gofmt -l heroku/data_source_heroku_app_config_vars_test.go
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, I think its the backtick making it look weird, but seems gofmt happy
@davidji99 @bernerdschaefer can one of you take another pass at this? thanks in advance! |
gentle poke @davidji99 @bernerdschaefer |
👀 |
func dataSourceHerokuAppConfigVarsRead(d *schema.ResourceData, m interface{}) error { | ||
client := m.(*heroku.Service) | ||
|
||
appName := d.Get("app").(string) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://github.com/terraform-providers/terraform-provider-heroku/blob/master/heroku/helper.go#L12 could use this helper here.
Type: schema.TypeMap, | ||
Computed: true, | ||
}, | ||
"wait_for_resources": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had a chat with one of the hashicorp guys on this PR. He offered an suggestion:
or perhaps it could work a bit like
consul_keys
where you have to identify which variable names you are looking for, and then the data source could wait until those are ready before returning
Maybe we could do this? a wait_for_keys
or wait_for_vars
where one specifies the keys you're looking for and have a max timeout of say 5min? If this attribute is not set, then just refresh as normal. This might give you and anyone else more control in making sure the data resource has what you need? What do you think Sharath?
closing this due to inactivity: feel free to re-open if you wish to pursue this further. |
No description provided.