The MVP requires that the VPC created be configured with an Internet Gateway.

Outstanding question: Should this step be skipped if the user provides an existing VPC through the ProviderConfig?

If the cluster actuator is managing the public bastion environment, then it should create a security group for the bastion host. The actuator should not create the security group if a user defines a pre-existing bastion environment through config.

/kind feature
/priority important-soon

The cluster actuator should be able to delete a managed public subnet. It should not delete a pre-existing subnet.

There are a couple of different image stamping repo's using ansible and packer.

Let trim one down and port it in.

The cluster actuator needs to be able to create aws subnets for the VPC

Update the build to use bazel

/assign @liztio

Common utilities and wrappers can be incorporated now and doesn't need to wait on some of the design fronts.

We can distill and crib from kubicorn/prototypes/kops etc.

/assign @chuckha

Subtickets:

• #23 VPC
• #24 Instance
• #28 Internet Gateway
• #29 Subnet
• #30 RouteTable
• #35 NAT Gateway
• #36 Security Groups
• #37 ELB

todo - fill in here
/assign @chuckha

/kind feature
/priority important-soon

todo also figure out VPC.

We need code to create/delete a vpc

related to #11

Add code to interface with an internet gateway

The MVP requires a public subnet for hosting a bastion host. This subnet should only be created if the user does not provide configuration to suggest that a public subnet already exists. What exactly that configuration looks like is TBD.

/kind feature
/priority important-soon

/kind feature
/priority important-soon

In order to avoid having to manually build out fake interfaces for all AWS APIs we are interacting with we should look into leveraging some auto-generation or automation.

We can potentially leverage existing work from KOPS or openshift/cluster-operator here.

cc @csrwng
/kind feature
/priority important-soon

I presume subprojects may span multiple SIGs, and I think it'd make sense for this subproject to also be linked to sig-aws.

The cluster actuator should create and manage a bastion host if it is managing the bastion environment. The actuator should not create the bastion host if the user-provided config indicates that an existing bastion environment should be used.

/kind feature
/priority important-soon

It would be good to have CI in place.

cluster-api-provider-openstack already done this in kubernetes/test-infra#8660 so it should be quite easy to follow thet example.

The MVP requires that the cluster actuator be able to delete a managed Internet Gateway.

This should not delete an Internet Gateway that is attached to non-cluster actuator managed VPC.

The cluster actuator should create and manage a load balancer for the apiserver if a user does not provide an existing load balancer.

The load balancer should be a classic ELB configured for tcp-passthrough.

Outstanding question: Should the cluster actuator or the machine actuator update membership for this load balancer?

Depends on: #37

/kind feature
/priority important-soon

The cluster actuator should create and manage a security group for the control plane nodes if a user does not provide an existing security group.

Depends on: #38, #36

/kind feature
/priority important-soon

type Actuator interface {
	// Create or update the cluster
	Reconcile(*clusterv1.Cluster) error
	// Delete the cluster.
	Delete(*clusterv1.Cluster) error
}

• Reconcile
  • #38 Reconcile VPC
  • #40 Reconcile Internet Gateway
  • Reconcile Public facing resources
    • #42 Reconcile public subnet
    • #44 Reconcile routes for public subnet
    • #45 Reconcile bastion security group
    • #46 Reconcile bastion host
  • Reconcile Private resources
    • #47 Reconcile private subnet(s)
    • #48 Reconcile routes for private subnet(s)
    • #49 Reconcile NAT Gateway
    • #50 Reconcile control plane node security group
    • #51 Reconcile worker node security group
  • #52 Reconcile Load Balancer
• Delete
  • #39 Delete VPC
  • #41 Delete Internet Gateway
  • Delete Public facing resources
    • #43 Delete public subnet
    • #56 Delete routes for public subnet
    • #57 Delete bastion security group
    • #58 Delete bastion host
  • Delete Private resources
    • #59 Delete private subnet(s)
    • #60 Delete routes for private subnet(s)
    • #61 Delete NAT Gateway
    • #62 Delete control plane node security group
    • #63 Delete worker node security group
  • #64 Delete Load Balancer
• #15 Define the Security Groups needed

/kind feature
/priority important-soon

/kind feature
/priority important-soon

If the cluster actuator is managing a public subnet it should created the needed routes. The actuator should not manage routes if a user is specifying an existing public subnet should be used through config.

Depends on #42
/kind feature
/priority important-soon

The cluster actuator should be able to create and manage private subnet(s) if the config does not indicate that the user is providing a pre-existing subnet(s).

The MVP only requires a single subnet, but there are future plans to support multi-AZ deployments, so the implementation should take that into account, such as ensuring that the subnet does not use the full cidr range of the VPC.

/kind feature
/priority important-soon

The MVP requires that the cluster actuator be able to idempotently manage a VPC.

• Attempting to update the VPC after creation should probably result in an error
• The actuator should also be able to use an existing VPC defined in the Provider Config.

/kind feature
/priority important-soon

Required mundge github
bots
talk with @spiffxp about where we are going to release artifacts
setup integration with testgrid
talk with @roberthbailey about having a separate cluster-api specific suite.
...

/kind feature
/priority important-soon

The cluster actuator should be able to delete a VPC that was created by the actuator. It should not delete a VPC that was defined by the user in the ProviderConfig.

The goal of this effort is to produce a spec to rally on with interested parties, then break down the work items in this repo.

I'd suggest PR-ing a KEP to this repo that we can agree on.

need to manage aws route table

type Actuator interface {
	// Create the machine.
	Create(*clusterv1.Cluster, *clusterv1.Machine) error
	// Delete the machine. If no error is returned, it is assumed that all dependent resources have been cleaned up.
	Delete(*clusterv1.Cluster, *clusterv1.Machine) error
	// Update the machine to the provided definition.
	Update(*clusterv1.Cluster, *clusterv1.Machine) error
	// Checks if the machine currently exists.
	Exists(*clusterv1.Cluster, *clusterv1.Machine) (bool, error)
}

• #31 Create
• #32 Delete
• #33 Update
• #34 Exists
• #427 kubeadm config support in provider config
• #16 cloud-init module

/kind feature
/priority important-soon

The MVP requires the ability to idempotently manage security groups.

/assign @chuckha @detiber

add code to manage instance

The MVP will require the ability to idempotently manage a NAT gateway for the private subnet(s)

The cluster actuator should create and manage a security group for the control plane nodes if a user does not provide an existing security group.

Depends on: #38, #36

/kind feature
/priority important-soon

The MVP requires the ability to idempotently manage a Classic ELB configured for TCP-passthrough to support load balancing of the API server.

There was talk of tokens and tags and opinions and I'd like to capture those ideas here.

cc @kris-nova @csrwng

The cluster actuator should create and manage route configuration for actuator-managed private subnets. It should not create routes for user-provided pre-existing private subnets that are provided through the ProviderConfig.

Depends on: #47, #38, #30

/kind feature
/priority important-soon

The cluster actuator should create and manage NAT gateway configuration for actuator-managed private subnets. It should not create a NAT gateway for user-provided pre-existing private subnets that are provided through the ProviderConfig.

Depends on: #47, #38, #35

/kind feature
/priority important-soon