[TOC Meeting] TOC + TAG Leads @ KubeCon NA 2024

[mrbobbytables]

Date, time and location information has been sent to the TAG Chair email list.

Agenda

• Review / deep dive on the state of cloud native reports from TAGs (please reply to this issue with links to them)
• Review how TAGs can help with DTR/GTR

[TheFoxAtWork]

TAG Environmental Sustainability's State of Cloud Native

[srust]

CNCF TOC: State of the Ecosystem Assessment - TAG Runtime

[chira001]

TAG Storage – State of the Ecosystem 2024

[mnm678]

TAG Security 2024 State of the Ecosystem

[jberkus]

TAG-CS State of the Ecosystem

[eddie-knight]

TAG Security State of the Ecosystem

[roberthstrand]

TAG App Delivery state of the Ecosystem (Slight updates needed after the meeting).

[TheFoxAtWork]

The TOC and TAG chairs met to discuss the findings from the state of ecosystem reports. The TOC propose some restructuring of the TAGs and Working Groups, TAG Chairs raised valid concerns around redistributing work too much in some areas or too little in others. All confirmed there are more cross functional areas of work than previously that touch on multiple domains. TAGS were asked to take the slides back (Karena will share) to their groups and discuss what makes sense. Some points of consideration:

• Development and Workloads
• Compliance and Policy
• Chair mentorship for transition

Other items discussed Standing weekly project presentation meetings across TAGs and invite the end users. 5 min preso.

Joint DTRs across TAGs for incubation and graduation and Triage

[angellk]

During the TOC + TAG Leads Meeting, the TOC presented a TAG Reboot proposal.

In preparing the proposal, the TOC reviewed:

• the State of the Ecosystem reports,
• current state of the TAG leadership,
• current TAG alignment to TAG charters,
• current TAG alignment to TOC requirements and asks,
• overall requirements of the Cloud Native ecosystem.

The TOC has asked the TAG leads to review the reboot proposal with each of their TAGs and Working Groups.

The proposed new working groups and topic areas as discussed are in this presentation.

The proposed new TAG structure is:

• TAG EPOC (Energy, Performance, Observability, Cost)
  • Optimizing Energy Resources
  • Observability
  • Performance
• TAG Infrastructure
  • Multicluster Management at the Infrastructure Level
  • Bare Metal
  • Infrastructure Lifecycle
  • Edge
  • Network
  • Service Mesh
• TAG Data + Storage
  • Data
  • Storage
  • Databases
• TAG Applications + Workloads (alternative name proposed: TAG Development + Workloads)
  • Application Development
  • Workload Scheduling
  • AI Workload Development
  • Multicluster Application Management
• TAG Application Delivery
  • GitOps
  • MLOps
  • Platforms
• TAG Runtime
  • Wasm
  • Batch
  • AI Compute
  • Special Purpose Operating System
• TAG Security (remains as-is)
• TAG Contributor Strategy (remains as-is)

During the TOC + TAG Leads meetings the following was brought up:

• TAG EPOC can be seen as similar to TAG Security and the assessments that TAG provides to benefit the ecosystem
• TAG Applications + Workloads may be too similar (and confusing) to TAG App Delivery - suggested proposed name: TAG Development + Workloads
• Compliance is a topic area that has a lot of sub-projects and overlap with other areas
  • There is security compliance and general compliance
  • Perhaps Compliance and Policy can be combined into a Working Group
• Working Group Health
  • Some TAG have working groups that should be closed (if they remained as-is)
  • TAGs should look at TAG Security and TAG Storage for low overhead WGs
  • TAGs should look assess whether a working group needs to be created or whether the work is better driven by a TAG Tech Lead
• TAG Leadership Terms
  • With the TAG Reboot, the oldest serving Chair and role's term will automatically come up for re-election
  • The current Chair may run again, as desired
  • With the chair ladder WG being finalized, the terms will be staggered
  • The chair ladder process will need to identify how the new chairs and TLs are trained and supported

[danieloh30]

Looks great to me! I agree with the similarity and confusion across 3 TAGs - TAG Applications + Workloads, TAG Application Delivery, and TAG Runtime. In my understanding, TAG Runtime aims to introduce the cloud-native runtimes(or VM, stack) to eventually deploy/run polyglot applications which means it might be better to name them with "TAG Application Runtimes" (maybe I'm wrong!) So it may be categorized into "Application Development" and "Application Platform (or Foundation)":

• TAG Application Development

  • Application Workload (Application Development + AI Workload Development)
  • Workload Scheduling
  • Multicluster Application Management

• TAG Application Platform (Foundation)

  • AI Ops (GitOps + MLOps + AI Compute)
  • Platform Engineering (Currently Platforms)
  • Wasm
  • Batch
  • Special Purpose Operating System

I'm not sure if there's a limit WG count in each TAG like max 4 WGs.

I'm happy to discuss this further if you have any questions. Please feel free to disregard my suggestions if they don't accurately reflect the original reboot intentions.

[raravena80]

Thanks for the proposal @angellk.

I think these look good to me:

• TAG Security
• TAG Contributor Strategy
• TAG Data + Storage
• TAG Infrastructure
• TAG EPOC

For the rest, I have a few questions on the AI (as in Artificial Intelligence) items and WGs:

• Could we define what AI Workload Development in TAG Applications + Workloads is? Sounds similar to MLOps (which is in another TAG: TAG Application Delivery), and there is considerable overlap with Batch and AI Compute (which are in TAG-Runtime)
• Also, MLOps is pretty wide, I see it as the intersection of cloud native and all these (but not limited): Notebook dev, data prep, DAG workflows, feature store, model registry (i.e OCI compliance), inference/serving, batch inference, autoML, HPC networking/filesystems/storage, scheduling, model training, model observability/trustworthiness/security, experiment tracking, etc -- Sounds like this spans multiple TAGs so we may need to associate the term with multiple TAGs or remove it altogether(?)
  • MLOps is also at the core of the CN AI Whitepaper and the CN AI WG.
• What's the plan for the existing Working Groups that will not be closed? Will they be independent entities from the TAGs? or will they be associated to TAGs (single/multiple) or will they be just associated with the TOC (or just CNCF in general)? or TBD?

Thanks!

[kdubois]

This is a great initiative and seems like a much more logical subdivision of concerns!

A few thoughts: With regards to TAG Applications + Workloads, "Workload Scheduling" seems a little ambiguous to me. Is this referring to eg. jobs/cron jobs? If so, perhaps it would make more sense to move this to the Runtimes TAG.

In TAG App Delivery, shouldn't there also be a Continuous Integration workgroup?

[roberthstrand]

Based on feedback from various active working group and TAG members, and discussions with the technical leads and chairs, I feel that splitting up the working groups is not in the best interest of our group.

Ever since the meeting on-site at KubeCon, I have been trying to think what problem splitting the group up will solve. When I look at the now proposed two TAGs of Workloads and App Delivery, I would consider all of those topics (mostly) to fall under the responsibility of (in many cases) a singular team at an organization.

The way that I read this list, it seems to be a mix between areas of responsibility and current working groups. The working groups we have been created to solve different aspects of the common goal of the group, and maybe we should focus on changing the name of the TAG to reflect this rather than move groups across various arbitrary groups.

There is no way to split up the various domains without overlapping between them, and in that sense I don't mind there being a TAG Infrastructure. Having that group take care of "Multicluster management at infra level" does make sense, but moving app management away from our TAG will in my opinion make it even harder for people to figure out where to contribute.

As for renaming, I have a bunch of ideas, but I don't want to throw too much info into the discussion right now.

[chira001]

• TAG Leadership Terms

  • With the TAG Reboot, the oldest serving Chair and role's term will automatically come up for re-election
  • The current Chair may run again, as desired
  • With the chair ladder WG being finalized, the terms will be staggered
  • The chair ladder process will need to identify how the new chairs and TLs are trained and supported

We should take a few minutes at the next TOC call to figure out the logistics for automatic elections.

Currently the charter specifies that for existing TAGs, the TAG leadership presents candidates to the TOC for election. However, we are all aware of the shortage of candidates, which has led to the extended term times. Perhaps if we are to have elections in the absence of candidates nominated by TAG leadership, we may need to establish a simple set of nomination and qualification processes for TAG chair candidates. I'd be happy to propose some minor changes to the charter operating model to enable this if appropriate.

[leonardpahlke]

What are the reasons and goals of the restructuring?

• TAGs do not reflect the landscape
• Some TAGs lack engagement (leadership & contribution)
• more?

[salaboy]

Folks, I like the proposal to restructure the TAGs, I appreciate the effort there. But, being part of the Application Development WG and looking at this proposal:

- TAG Applications + Workloads (alternative name proposed: TAG Development + Workloads)
  - Application Development
  - Workload Scheduling
  - AI Workload Development
  - Multicluster Application Management
- TAG Application Delivery
  - GitOps
  - MLOps
  - Platforms

I feel that we will be splitting once again Platforms and Application Developers, which seems to defeat the purpose. I firmly believe that App Devs and Platforms should be together. It sounds like GitOps and MLOps are very close and also related to Multicluster Application Management and Workload Scheduling.

In my head, something like this make sense:

• TAG Ops (maybe another name)
  • GitOps WG
  • MLOps WG
  • Workload + AI Workload + Batch Jobs Scheduling WG
  • Multicluster Application Management WG
• TAG Platforms Enablement
  • Platform Engineering WG
  • Application Development and Developer Experience WG
  • AI Development WG

I totally understand that everybody looking at the TAG restructuring will have different opinions on the subject, so as soon as we make sure that WG collaborate between each other, the names and hierarchies should help newcomers to understand the focus of each TAG and WG.

Hopefully this makes sense @angellk @roberthstrand

[mbianchidev]

The idea of adding terms and restructuring is great, kudos! I'm now going to provide a focused feedback on the TAG and WG where I'm more active in.

As active member of the WG Platforms, I strongly believe the WG (currently under TAG App Delivery) should become a TAG. So, I kinda agree with @salaboy here, but my ideal outcome looks more like:

- TAG Platform Engineering
Platform Enablement WG (where people continue paap, paap-research and all the current subprojects)
Application Development and Developer Experience WG
MLOps WG -> Renamed "AI Platforms" and contains every non-data AI WG

- TAG Application Delivery
GitOps WG
App Development WG
Artifacts WG
Every other non-dead WG if any (they should be all afaik)

or

- TAG Platform Engineering
Platform Enablement WG 
Application Development and Developer Experience WG
AI Platforms WG
GitOps WG
App Development WG
Platform Artifacts WG

Maybe this rename scenario has too many WGs?

The rationale behind my idea is the following: The Platforms WG is currently very active and having quite some sub-WGs and projects, so the interest is definitely there and we have the urge for more structure and resources. We are also mature enough in our processes to be promoted as a separate TAG.

I also shared the outline of this idea (in person) with many members of the WG Platforms at KubeCon NA, plus @caniszczyk and @rochaporto (at KCD Denmark), receiving an overall positive feedback - nothing binding or anything but a sign that this new TAG makes sense from the outside point of view too.

[alolita]

Dear TOC,

The TAG Observability leads (chairs, TLs) were unable to join this discussion at KubeCon NA 2024 due to talk session conflicts.

The TAG Observability leads would like to discuss with the TOC, the suggested proposal of combining 4 areas (EPOC) into one TAG since these are significantly diverse areas and have their own areas of expert understanding. We would like to better understand how the mechanics of such a merger would work.

TAG EPOC (Energy, Performance, Observability, Cost) Optimizing Energy Resources Observability Performance

Please let us know how we should proceed for this discussion.