Cluster API Weekly Meeting


We’ll use this topic to post community meeting notes and videos.


pinned #2


April 10, 2019

  • [frobware] PR for kubernetes/autoscaler for cluster-api based cloudprovider
    • AI: Talk with SIG on Monday to move forward with PR
  • [timothysc] Group topic about scope and purpose of the requirements exercise.
    • They are more of a refinement of mission and scope to help serve as guardrails for v1alpha2+ conversations.
    • Proposing 1 week timeout until merge.
    • Note: This will be a living document and will be refined over time.
    • PR:
    • Concerns:
      • Should make it clear which parts are requirements for the API, reference provider implementation or link to external provider.
  • PSA 1 [timothysc] There is a new SCL contributor meeting this Friday, for those who are new to SCL I recommend coming to that session.
  • PSA 2 [timothysc] There is a SCL session open for KubeConEU
    • During the Contributor Summit
    • May spin off sub-sessions for Cluster API
  • PSA 3 [detiber] Cluster API t-shirts for KubeCon EU designed by the CNCF, which you can pick up from VMware at Kubecon EU. If you are not going and would like a tee, please reach out to Jason DeTiberus privately with mailing address details.
  • [detiber] Repository owners and security contacts update
    • These have been woefully out of date.
    • PR formalises existing extended ACLs for the repository
    • Timeout of 1 week for lazy consensus
  • [ncdc] Communication methods
    • Not everyone can make Zoom meetings (time zones are hard)
    • How can we make sure everyone who wants to participate is able to?
    • Should we consider creating a Cluster API Google Group or other project-focused forum/mailing list? I.e. that we split out of SIG Cluster Lifecycle.
      • There isn’t precedent for this, and would need discussion with SIG Contributor Experience, and docs would need to be updated.
      • Could use for targeted discussion, and has precedent around usage.
      • Alternative to Github needed because not everything is an issue, and good to have threading, but there is a tradeoff as to fragmenting the discussion.
      • Higher level design discussions are useful to have in a threaded conversation environment, but the end result should be finalised via Github.
    • We need to avoid synchronous discussion such as Slack and Zoom as they make poor records of discussion.
    • How can we best collaborate with people who may not be able to access Google Docs?
      • Standard operating procedure elsewhere has been that people have been able to get in contact.
      • [naadir]
        • Announcements go to mailing list & Discuss.
        • High-level discussions happen in forum.
        • CAEPs and execution discussions happen on GitHub.
        • AI: Vince to formalise
  • [vincepri] Workstreams and CAEPs
    • CAEP: Cluster API Enhancement Proposal
      • (dhellmann) The pronunciation of this is really close to KEP (as Vince just demonstrated). How about “CAPE”? “Cluster API Proposed Enhancement”?
    • CAEP Template
    • GitHub projects
    • Facilitator role
      • Not be the owner.
      • Coordinate meeting times.
      • Facilitate discussion.
        • Make sure everyone is able to have their opinion heard.
        • In zoom meetings, not everyone is able to have their opinion heard. Consider using zoom’s “raise hand” feature.
      • Facilitators must provide a read out to this group. (Share updates with the broader community at the weekly meeting.)
      • [Naadir] Facilitation resource sheet
    • Participation rules
      • Zoom — Raise hand feature
    • AI for facilitators
      • Send out a doodle in Slack/Mailing List/Discuss
      • Schedule kickoff meeting
  • Workstream updates template
    • [extension-mechanism]
      • How does the Cluster API interact with Cluster API providers?
      • Webhooks, gRPC, or independently reconciled CRDs
      • Compare and contrast approaches.
      • Choose one approach or potentially multiple approaches.
    • [data-model]
      • Cover all things related to changing existing types (Machine, Cluster) and introducing new types (e.g. ControlPlane).
    • [controlplane-lifecycle-management]
      • Make the cluster control plane a first-class resource.
      • Support scaling up/down of control plane
      • Support control plane upgrade
    • [node-lifecycle-management]
      • Design and implement a reference implementation that can be used by any provider
      • Likely based on kubeadm
      • Figure out the extension points for bootstrapping a control plane or "worker" node
      • Interactions with autoscaler
    • Concerns
      • What is in and out of scope?
        • [Tim] Let the workstreams decide their scope
      • Maybe infrastructure is a separate workstream, but possible overlap with the data model in terms of the scope.
      • That discussions do not become too fragmented.
  • [vincepri] User stories
    • Take the use cases Google Doc and put it into e.g.
    • Move use cases from the brainstorming doc into CAEPs as appropriate


Wed 17 April 2019 - 10am Pacific