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

refactor(*): Remove credentialAccount from all AWS-derived cloud providers #4017

Merged
merged 1 commit into from
Sep 10, 2019

Conversation

robzienert
Copy link
Member

@robzienert robzienert commented Sep 10, 2019

What could possibly go wrong with this? Really. What could possibly go wrong with this? I know we have duplication for credentials vs account, this is standardizing on credentials, since like... I don't even know why credentialAccount ever existed to begin with.

It looks to me like most of the code for descriptions expects credentials, whereas account isn't really referenced directly anyhow? (Looking at AtomicOperationConverters for the AWS-derived cloud providers).

Copy link
Contributor

@cfieber cfieber left a comment

Choose a reason for hiding this comment

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

seeems fine...

@robzienert
Copy link
Member Author

yolo

@robzienert robzienert merged commit 7c861e3 into spinnaker:master Sep 10, 2019
@ajordens
Copy link
Contributor

Belated LGTM, I also don’t recall where credentialAccount originated.

ezimanyi added a commit that referenced this pull request Sep 12, 2019
The change in #4017 broke deserialization of
the account property. This is due to some confusing inheritence
where KubernetesAtomicOperationDescription has a field 'account'
that overrides the default method in the CredentialsNameable
interface. Adding @JsonProperty("credentials") to the interface
method broke deserialization.

This can be fixed by adding an explicit @JsonProperty("account")
to the field in KubernetesAtomicOperationDescription. As this is
subtle, also add a test to validate this (and prevent it from
breaking in the future). While it might be better to rename the
account field, it's used all over the V1 provider in groovy code,
so this change is much safer as it keeps the interface of the
class to consumers the same.

The test that is added passes before #4017,
breaks after that change, and passes again with this change.
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.

5 participants