docs(design): phase-1 docs for layer2 support in CAPP: version 1

[rahulii]

What this PR does / why we need it:
📖 Proposal for adding layer2 support in CAPP

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Part of #613

[k8s-ci-robot]

Welcome @rahulii!

It looks like this is your first PR to kubernetes-sigs/cluster-api-provider-packet 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/cluster-api-provider-packet has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: rahulii
Once this PR has been reviewed and has the lgtm label, please assign sbueringer for approval. For more information see the Kubernetes Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[niravparikh05]

few minor comments, let's add a user flow diagram on the steps CAPP would perform for ease of understanding.

Will go through the user data script in more detail, at a glance it looks good to me.

[displague]

Noting some additional points. These limitations could be left to the user, to define their image store and routing within the L2 network. Other limitations that are perhaps more core to ClusterAPI and CPEM functioning is the need to interact with Equinix Metal APIs (including Metadata where userdata scripts are accessed at node startup). There may be clever ways to work around these limitations, but we are intentionally keeping ideation and solutioning around full layer2 modes out of scope to get the direct benefits of networking modes that enable L2 capabilities without removing the default L3 public address capabilities.

[displague]

I've converted this PR to a draft so that we can continue to iterate on design and implementation (#787 and others) in parallel while the design is being vetted.

Sample userdata scripts are going to be hard to vet in markdown format and will be easier to verify in E2E tests from the implementation PRs.

[displague]

We'll want to update https://github.com/kubernetes-sigs/cluster-api-provider-packet/blob/main/docs/concepts/cluster.md and https://github.com/kubernetes-sigs/cluster-api-provider-packet/blob/main/docs/concepts/machine.md with the results of this design as we get closer to merging the design and implementation.

[rahulii]

the results of this design as we get closer to merging the design and implementation.

yah, once we are closer I will make sure to add the changes in those files. Thanks for reminding!

[displague]

We can write out directly to interfaces.d/something. An example of that here:

https://github.com/equinix-labs/terraform-equinix-metal-hybrid-gateway/blob/main/modules/backend/cloud-config.cfg#L7

[displague]

Err .. nevermind that example.. It was more involved and manipulated cloud-config.d rather than interfaces.d, it also depended on changing the OS to use netplan:

https://github.com/equinix-labs/terraform-equinix-metal-hybrid-gateway/blob/main/modules/backend/pre-cloud-config.sh

That said, we could write out to an interfaces.d/ file directly. This is just a nitpic and there may be reasons why it is better to take the inline approach you offered, to ensure that the modification is made at the right time relative to other operations.

[rahulii]

I really don't have any opinions on /etc/network/interfaces vs /interfaces.d directory 😅
If it seems reasonable to write into /interfaces.d , I will try that out once.

[niravparikh05]

examples need to be updated based on our recent discussions, it should not contain the ip cidr

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale