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

Implemented support for TLS and ServerCA handling for cloudmemorystore #513

Merged
merged 1 commit into from
Sep 16, 2023

Conversation

andrewj-a42
Copy link
Contributor

@andrewj-a42 andrewj-a42 commented Sep 6, 2023

Description of your changes

The change is adding support for enabling 'SERVER_AUTHENTICATION' for the TransitEncryptionMode.
The code is setting the value of TransitEncryptionMode field for gcp client and is observing serverCACerts field.
As soon as the instance is provisioned and CA is generated it is added to the managed resource to the atProvider section.

Fixes #

I have:

  • Read and followed Crossplane's contribution process.
  • Run make reviewable test to ensure this PR is ready for review.

How has this code been tested

This code was tested by building a fresh image and deploying it to a dev cluster with crossplane pod up and running.
Successful cloudMemoryStore provisioning was performed and with TransitEncryptionMode field set to 'SERVER_AUTHENTICATION' value, the redis provisioning process generated server CA certificate which became part of 'atProvider' section of the managed resource.

Copy link
Collaborator

@dee0sap dee0sap left a comment

Choose a reason for hiding this comment

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

Code change looks good to me.

Hey @Feggah and @hasheddan
Is there anything more than approval required here?

@dee0sap
Copy link
Collaborator

dee0sap commented Sep 8, 2023

Hey @Feggah
Would you please take a look? I approved the PR but still it doesn't seem to be progressing.
Maybe I am not having some required access on the repo ?

@Feggah
Copy link
Collaborator

Feggah commented Sep 8, 2023

Maybe I am not having some required access on the repo ?

You need to follow the new member process to be added to the Crossplane organization. Here is an example of when I was added as maintainer.

I'm unsure if the process is exactly the same because this repository was under the crossplane organization at that time. As it's in crossplane-contrib now, maybe @jbw976 could help to understand if the process is different for community providers today 🙂

@dee0sap
Copy link
Collaborator

dee0sap commented Sep 8, 2023

@Feggah

Thanks, I thought something was missing. I'll go ahead and create the issue as described in that doc, operating under the assumption that the process hasn't changed.

@jbw976
Copy link
Member

jbw976 commented Sep 12, 2023

I just took a look into this and found a couple issues:

  • the repository access settings were not yet updated to reflect the recent changes in OWNERS.md, so I have made those changes now.
    • @dee0sap if you see any invites to join this crossplane-contrib org and this repo, then please do accept them 😉
  • The CI and PR validation workflow has not yet run on this PR because it is from a new contributor and must first be approved. I will click this now to get things going. In the future, I think anyone with maintainer perms can do this.
  • I see that @dee0sap opened MEMBERSHIP: dee0sap crossplane/org#67 to join the main crossplane org as a member - that's not strictly necessary here for this crossplane-contrib repo, but a good thing to do either way, so I'll follow up there too!

@dee0sap
Copy link
Collaborator

dee0sap commented Sep 12, 2023

Thanks @jbw976 !

Hey @andrewj-a42 Please review the lint and check-diff failures.

@andrewj-a42
Copy link
Contributor Author

Thanks @dee0sap for the note on check-diff. I have just addressed those lint problems and locally it is clean now.
I hope these problems were only caused by the linting.

@dee0sap
Copy link
Collaborator

dee0sap commented Sep 13, 2023

Hey @hasheddan and @Feggah

This all looks good to me but as this would be my first merge I want to give you guys the chance to double check things before I push the button. So I'll let this set for a day.

Copy link
Collaborator

@Feggah Feggah 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 the PR! I added some comments mainly to emphasize our "code guidelines" for providers.


Other than that, not specifically to this PR, but a general tip that is important IMHO: I would recommend always striving for test cases where the want and args structs have the resource.Managed field.

This is important to test that the main functions (Observe, Create, Update) are modifying the Managed Resource structure as expected.

For example, check the test cases for the CloudSQL:

type args struct {
mg resource.Managed
}
type want struct {
mg resource.Managed
obs managed.ExternalObservation
err error
}

With this structure, we can validate that the expected modifications to the Managed Resource are happening. Test case example:

provider-gcp_pkg_controller_database_cloudsql_test_go_at_master_·_crossplane-contrib_provider-gcp

Note that the returned spec from the GCP API has BackupConfigurationStartTime set. On the Managed Resource side, it didn't have this field set. So we could validate that if the API returned the field BackupConfigurationStartTime and it wasn't set on the MR, it would be late-initialized.

Comment on lines 46 to 47
// +optional
TransitEncryptionMode string `json:"transitEncryptionMode,omitempty"`
Copy link
Collaborator

Choose a reason for hiding this comment

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

We have a guideline to use pointers for optional fields in the Parameters struct. So this field should be:

Suggested change
// +optional
TransitEncryptionMode string `json:"transitEncryptionMode,omitempty"`
// +optional
TransitEncryptionMode *string `json:"transitEncryptionMode,omitempty"`

Comment on lines +149 to +166
// Cert is the certificate in the PEM format.
Cert string `json:"cert,omitempty"`

// CreateTime: Output only. The time when the certificate was created in
// RFC 3339 (https://tools.ietf.org/html/rfc3339) format, for example
// `2020-05-18T00:00:00.094Z`.
CreateTime string `json:"createTime,omitempty"`

// ExpireTime: Output only. The time when the certificate expires in RFC
// 3339 (https://tools.ietf.org/html/rfc3339) format, for example
// `2020-05-18T00:00:00.094Z`.
ExpireTime string `json:"expireTime,omitempty"`

// SerialNumber: Serial number, as extracted from the certificate.
SerialNumber string `json:"serialNumber,omitempty"`

// Sha1Fingerprint: Sha1 Fingerprint of the certificate.
Sha1Fingerprint string `json:"sha1Fingerprint,omitempty"`
Copy link
Collaborator

Choose a reason for hiding this comment

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

Just a comment here to clarify the difference between the Parameters struct:

Setting omitempty and non-pointer fields in the Observation struct is correct 👍🏼

Comment on lines 233 to 235
// ServerCaCerts: Output only. List of server CA certificates for the
// instance.
ServerCaCerts []*ServerCACertsObservation `json:"serverCaCerts,omitempty"`
Copy link
Collaborator

Choose a reason for hiding this comment

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

Generally, we don't use pointers in the Observation struct. If there isn't a specific reason for it, I would recommend changing to:

Suggested change
// ServerCaCerts: Output only. List of server CA certificates for the
// instance.
ServerCaCerts []*ServerCACertsObservation `json:"serverCaCerts,omitempty"`
// ServerCaCerts: Output only. List of server CA certificates for the
// instance.
ServerCaCerts []ServerCACertsObservation `json:"serverCaCerts,omitempty"`

@andrewj-a42
Copy link
Contributor Author

I just applied the above suggestions related to usage of pointers.

Copy link
Collaborator

@Feggah Feggah left a comment

Choose a reason for hiding this comment

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

LGTM 🙂

Will leave it for @dee0sap to merge it.

@dee0sap
Copy link
Collaborator

dee0sap commented Sep 16, 2023

Thanks much @Feggah !

@dee0sap dee0sap merged commit 01437a1 into crossplane-contrib:master Sep 16, 2023
7 checks passed
@dee0sap
Copy link
Collaborator

dee0sap commented Sep 16, 2023

Oh, a question @Feggah

How and when are releases done? I just searched the markdown in this repo and didn't find any statement about that.

FYI over in provider-aws there is a statement that they do a release every month. That's not the exact wording, but that is the gist.

@Feggah
Copy link
Collaborator

Feggah commented Sep 16, 2023

How and when are releases done?

We don't have an official definition of that for this provider. We kind of did releases as the necessity arose.

Feel free to suggest a frequency or release version as needed 🙂

@dee0sap
Copy link
Collaborator

dee0sap commented Sep 16, 2023

Thanks @Feggah

My teammates and I will discuss next week some time and then reach out to you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants