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

Update go client, use new synthetics target #571

Merged
merged 12 commits into from
Jul 20, 2020
Merged

Conversation

therve
Copy link
Contributor

@therve therve commented Jul 8, 2020

This updates the go client to the latest version to be able to use the new
SyntheticsTest model, in particular the validatesJSONPath operator.

Closes ##545, #566

@therve therve added the do-not-merge/WIP Do not merge this PR label Jul 8, 2020
@therve therve force-pushed the therve/synthetics-json-path branch from 2447693 to b3a56a0 Compare July 10, 2020 20:19
@therve therve added resource/synthetics and removed do-not-merge/WIP Do not merge this PR labels Jul 10, 2020
Copy link
Contributor

@nmuesch nmuesch 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 this 🙇 Did a high level review, i'll spend some time next week playing around with test scenarios since we're modifying schema types. Left a couple questions/comments inline.

Comment on lines 398 to 402
} else if assertionTarget.GetOperator() == datadogV1.SYNTHETICSASSERTIONOPERATOR_VALIDATES {
assertionTarget.SetTarget(v.(string))
} else {
assertionTarget.SetTarget(v.(string))
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this just be one else?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah most likely.

assertionMap := attr.(map[string]interface{})
if v, ok := assertionMap["type"]; ok {
assertionType := v.(string)
assertion.SetType(datadogV1.SyntheticsAssertionType(assertionType))
Copy link
Contributor

Choose a reason for hiding this comment

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

Any reason to change this logic if we're deprecating it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's because of the api client change I believe.

datadog/resource_datadog_synthetics_test_.go Outdated Show resolved Hide resolved
@@ -466,20 +562,48 @@ func updateSyntheticsTestLocalState(d *schema.ResourceData, syntheticsTest *data
d.Set("request_headers", actualRequest.Headers)

actualAssertions := syntheticsTest.GetConfig().Assertions
var localAssertions []map[string]string
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need to keep any of the existing logic for users that still use assertions for a bit?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah I think I found what was needed there.

@therve therve added the do-not-merge/WIP Do not merge this PR label Jul 11, 2020
@therve
Copy link
Contributor Author

therve commented Jul 11, 2020

Imports don't work properly just yet.

@therve therve removed the do-not-merge/WIP Do not merge this PR label Jul 11, 2020
@therve
Copy link
Contributor Author

therve commented Jul 11, 2020

OK I believe I found a correct path forward. The trick is to keep using the old field if it's referenced in the current state, otherwise use the new field everywhere. AFAIU it just a bit weird if you use import with the old schema.

Copy link
Contributor

@jirikuncar jirikuncar left a comment

Choose a reason for hiding this comment

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

@therve can you bump the version of datadog-api-client-go in separate PR?

Copy link
Contributor

@nmuesch nmuesch left a comment

Choose a reason for hiding this comment

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

I apologize I haven't done a full manual test with this yet, but I did take a deeper look and left another review with some followup questions

Type: schema.TypeString,
Optional: true,
},
"targetjsonpath": {
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we have this conflictsWith target? They seem mutually exclusive

Copy link
Contributor Author

@therve therve Jul 20, 2020

Choose a reason for hiding this comment

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

It doesn't work with nested fields unfortunately.

Copy link
Contributor

Choose a reason for hiding this comment

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

if v, ok := assertionMap["operator"]; ok {
assertionOperator := v.(string)
assertion.SetOperator(datadogV1.SyntheticsAssertionOperator(assertionOperator))
if v, ok := assertionMap["operator"]; ok {
Copy link
Contributor

Choose a reason for hiding this comment

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

It looks like this code path is pretty much the same as before, but some is further indented now. From the schema aren't type and operator siblings? Do the operator and target checks need to happen inside the type check?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

They are now required, so it's indented because we only create the structure when we already have the previous fields.

@@ -49,6 +73,8 @@ func TestAccDatadogSyntheticsSSLTest_importBasic(t *testing.T) {
ResourceName: "datadog_synthetics_test.ssl",
ImportState: true,
ImportStateVerify: true,
// Assertions will be imported into the new schema by default, but we can ignore them as users need to update the local config in this case
ImportStateVerifyIgnore: []string{"assertions", "assertion"},
Copy link
Contributor

Choose a reason for hiding this comment

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

Is the issue here that on import we will have both assertions and assertion in the state? Is this going to cause an unempty diff on future applys?

Actually, re-reading some of the code above, it looks like you check for the config before saving this field, in updateSyntheticsTestLocalState, so is this ignore still a requirement?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I check the config before saving the field, but it only works if I already have state. IIUC, the ImportStateVerify compares to a plain import, which doesn't compare to anything locally.

datadog/resource_datadog_synthetics_test_.go Outdated Show resolved Hide resolved
localAssertion["target"] = convertToString(target)
localAssertions[i] = localAssertion
}
// If the config still uses assertions, keep using that in the state to not generate useless diffs
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd have to test around with this a bit more, but I'm not sure if d is always from the config. I think depending on which lifecycle piece we're in, d can reflect the object from the state instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah it mostly comes from the state, but that's what I care about here.

@therve
Copy link
Contributor Author

therve commented Jul 20, 2020

@therve can you bump the version of datadog-api-client-go in separate PR?

It needs a code change so I'd rather merge that one if we're close.

@therve therve merged commit 7de6c6e into master Jul 20, 2020
@therve therve deleted the therve/synthetics-json-path branch July 20, 2020 12:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants