Cluster-api-provider-aws: UMBRELLA: Variants

[errordeveloper]

As we've discussed a few different use-cases, and it became immediately clear that certain use-cases are significantly different, yet there is enough overlap in certain areas, larger when it comes down to general AWS things.

Example use cases:

• Control plane flavours:
  
  
  
  • Hosted, i.e. EKS
  
  
  • Hosted in other provider, e.g. GKE
  
  
  • Control plane as pods in management cluster
  
  
  • Control plane as standalone instances:
    
    
    
    
    
    • in the same region
    
    
    
    • different regions
    
    
    
  
  
• Nodes:
  
  
  
  • Managed by:
    
    
    
    
    
    • parent control plane
    
    
    
    • management cluster that manages the parent control plane also
    
    
    
  
  
  • Networking:
    
    
    
    
    
    • VPC per group of nodes
    
    
    
    • shared VPC, many subnets and SGs
    
    
    
  
  
  • Images:
    
    
    
    
    
    • immutable: LinuxKit
    
    
    
    • semi-immutable: Atomic, CoreOS Container Linux
    
    
    
    • mutable: Arch, Fedora, Ubuntu, etc
    
    
    
  
  
  • Scaling:
    
    
    
    
    
    • managed directly by the Cluster API providers
    
    
    
    • managed via ASG+MachineSet
    
    
    
    • managed directly, with MachineSet
    
    
    
  
  
• AWS resource management
  
  
  
  • individual resources managed directly by the Cluster API providers
  
  
  • via CloudFormation
  
  
  • via Terraform
  
  
• Other significant modes:
  
  
  
  • use of bastion
  
  
  • use of ELB for API access
  
  
  • VPN-only API access
  
  

Some of these use-cases maybe map out as properties or options of particular a flavours, yet it's probably a good idea to leave this open for discussion to start with. This issue is to discuss the next steps towards defining what attributes comprise a Flavour, and what we may exclude.

[errordeveloper]

For the purpose of moving the discussion forward, I'd like to follow up with a straw man proposal of EKS flavour, based on eksctl. Once we have a clearer idea and a common conceptual framework, we can proceed to implementing and see how other flavours may fit in. Hopefully EKS flavour would be significantly representative of the type of what are common differences between flavours.

[timothysc]

@errordeveloper Could you work with @davidewatson on writing up a simple spec that we could use to rally other folks around?

[errordeveloper]

@timothysc sure, happy to do that!

[randomvariable]

Linking https://github.com/kubernetes-sigs/cluster-api-provider-aws/blob/master/docs/proposal/features.md here for the history

[detiber]

/assign @errordeveloper
/assign @davidewatson

[gyuho]

@errordeveloper @davidewatson Any updates?

[detiber]

@gyuho things have been a bit hectic lately as we've been working on getting the initial release out.
we will be using the Oct 15th AWS Provider Office Hours to do planning and prioritization for the next release, and I highly suspect that variants will end up relatively high on the list there.

[gyuho]

@detiber I see. I will be attending office hours. Happy to collaborate :) Thanks!

[detiber]

/assign @gyuho @randomvariable

[dennisme]

My team and I are particularly interested in CoreOS support and the changes needed for this. Happy to take the first swing.

[randomvariable]

May be better to target Fedora Atomic, which should be using Ignition now afaik?

We'll need to take into consideration the bootstrap since we are using a kubeadm cloud-init module at the moment

[dennisme]

Ah almost forgot about Atomic. I'm not seeing anything on ignition support other than feature requests. https://www.redhat.com/archives/anaconda-devel-list/2018-April/msg00005.html

[randomvariable]

Ah, that was the ticket I read months ago. I thought it had happen. I've pinged the ticket in Pagure.

[cgwalters]

Fedora CoreOS will succeed Fedora Atomic Host and it will use Ignition.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[chuckha]

we plan to reference this in future issues as this issue itself is too large in scope