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

move network resources to v1beta1 #182

Merged
merged 12 commits into from
Jun 15, 2020

Conversation

sahil-lakhwani
Copy link
Contributor

Signed-off-by: sahil-lakhwani sahilakhwani@gmail.com

Description of your changes

This PR moves all existing network resources to v1beta1

Tested examples in examples/network.

Checklist

I have:

  • Run make reviewable to ensure this PR is ready for review.
  • Ensured this PR contains a neat, self documenting set of commits.
  • Updated any relevant documentation, examples, or release notes.
  • Updated the dependencies in app.yaml to include any new role permissions.

@sahil-lakhwani sahil-lakhwani marked this pull request as ready for review March 31, 2020 04:34
@muvaf muvaf self-requested a review April 1, 2020 20:51
Copy link
Member

@muvaf muvaf left a comment

Choose a reason for hiding this comment

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

I've been able to review only internet gateway. Most of the comments probably apply to other resources, too. So, I'd suggest checking others as well during iteration.

In the future, please consider breaking up PRs by resource so that reviews are easier and we can merge the ones that are approved separately, faster.

pkg/controller/network/internetgateway/controller.go Outdated Show resolved Hide resolved
pkg/controller/network/internetgateway/controller.go Outdated Show resolved Hide resolved
pkg/controller/network/internetgateway/controller.go Outdated Show resolved Hide resolved
pkg/controller/network/internetgateway/controller.go Outdated Show resolved Hide resolved
pkg/controller/network/internetgateway/controller.go Outdated Show resolved Hide resolved
pkg/controller/network/internetgateway/controller.go Outdated Show resolved Hide resolved
pkg/controller/network/internetgateway/controller.go Outdated Show resolved Hide resolved
apis/network/v1beta1/internetgateway_types.go Show resolved Hide resolved
@muvaf
Copy link
Member

muvaf commented Apr 1, 2020

@sahil-lakhwani On another note, please don't hesitate to make changes to the existing logic or decide to take some small divergences to make things simpler as you see fit.

@infinitecompute
Copy link

@sahil-lakhwani @muvaf What is the checklist to get this closed out? Can we resolve all conversations that have been addressed please.

apis/network/v1beta1/internetgateway_types.go Outdated Show resolved Hide resolved
apis/network/v1beta1/securitygroup_types.go Show resolved Hide resolved
apis/network/v1beta1/subnet_types.go Outdated Show resolved Hide resolved
@sahil-lakhwani
Copy link
Contributor Author

@muvaf @hasheddan I have addressed your comments, and taken care of them across resources. I have replied to comments which are not marked Outdated here, they are addressed in the code.

@negz
Copy link
Member

negz commented Apr 18, 2020

This PR needs a rebase due to the work we did to migrate all the controllers to support the crossplane.io/external-name annotation. It will likely need further rebasing once #198 lands, so it might be best to rebase on that branch.

runtimev1alpha1 "github.com/crossplane/crossplane-runtime/apis/core/v1alpha1"
)

// Route describes a route in a route table.
type Route struct {
// The IPv4 CIDR address block used for the destination match. Routing
// decisions are based on the most specific match.
DestinationCIDRBlock string `json:"destinationCidrBlock"`
DestinationCIDRBlock string `json:"destinationCidrBlock,omitempty"`
Copy link
Member

Choose a reason for hiding this comment

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

I notice you added an omitempty tag here. Is this field optional? If so, should it have the optional comment marker and be a pointer?

Copy link
Member

Choose a reason for hiding this comment

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

Ah - is this to accomodate using Route in both the spec and the status? I suggest we avoid doing this, per my comments below.

apis/network/v1beta1/routetable_types.go Outdated Show resolved Hide resolved
// The state of the association.
State string `json:"state,omitempty"`

Association Association `json:",inline"`
Copy link
Member

Choose a reason for hiding this comment

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

Similar to my comment about RouteState above, I'd prefer to avoid embedding the Association here and to just include a SubnetID string field in the AssociationState.

apis/network/v1beta1/subnet_types.go Outdated Show resolved Hide resolved
examples/network/securitygroup.yaml Outdated Show resolved Hide resolved
pkg/controller/network/securitygroup/controller.go Outdated Show resolved Hide resolved
}
}

if patch.Ingress != nil {
Copy link
Member

Choose a reason for hiding this comment

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

It looks like we create the security group, but never add any ingress or egress rules until update time. Does this mean there will be a brief window in which the security group will appear to be 'ready' but won't actually be allowing the traffic it is configured to allow?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Have added a check for the ingress/egress rules, and then updating the status.

return managed.ExternalCreation{}, errors.Wrap(err, errPersistExternalName)
meta.SetExternalName(cr, aws.StringValue(ig.InternetGateway.InternetGatewayId))

return managed.ExternalCreation{}, errors.Wrap(e.kube.Update(ctx, cr), errSpecUpdate)
Copy link
Member

Choose a reason for hiding this comment

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

Here and elsewhere in this PR, it seems like we have a call order of:

  1. Set conditions. (Modifies status)
  2. Set external name. (Modifies metadata)
  3. Call e.kube.Update()

This is all followed by a call to e.kube.Status().Update() made by the managed.Reconciler.

Will calling Update() before we call Status().Update() undo the status conditions that we set? I can never remember whether Update() overwrites status or not.

Copy link
Member

Choose a reason for hiding this comment

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

Will calling Update() before we call Status().Update() undo the status conditions that we set?

Yes. The operation that undoes the rest of the resource is not Update but the call itself actually. What it does when you call either Status().Update() or Update() is that it issues the respective payload (either only status or metadata+spec) and then deep copies the resulting object into what you have sent. So, the local object is the most up-to-date version that exists in the api-server, which means the payload that you didn't send is overwritten by whatever is in api-server.

We have synced with @sahil-lakhwani about this and it seems calling Status().Update() after the SetConditions makes sense because that way if the CreateInternetGatewayRequest call fails, the condition will reflect that the error arose during creation.

if !ok {
return managed.ExternalCreation{}, errors.New(errUnexpectedObject)
}

// if VPCID already exists, skip creating the vpc
// this happens when an error has occurred when modifying vpc attributes
Copy link
Member

Choose a reason for hiding this comment

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

Is this no longer a concern?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

After the below comment is addressed, I think this won't be needed.

attrReq := e.client.ModifyVpcAttributeRequest(input)

if _, err := attrReq.Send(ctx); err != nil {
if _, err := e.client.ModifyVpcAttributeRequest(input).Send(ctx); err != nil {
return managed.ExternalCreation{}, errors.Wrap(err, errModifyVPCAttributes)
}
}
Copy link
Member

Choose a reason for hiding this comment

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

It seems like this PR mostly has a pattern of creating a resource in Create, then waiting until Update time to set any fields that are modifiable. Should we follow that pattern for VPCs?

Copy link
Member

@muvaf muvaf left a comment

Choose a reason for hiding this comment

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

I have left some comments but they should be easy to fix. Let's wrap up this PR, merge and revisit later for more.

A general comment, +immutable tag is not used in many of the resources. Even though it's not functional yet, it shows up in docs and serves a nice informational purpose. Also it seems the PR needs to be rebased.

apis/network/v1beta1/vpc_types.go Outdated Show resolved Hide resolved
}

meta.SetExternalName(cr, aws.StringValue(result.Vpc.VpcId))
Copy link
Member

Choose a reason for hiding this comment

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

Right after setting the external name, we should call e.kube.Update() so that the annotation is not lost if the next steps fail for some reason.

pkg/controller/network/vpc/controller.go Outdated Show resolved Hide resolved
current := cr.Spec.ForProvider.DeepCopy()
ec2.LateInitializeVPC(&cr.Spec.ForProvider, &observed)
if !cmp.Equal(current, &cr.Spec.ForProvider) {
if err := e.kube.Update(ctx, cr); err != nil {
Copy link
Member

Choose a reason for hiding this comment

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

Once you call e.kube.Update(), the cr object will be populated with whatever the resulting object is in the api-server and that doesn't include status, i.e. all changes you make on status before this line gets lost. It's probably called only once or twice as late-init frequency is low but would be better if you just moved the SetConditions calls below e.kube.Update.

pkg/clients/ec2/vpc.go Outdated Show resolved Hide resolved
@@ -142,99 +158,134 @@ func (e *external) Observe(ctx context.Context, mgd resource.Managed) (managed.E
cr.SetConditions(runtimev1alpha1.Available())
}

Copy link
Member

Choose a reason for hiding this comment

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

Why don't we need a late-init for this resource?

pkg/clients/ec2/internetgateway.go Outdated Show resolved Hide resolved
pkg/clients/ec2/internetgateway.go Outdated Show resolved Hide resolved
if len(in.Tags) == 0 && len(rt.Tags) != 0 {
in.Tags = v1beta1.BuildFromEC2Tags(rt.Tags)
}
}
Copy link
Member

Choose a reason for hiding this comment

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

Ideally, there should be a field of the struct and we should late-init only the elements that we don't have locally. But that doesn't handle the fact that user might have wanted to delete that entry. Lately, I've been thinking that maybe we'd require user to prefix - in the key field value to let us know that this entry should be removed, similar to kubectl unlabel notation.

The late-init only in case the array is empty is the safe solution but there are cases where there is a constant default entry even if you didn't create it, so, we'd be missing that. But I think skipping if the spec array is not empty should be fine for this PR

if len(in.Tags) == 0 && len(rt.Tags) != 0 {
in.Tags = v1beta1.BuildFromEC2Tags(rt.Tags)
}
}
Copy link
Member

Choose a reason for hiding this comment

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

FWIW, this function is not used in Observe. Only in UpToDate check as far as I can see.

@muvaf muvaf self-assigned this Jun 2, 2020
Signed-off-by: sahil-lakhwani <sahilakhwani@gmail.com>
Signed-off-by: sahil-lakhwani <sahilakhwani@gmail.com>
Signed-off-by: sahil-lakhwani <sahilakhwani@gmail.com>
Signed-off-by: sahil-lakhwani <sahilakhwani@gmail.com>
Signed-off-by: sahil-lakhwani <sahilakhwani@gmail.com>
Signed-off-by: sahil-lakhwani <sahilakhwani@gmail.com>
Signed-off-by: sahil-lakhwani <sahilakhwani@gmail.com>
Signed-off-by: sahil-lakhwani <sahilakhwani@gmail.com>
Signed-off-by: sahil-lakhwani <sahilakhwani@gmail.com>
Signed-off-by: sahil-lakhwani <sahilakhwani@gmail.com>
@sahil-lakhwani
Copy link
Contributor Author

@muvaf @negz I have addressed the comments. I have resolved some trivial conversations.
Also, have made sure that the CR Status is updated before it is lost.

Copy link
Member

@muvaf muvaf left a comment

Choose a reason for hiding this comment

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

Assuming all is manually tested, LGTM! I have one small comment but this should be ready to merge. @negz

apis/network/v1beta1/vpc_types.go Outdated Show resolved Hide resolved
@muvaf
Copy link
Member

muvaf commented Jun 10, 2020

@hasheddan Is the current group OK for these resources or should it be ec2.aws.crossplane.io ?

// +kubebuilder:object:root=true

// A VPC is a managed resource that represents an AWS Virtual Private Cloud.
// +kubebuilder:printcolumn:name="VPCID",type="string",JSONPath=".status.atProvider.vpcId"
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
// +kubebuilder:printcolumn:name="VPCID",type="string",JSONPath=".status.atProvider.vpcId"
// +kubebuilder:printcolumn:name="VPCID",type="string",JSONPath=".metadata.annotations['crossplane.io/external-name']"

I believe this should work but didn't test manually.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I checked this, it doesn't work and I have removed that printcolumn annotation for now.

Copy link
Member

Choose a reason for hiding this comment

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

Here is the working form:

// +kubebuilder:printcolumn:name="VPCID",type="string",JSONPath=".metadata.annotations.crossplane\\.io/external-name"

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks @muvaf. Added this in a new commit.

Signed-off-by: sahil-lakhwani <sahilakhwani@gmail.com>
@hasheddan hasheddan self-requested a review June 10, 2020 14:04
Copy link
Member

@hasheddan hasheddan left a comment

Choose a reason for hiding this comment

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

@muvaf I feel like they probably should be in ec2 group, but at this point I think we should either stick with network, or merge this then circle back around to update group before next release.

@muvaf muvaf requested a review from hasheddan June 13, 2020 10:14
@muvaf
Copy link
Member

muvaf commented Jun 13, 2020

@hasheddan we need your approval because of your request for changes.

Copy link
Member

@hasheddan hasheddan left a comment

Choose a reason for hiding this comment

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

Approving to remove my requested changes. I haven’t gotten a chance to do a final review but will defer to @muvaf here

Signed-off-by: sahil-lakhwani <sahilakhwani@gmail.com>
@muvaf
Copy link
Member

muvaf commented Jun 15, 2020

Tested with Wordpress and it's working as expected.

Merging this and I will open a follow-up PR to move these network CRDs to ec2 group per @hasheddan 's comment and then update AWS Sample Stack to use the new specs.

@muvaf muvaf merged commit 534d6d9 into crossplane-contrib:master Jun 15, 2020
@hasheddan
Copy link
Member

@muvaf nice, thanks!

wolffbe pushed a commit to wolffbe/provider-aws that referenced this pull request Feb 12, 2021
namku pushed a commit to namku/provider-aws that referenced this pull request Mar 9, 2021
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