Support specifying VPC

[timoreimann]

What this PR does / why we need it:
This change adds a field to DONetwork specifying the VPC UUID and updates the controllers to pass the ID into droplet and load balancer create requests. That way, users can create custom VPCs and have their CAPI-managed clusters join them.

Which issue(s) this PR fixes:
Fixes #177

Special notes for your reviewer:
I was looking into writing a dedicated e2e test for this feature. The part I struggled with is how to customize the subnet definition in the Cluster resource and, more importantly, the subnet defined in the Calico config file. I think I can solve the former by introducing another DO-specific environment variable, but not sure if the same pattern applies for the Calico config.

Happy to follow up on this before calling the PR done if anyone is willing to provide some guidance. Thanks!

Release note:

Add support for specifying the VPC UUID

[k8s-ci-robot]

Hi @timoreimann. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[cpanato]

/ok-to-test

[prksu]

/milestone v0.5

[prksu]

@timoreimann so the users should to create the vpc before using that right?
how about automatically creating vpc through docluster-controller. so users just configure the vpc spec under DONetwork that contains name and ip range entity.

[timoreimann]

@prksu I like the idea to let the controller manage the VPC. I'm also thinking though that some users may want to use a pre-existing VPC, in which case the controller should probably verify that the VPC exists. Any thoughts on covering both cases? (If so, then I could first tackle the simpler case of the two followed by the other in a future PR.)

[cpanato]

/approve

[timoreimann]

@prksu I moved the VPC UUID below a newly created struct named VPC. This should provide space for adding more VPC-specific fields, like the subnet.

WDYT about getting this PR in first so that users who are fine with specifying the VPC ID explicitly and configuring the subnet etc. accordingly can benefit from it, while we leave the more complex auto-discovery approach to a future PR? The latter still has a few open questions for me, especially how a dynamically retrieved subnet can be fed into the CNI configuration. We might need more time to sort that out.

[prksu]

@prksu I moved the VPC UUID below a newly created struct named VPC. This should provide space for adding more VPC-specific fields, like the subnet.

That's what I thought too.
And yes, we can leave the rest as the follow up. Thanks @timoreimann

/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cpanato, prksu, timoreimann

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 [cpanato,prksu]

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