-
Notifications
You must be signed in to change notification settings - Fork 11
cvm: fix tag/field SkipImageValidation conflicts #97
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
Conversation
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.
It looks like we need to do more than just rename. I left a suggestion that should get this ready to merge. Please let me know if you have any questions.
@@ -32,7 +32,7 @@ type TencentCloudImageConfig struct { | |||
// after your image created. | |||
ImageShareAccounts []string `mapstructure:"image_share_accounts" required:"false"` | |||
// Do not check region and zone when validate. | |||
SkipValidation bool `mapstructure:"skip_region_validation" required:"false"` | |||
ImageSkipValidation bool `mapstructure:"image_skip_region_validation" required:"false"` |
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 see what happened here. This skip_region_validation is essentially the same as the one in Access Config, as you see before the validRegion function is in Access config. This field was probably copied just to support the check. Instead of renaming I would suggest adding a new config type struct in access_config.go just for the SkipValidation field that can then be embedded into both TencentCloudImageConfig and TencentCloudAccessConfig
Something like
type TenencentCloudRegionValidation struct {
// Do not check region and zone when validate.
SkipValidation bool `mapstructure:"skip_region_validation" required:"false"`
}
This will ensure no breaking change and will work as intended.
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.
Unfortunately I don't think we can do what you suggest as it will still imply a duplicate argument unfortunately.
I ended-up creating a single boolean in the parent config, and propagate its value to private fields on the substructures that needed it.
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.
Hmm.. this is interesting if this is the case I suspect other plugins that use this embedded pattern would have this issue. Just in case I'm recommending we do something like https://github.com/hashicorp/packer-plugin-amazon/blob/2efec668b60523b60c43307e4b4a17b1d6328237/builder/common/run_config.go#L77 which is then embedded into each of the builders https://github.com/hashicorp/packer-plugin-amazon/blob/2efec668b60523b60c43307e4b4a17b1d6328237/builder/ebs/builder.go#L37
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.
With this approach I fear we'll experience the same issue since a single builder has substructures that use this attribute, so if we make a shared structure and embed it in both config structs, it'll still be a conflict, hence the approach I took to propagate the value from an upper level to the sub-structures for later validation.
We could make a Meta
structure to define such attributes later, but I would think we still have to manually propagate the values in this case.
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.
Ah I see - this would be embedded twice within the same config structure for the cvm builder. For whatever reason I thought this was a config being shared across to builders. Sorry for not looking at the builder config entirely. Yeah this makes sense to me.
efaa6ea
to
ddd02d9
Compare
@@ -31,8 +31,7 @@ type TencentCloudImageConfig struct { | |||
// accounts that will be shared to | |||
// after your image created. | |||
ImageShareAccounts []string `mapstructure:"image_share_accounts" required:"false"` | |||
// Do not check region and zone when validate. | |||
SkipValidation bool `mapstructure:"skip_region_validation" required:"false"` | |||
skipValidation bool `mapstructure:"_"` |
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.
Mapstructure tag is not needed.
skipValidation bool `mapstructure:"_"` | |
skipValidation bool |
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.
Good catch! I've removed it from the config
@@ -32,7 +32,7 @@ type TencentCloudImageConfig struct { | |||
// after your image created. | |||
ImageShareAccounts []string `mapstructure:"image_share_accounts" required:"false"` | |||
// Do not check region and zone when validate. | |||
SkipValidation bool `mapstructure:"skip_region_validation" required:"false"` | |||
ImageSkipValidation bool `mapstructure:"image_skip_region_validation" required:"false"` |
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.
Ah I see - this would be embedded twice within the same config structure for the cvm builder. For whatever reason I thought this was a config being shared across to builders. Sorry for not looking at the builder config entirely. Yeah this makes sense to me.
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.
This looks good to me. One small change request but otherwise good to go.
This doesn't seem like a breaking change any more. So I removed the label. Please add it back if I am wrong. |
It won't be breaking for any client I'd think, but it may change the behaviour for HCL2 users maybe. With the configuration in its current state, if someone set |
ddd02d9
to
51d712c
Compare
Seeing as there were no previous bugs reported here it may not have been an issue and folks thought it was happening. Not sure. Feel free to check with @likexian on how you want to release and communicate. Great work here. |
51d712c
to
e9eb5ac
Compare
Since it's been a week since the PR was approved, and no objections were heard, I propose we merge this today (or tomorrow). @likexian, thoughts? Since this fixes some conflicts, and since the SDK has been updated to enforce not having conflicts in fields/tags in the latest release, we can bump the version of the SDK for this plugin, and release a new version if this is alright for you? |
@lbajolet-hashicorp Sorry for the delay. The changes LGTM, but I am not sure about backward compatibility, If there is no breaks, just go ahead. |
The `SkipImageValidation' field and its tag, `skip_region_validation`, was duplicated in two structures, `TencentCloudImageConfig`, and `TencentCloudAccessConfig`. This resulted in unexpected behaviour, as setting the attribute in a template will set the config for both substructures for JSON templates, while on HCL templates, only one would be settable. To fix this discrepancy, we mutualise the field as a config argument for the global configuration object, and propagate its value to the appropriate configuration structures. This way, region validation can be skipped for both the AccessConfig, and the ImageConfig, in all cases.
e9eb5ac
to
fc9a7db
Compare
The
SkipImageValidation' field and its tag,
skip_region_validation, was duplicated in two structures,
TencentCloudImageConfig, and
TencentCloudAccessConfig`.This resulted in unexpected behaviour, as setting the attribute in a template will set the config for both substructures.
To prevent this, we rename one attribute in the image_config, so that it's clear which attribute does what.