Bug 1871954 - incomplete DeepCopy implementation for AWSProviderSpec objects
Summary: incomplete DeepCopy implementation for AWSProviderSpec objects
Keywords:
Status: VERIFIED
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Cloud Credential Operator
Version: 4.6
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: 4.6.0
Assignee: Joel Diaz
QA Contact: wang lin
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-08-24 16:56 UTC by Joel Diaz
Modified: 2020-09-01 07:44 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github openshift cloud-credential-operator pull 234 None closed Bug 1871954: more auto deepcopy functions (less manual) 2020-08-31 07:26:45 UTC

Description Joel Diaz 2020-08-24 16:56:04 UTC
Description of problem:
Doing a DeepCopy of an AWSProviderSpec object leaves the new and original objects pointing to some similar data structures where a change to certain structures one object affects the other.

Version-Release number of selected component (if applicable):


How reproducible:



Steps to Reproduce:
1.DeepCopy an AWSProviderSpec with PolicyConditions
2.Modify the original's PolicyConditions values
3.View the copied objects PolicyConditions

Actual results:
Copied object sees changes to original object.


Expected results:
Copied object is a complete copy of the original object.


Additional info:

Comment 4 wang lin 2020-08-31 09:12:34 UTC
Hi, Joel. Could you tell me how to create DeepCopy from an AWSProviderSpec?

Comment 5 Joel Diaz 2020-08-31 14:44:40 UTC
There are already test cases to cover the DeepCopy() ( https://github.com/openshift/cloud-credential-operator/blob/master/pkg/apis/cloudcredential/v1/aws_manual.deepcopy_test.go#L171-L178 ). You could follow along with that pattern, but since the tests are already written, I would suggest a more high-level testing to make sure nothing broke in the process.

Specifically, testing around CredentialsRequests with conditions defined. Making sure the AWS Users/Policies match what is specified in the CredentialsRequest.

Comment 6 wang lin 2020-09-01 07:44:41 UTC
this won't influence CredentialsRequests.
test payload:4.6.0-0.nightly-2020-08-31-194600

steps:
1.create CR with policyCondition like below:
##################
spec:
  providerSpec:
    apiVersion: cloudcredential.openshift.io/v1
    kind: AWSProviderSpec
    statementEntries:
    - action:
      - iam:CreateServiceLinkedRole
      effect: Allow
      policyCondition:
        StringEquals:
          iam:AWSServiceName: replication.dynamodb.amazonaws.com
      resource: '*'
#####################
2.check user/policy on aws, the policy is the same as i defined


Note You need to log in before you can comment on or make changes to this bug.