Proposal for handling late-initialization in ACK.

[vijtrip2]

Issue #812 , if available:

Description of changes:

• Adding the proposal on how to handle server-side defaults/late-initialization in ACK.
• You can find the rendered proposal document here

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[vijtrip2]

/hold
/do-not-merge

[RedbackThomson]

Wow, really good stuff, here. Your solution is actually a lot more elegant than I had initially imagined. Great detective work with flux. Left some comments nitpicking specifics

[jaypipes]

@vijtrip2 I would like you to break this PR into two separate proposals, one that specifically addresses the late initialization of fields that the user does not specify and the server sets to a default value and another proposal for handling fields where the k8s user does specific a value for the field, but the backend service overrides that specified value.

The two use cases are substantially different and I'd like to tackle the former use case (defaulting field values that the k8s user did not specify) ASAP before moving on to tacklling the server-override field use case.

[vijtrip2]

@vijtrip2 I would like you to break this PR into two separate proposals, one that specifically addresses the late initialization of fields that the user does not specify and the server sets to a default value and another proposal for handling fields where the k8s user does specific a value for the field, but the backend service overrides that specified value.

The two use cases are substantially different and I'd like to tackle the former use case (defaulting field values that the k8s user did not specify) ASAP before moving on to tackling the server-override field use case.

Sounds good. I actually started implementing server-override, that's why this PR went stale.
I will prioritize work on server-side defaults instead.

[echen-98]

@vijtrip2 I would like you to break this PR into two separate proposals, one that specifically addresses the late initialization of fields that the user does not specify and the server sets to a default value and another proposal for handling fields where the k8s user does specific a value for the field, but the backend service overrides that specified value.

The two use cases are substantially different and I'd like to tackle the former use case (defaulting field values that the k8s user did not specify) ASAP before moving on to tacklling the server-override field use case.

+1, I think "default fields" and "override fields" need different solutions.

I would request that this comment be considered when coming up with solutions for default fields.

[vijtrip2]

@vijtrip2 I would like you to break this PR into two separate proposals, one that specifically addresses the late initialization of fields that the user does not specify and the server sets to a default value and another proposal for handling fields where the k8s user does specific a value for the field, but the backend service overrides that specified value.

The two use cases are substantially different and I'd like to tackle the former use case (defaulting field values that the k8s user did not specify) ASAP before moving on to tacklling the server-override field use case.

+1, I think "default fields" and "override fields" need different solutions.

I would request that this comment be considered when coming up with solutions for default fields.

@echen-98 We decided in a previous meeting that late initialized fields will be populated back in resource spec. And the new solution will be based on that for late initialized(i.e.default) fields. More details will be there in future PR.

Going that path, "the comment" regarding nil difference will not be required for handling unnecessary updates.

[vijtrip2]

• I have updated this PR to only deal with late initialized fields
• I have created a separate PR #856 to propose a solution for server-side-overrides.

[jaypipes]

@vijtrip2 I'd like to see a fairly substantial reworking of this proposal document. See inline for details, but overall, I'd like to see the following layout used:

# Problem overview
# Solution requirements
# Proposed solution
## ACK code-generator
## ACK runtime
# Alternate solutions considered

[jaypipes]

@vijtrip2 I think you may have misunderstood previous comments I made. I've tried to highlight in the inline comments how I think the changes to the reconciler should be done in order to minimize changes needed to the AWSResourceManager interface...

[jaypipes]

This is much better. Getting close. A few suggested renames inline...

[jaypipes]

I'm good with this. If @RedbackThomson and @a-hilaly are also good with it, let's merge away.

[a-hilaly]

Looks solid to me! I'm good with merging this PR once @RedbackThomson comments are addressed

[RedbackThomson]

/lgtm

[ack-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: A-Hilaly, jaypipes, RedbackThomson, vijtrip2

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 [A-Hilaly,RedbackThomson,jaypipes,vijtrip2]

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