Cluster API: data-model workstream

Hello everyone,

below you’ll find the dates for the kickoff meeting of Cluster API data-model workstream.


  • Monday April 15th, 2019 10AM PST
    • Highest voted date
  • Thursday April 18th, 2019 9AM PST
    • Highest voted date prioritizing EMEA folks

Add your agenda items to the Meeting Notes document, a Google Calendar invitation will follow. As always, please feel free to reach out with comments, questions, or concerns.


The calendar invite that went out for “data-model workstream kickoff - 1” says it’s tomorrow, Tuesday April 16. But this thread, and the noted doc, both say it’s today. Can you confirm which it is?

Fixed it, also updated the Zoom meeting. Thanks for the heads up!

1 Like

Monday 15 April 2019 - 10AM Pacific

Recording coming soon (@detiber)

  • [vincepri] Workstream introduction, deliverables, and goals
    • Objective: Define Cluster API high level types, their boundaries, requirements, and use cases.
    • Cluster
    • Machines (+MachineSet, +MachineDeployment)
    • MachineClass
  • [vincepri] New Types
    • Outdated Proposal
      • Bullet point items below are from the former proposal above by vincepri and Robert Bailey, but is here only for information.
    • ControlPlane
      • Described within this group, but will tie into control plane lifecycle workstream
      • Initially arrived to address “external control planes”, which may not necessarily be spun up by Cluster API
    • Infrastructure
      • Describes the infrastructure within the cluster. What do we see this type doing in cluster-api?
      • Where do we describe the infrastructure that it outside of the cluster, and that can be used to build other clusters? (dhellmann)
  • [chuckha] Need to link these to use cases
    • [pablochacin] It woud be useful to have the use cases already in the repo to facilitate referencing them,mostly because the actual document has may use cases which are probably not included and some still require clarification.
    • [vincepri] this is planned to happen soon
  • [jbelamaric] Need to be careful around in
  • interdependencies such that types can be used independently. Understanding is that today they are more intertwined.
    • [vincepri] Problem with complete separation is it leads to fragmentation. The cluster object is an overloaded type, and hence creating a separated infrastructure type.
    • [jbelamaric] how do we keep this clean and not bake too many opinions into the specification
    • [vincepri] likely that the extension mechanism workstream will address this.
  • Use Case proposals for Machines without Clusters (in favor of loose coupling)
    • As an operator, I want to deploy Machines that aren’t part of any Clusters.
      • (dhellmann) in MetalKube, we used a different object to represent the “host” that can be provisioned and can be linked to a Machine, but can also be used independently of a Machine or Cluster -
    • [jbelamaric] As a provider, I don’t agree with how OSS has defined Cluster and want to use my own implementation.
      • (dhellmann) Which aspects have you found it useful to change?
    • As an operator, I want to adopt Cluster API one piece at a time. I want to adopt Machine before I use ControlPlane or Cluster.
  • [david watson] Historically, avoided any semantics not universal across providers. Probably want to enable higher level semantics going forward, even if they aren’t completely universal across providers (e.g. managing the control plane). We need to review our goals, so we don’t go in circles on topics like this Cluster discuss that has come up over and over in the last 18 months.
    • (general approval of approach)
  • [jbelamaric] I don’t see the value in Cluster object, and I’ll have to double-check that it’s optional. The value of Machine is clear. Need to make sure that the conditions imposed by adopting each piece of Cluster API are worth the benefits. Because so much is pushed into the Provider Config, it’s hard to see the value of the Cluster object.
    • [jason detiberus] Adding owner references to the Cluster object recently allowed handling cascading deletions. Someday, I hope that statuses will be bubbled up to Cluster – so users will be able to see aggregate state via Cluster objects. And a single place to delete clusters.
    • [jbelamaric] We all think in terms of clusters; there will be various infrastructure per-cluster. Is it possible to build more semantics and more value in Cluster, or will that add too much opinion into the spec?
    • [pablo] Gardener project: conclusion that they needed an object to anchor some meta-data about cluster, like status and end-points to manage it. All this makes tooling easier to develop: tooling can understand what actions it can take and how access the status for the cluster. It is useful even for clusters that were not created by Gardner.
    • [vince] useful to have an umbrella type. Goal for Cluster API is to manage K8s Clusters. Don’t want Machines so loose. Cluster will provide a better UX, since we’re only doing k8s clusters. A thing we’re missing now is more streamlined UX across providers; Cluster could offer that. Cluster type today is overloaded, undefined what it should/shouldn’t do. Would like to see boundaries between the types and their relationships defined by this workstream.
  • Next follow-up: new google doc with KEP template
  • (yay! Ended early!) :slight_smile:

The proposal working document has been created and it’s open for collaboration, please add new items, use cases, goals, and non goals! This proposal should be a high-level overview for Cluster API types, requirements, boundaries, goals, and non-goals.