CRD usage of pointers vs non-pointers

[shahulsonhal]

Changes

We were not following the pointer vs non-pointer fields for custom resource definitions having required and optional fields.
Fixes #397

Update required custom resource fields to non-pointer
Update optional custom resource fields that do not have a built-in nil value to pointers

Submitter Checklist

• Includes tests if functionality changed/was added
• Includes docs if changes are user-facing
• Set a kind label on this PR
• Release notes block has been filled in, or marked NONE

See the contributor guide
for details on coding conventions, github and prow interactions, and the code review process.

Release Notes

action required: We have cleaned up our APIs to provide a consistent representation of optional fields in Go. If you consume our Go types, many optional field types have been converted to pointers.

[SaschaSchwarze0]

@adambkaplan @gabemontero @HeavyWombat Looking for other opinions on optional fields. Imo we should use pointers for objects and fields where we must distinguish the "default value (""/false/0) and nil. In other cases we should use omitempty.

[shahulsonhal]

@adambkaplan @gabemontero @HeavyWombat Looking for other opinions on optional fields. Imo we should use pointers for objects and fields where we must distinguish the "default value (""/false/0) and nil. In other cases we should use omitempty.

@SaschaSchwarze0 Thanks.

we ask that pointers always be used with optional fields that do not have a built-in nil value

I saw this line in api-conventions and decided to use the pointers for primitive types as well.

[SaschaSchwarze0]

@adambkaplan @gabemontero @HeavyWombat Looking for other opinions on optional fields. Imo we should use pointers for objects and fields where we must distinguish the "default value (""/false/0) and nil. In other cases we should use omitempty.

@SaschaSchwarze0 Thanks.

we ask that pointers always be used with optional fields that do not have a built-in nil value

I saw this line in api-conventions and decided to use the pointers for primitive types as well.

I see. Okay. Let's wait for further feedback and if needed bring it up in next Monday's community meeting.

[SaschaSchwarze0]

/hold

Adding hold so that we merge this after the 0.7.0 release. We should merge this then soon and do the necessary changes in the CLI.

[SaschaSchwarze0]

/unhold

@shahulsonhal this needs a rebase

[SaschaSchwarze0]

I recently learned that the functions with Ptr suffix in the pointer package are deprecated. That's most of my comments. A few others. If you do not have time for it @shahulsonhal, you can also grant me write access to your fork, I'll then append a commit.

[SaschaSchwarze0]

/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: SaschaSchwarze0

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [SaschaSchwarze0]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[SaschaSchwarze0]

We decided to merge this after the v0.8 release so that we have enough time to adopt the CLI and test things there.

[adambkaplan]

/lgtm

Now that v0.8.0 is out, we can merge this.