I spoke to a Kubernetes end user company who are currently planning their 2019 technical architecture. The CTO asked me whether projects had feature roadmaps for the next six months - one year which they can incorporate into their planning. They are a small company with four infrastructure engineers, so lack the time to engage directly with each project.

I propose that the graduation criteria should require projects to publish a six month feature roadmap. This provides visibility for planning and also allows users to give early feedback. The format could be a simple file in Github.

Feedback and thoughts are very welcome. @caniszczyk @monadic

Per the charter, the CNCF TOC is responsible for:

• approving new projects within the scope for CNCF set by the Governing Board, and create a conceptual architecture for the projects
• aligning projects, removing or archiving projects,

This issue will track coming up with a process to accept projects within the CNCF.

At today's @cncf/toc call the TOC wants to hold a vote amongst itself and the TOC Contributors (https://github.com/cncf/toc/blob/master/CONTRIBUTORS.md):

• Labs
• Launchpad
• Prototype
• Sandbox
• Workshop

On the March 20th meeting, the TOC will use the results of this vote to make a final decision amongst themselves on whether we stick with the name or update it.

Was there anything else I missed @monadic ?

etcd is a distributed, reliable, consistent, key-value store for the most critical data of a distributed system. It is used by several CNCF projects, particularly Kubernetes, as well as many other projects in the broader cloud-native ecosystem. Red Hat supports etcd as a part of OpenShift. We do not have plans to productize etcd independently.

The etcd team believes that this project aligns well with all three goals in section 1 of the CNCF Charter by providing a consistent information store for all other cloud microservices. Per 1(a) etcd is generally distributed and deployed in containers; per 1(b) it supports dynamic management by providing a place to store and retrieve configuration and location information; per 1(c) it provides only consistent data storage, and allows other microservices to wrap its storage rather than implementing their own.

Given its already wide industry adoption, the team hopes that moving it to CNCF ownership will encourage a broader community to contribute to, maintain, and build on etcd as a foundation for both new and existing cloud-native projects.

Website: https://etcd.io
GitHub: https://github.com/coreos/etcd (soon to move to a new namespace)
License: Apache License, Version 2.0

The TOC is entitled to selecting 2 TOC members of the 9 (known as TOC-selected seats)

https://github.com/cncf/toc/blob/master/process/election-schedule.md

One of these TOC-selected seats frees up on 3/17/2019 held by Quinton

Buildpacks replace Dockerfiles in the app development lifecycle with a higher level of abstraction. In doing so, they provide a balance of control that reduces the operational burden on developers and supports enterprise operators who manage apps at scale. Buildpacks ensure that apps meet security and compliance requirements without developer intervention. They provide automated delivery of both OS-level and application-level dependency upgrades, efficiently handling day-2 app operations that are often difficult to manage with Dockerfiles.

First conceived in 2012, buildpacks have provided an opinionated solution for building cloud apps on Heroku, Cloud Foundry, GitLab, Deis, Dokku, and other platforms. Heroku and Pivotal are actively collaborating on a next-generation buildpack API that uses existing standards (such as the OCI image format) to bring buildpacks to cloud platforms that support Docker or OCI images. This new API also incorporates feedback from years of assisting our customers operate buildpacks in production.

We believe this project fits well within the CNCF by directly supporting the CNCF's mission statement of supporting cloud native systems. The next generation of buildpacks will aid developers and operators in packaging applications into containers (1a), allow operators to efficiently manage the infrastructure necessary to keep application dependencies updated (1b), and are available via well-defined interfaces (1c).

By becoming a CNCF project, we hope to greatly improve buildpack interoperability between platforms and attract a wide community of contributors, including buildpack creators and maintainers.

GitHub: https://github.com/buildpack/resources
License: Apache License, Version 2.0
(Website will be packs.sh.)

@kenowens12 and a bunch of other folks have done excellent work on a reference architecture:
https://docs.google.com/presentation/d/1uMw2wkK0ubmc3khxqIuxK_rLK_wN89tNCnK7gDmTGR8/edit#slide=id.g15843037bc_2_6

The last TOC meeting there was a request to call a vote to approve and finalize this.

Who, What, Why?



Dragonfly is an intelligent P2P based container image distribution system. It provides a native image distribution solution for cloud native applications.
Compared to traditional central server mode, Dragonfly integrates P2P and CDN technologies, as well as multiple intelligent ways to solve image distribution challenges. These challenges include: intelligent compression, intelligent flow control, intelligent scheduling, etc. It solves the efficiency problems especially for large distributions while guaranteeing the security and control the data flow of the whole transmission.


GitHub: https://github.com/alibaba/Dragonfly
Website: https://alibaba.github.io/Dragonfly
License: Apache 2.0



Cloud-Native and CNCF Alignment



Dragonfly's mission is to help users to improve image distribution efficiency in cloud native use cases .

Users are looking for a solution to guarantee all aspects of image distribution, such as efficiency, security and scheduling. Dragonfly addresses all these demands and currently has the following adaptors:



• Alibaba Group (All image distribution and 90% file distribution);

• China Mobile (The leading telecommunications services provider in China, 7000 containers on 1000 nodes all with dragonfly);

• Didi Chuxing (The World’s leading mobile transportation platform);

• Ant Finacial (The largest company provides inclusive financial services, 90% file distribution);

• iFLYTEK (The leading intelligent speech and language enterprise in China);
  
* and so on.



Donation Goals



Our primary goal of contributing Dragonfly to CNCF is to help container communities improve the image distribution as well as other tasks in image management. Donating Dragonfly is also an attempt to standardize image management for Kubernetes ecosystem. Meanwhile, the CNCF community can help us draw attention and contributors into this project.



We are sincerely looking forward to having an opportunity to discuss Dragonfly with the TOC.

Hi CNCF TOC,
I am @wu-sheng. I want to proposal the sky-walking to join the CNCF hosted projects. This is a project, I found two years ago, from Chinese open source community, hosted it in github since 2015, and now the team want it to join CNCF.

Skywalking is an APM, Application Performance Monitoring, for distributed system, and also definitely a distributed tracing system. I am a member and contributor of OpenTracing, and also an OTIAB member of OpenTracing. So in 2016, I have brought the sky-walking into the OpenTracing Supported Tracer list. And @bhs knows a lot stories about me and sky-walking with OpenTracing Community. Also contribute a little things for openmessage @vongosling

I am also an envanglist of OpenTracing:

• Provided and maintain formal zh (Chinese) translation of the opentracing/specification: https://github.com/opentracing-contrib/opentracing-specification-zh
• Gave the speeches about introducing CNCF and OpenTracing twice this year at Qcon Beijing 2017 and CNUTCon Shanghai 2017.
• Brought Motan, Hprose RPC Frameworks into OpenTracing Supported framework list.

Skywalking, today, has nearly 1.3K star, 400+ forks, 2300+ commits, 16 releases in GitHub. And has nearly 20 contributors. At early days of the project, some people doesn't contribute features from github, so I make a list on README.

Skywalking is a very special, and even unique big open source project in China community. We have no company background, just started and developed in the open source community only. All the PMC members(@wu-sheng @pengys5, @ascrutae) and contributors dedicate a lot of energy, time, enthusiasm for this project.

As an APM, skywalking provided these features:

• Dynamic topological graph of application clusters relationship. Based on tracing Spring Cloud, Dubbo(Alibaba), Motan(Sina) and many RPC frameworks. Check the supported list here: https://github.com/wu-sheng/sky-walking/wiki/3.2-supported-list
• Distributed Tracing, of course. Support auto instrumentation and manual instrumentation(OpenTracing API and Skywalking Annotation). I think we are the only open source project support them in the same
  tracing context, interop with each other, only instana support this in their commercial product.
• Dynamic service relationship, or dependency tree.
• JVM metrics. We are now a Java APM, so JVM metrics are very important. We also create a view including these metrics and TPS/ResponseTime in a time line, in order to help users to find out whether the JVM metrics influence the performance or not. This is the only feature related to JVM-platform.

You can see the screenshots about these features in our README page.

Skywalking built for Cloud Native applications, specially for docker-based env.

• In that env, the IP/hostname from OS is not the ip/name used for providing services, e.g. use service mesh like linkerd. Skywalking can adapt and work well.
• In our project, we provided Java auto instrumentation agent, at the same time we also provided gRPC and RESTful service to integrate other agent from communities. I have confirmed, people used PHP, golang agents, and working(interop) with our java agent to monitor their system.

@terrymanu 's dangdang.com team are using skywalking for their container based and multi languages system.

These companies are using skywalking for their OSS:

• dangdang.com Top level e-commerce china. (NYSE:DANG)
• China Unicom Telecom System(WIP)
• 数人云, https://www.shurenyun.com/
• Asisinfo, http://www.asiainfo.com/
• Tydic, https://www.tydic.com/
• 印记, http://www.yinjiyun.cn/
• 中数智慧, https://www.bidata.com.cn/
• vbill, https://www.vbill.cn/

BTW, the project is licensed by GPLv3, and in my personal repository. We can discuss the details later. The GPLv3 protected our project in early days, if we can join the CNCF, I am sure that Apache 2.0 is OK for our PMC members and contributors.

These people of other projects you can ask about our project:

• @bhs OpenTracing
• @adriancole Zipkin
• @WillemJiang Apache member and Huawei open source project team leader
• @vongosling Apache Rocketmq Team Leader&Co creator, Linux openmessage initiator
• @terrymanu Dangdang Architecture Director

At last, I truely hope we can bring skywalking, the most popular open source APM in China, into CNCF.

Project Description

ORY Hydra is an OpenID Certified OAuth 2.0 and OpenID Connect open source server. It implements best practices for access control security and builds on top of open standards and protocols. Contrary to existing projects in this space, ORY Hydra defines a clear boundary around OAuth 2.0 and OpenID Connect and does not aim to solve all authentication, authorization, and access control issues in one stack.

ORY builds a range of open source services that individually tackle these issues within a clear defined boundary. Each service, including ORY Hydra, solves the task at hand stand-alone. The services can also be combined with other ORY projects or other CNCF projects, such as OPA, to build a hardened, enterprise-grade access control system.

ORY Hydra is written in Go and compiles to a static ~12 MB size binary without dependencies that runs on any operating system with a minimal CPU & memory footprint. Its twelve-factor architecture allows horizontal (auto-)scaling and makes it natively compatible with application platforms such as Kubernetes, CloudFoundry, Heroku, and others.

In contrast to existing projects, this software focuses on interoperability with any authentication system by implementing a redirection-based flow (“user login and consent flow”). Popular “full-stack” auth* solutions provide strongly opinionated customization logic including template engines, plugin systems, and scripting languages that are often hard to test and require specific domain-knowledge of the system and language in place.

Instead, ORY Hydra relies on Layer 7 protocols (HTTP/HTTPS) so developers can plan, develop, test, and operate custom business logic and UIs in the language, frameworks, and with development processes they prefer.

Preferred Maturity Level: Sandbox
License: Apache License 2.0

Community

ORY Hydra has evolved, over the course of three years, to a trusted project for developers looking to solve API access control and delegation of authorization (OAuth 2.0) as well as authentication (OpenID Connect).

Community and adoption is growing fast. We are open and willing to share detailed telemetry data insights with the TOC. Telemetry data has voluntarily been submitted to us.

Source control

GitHub: https://github.com/ory/hydra

External Dependencies

$ licenses github.com/ory/hydra
github.com/ory/hydra                                                                 Apache License 2.0
github.com/ory/hydra/vendor/github.com/asaskevich/govalidator                        MIT License
github.com/ory/hydra/vendor/github.com/beorn7/perks/quantile                         MIT License (98%)
github.com/ory/hydra/vendor/github.com/davecgh/go-spew/spew                          ISC License (98%)
github.com/ory/hydra/vendor/github.com/dgrijalva/jwt-go                              MIT License (98%)
github.com/ory/hydra/vendor/github.com/fsnotify/fsnotify                             BSD 3-clause "New" or "Revised" License (96%)
github.com/ory/hydra/vendor/github.com/go-resty/resty                                MIT License
github.com/ory/hydra/vendor/github.com/go-sql-driver/mysql                           Mozilla Public License 2.0
github.com/ory/hydra/vendor/github.com/golang/gddo/httputil/header                   BSD 3-clause "New" or "Revised" License (96%)
github.com/ory/hydra/vendor/github.com/golang/protobuf/proto                         BSD 3-clause "New" or "Revised" License (92%)
github.com/ory/hydra/vendor/github.com/gorilla/context                               BSD 3-clause "New" or "Revised" License (96%)
github.com/ory/hydra/vendor/github.com/gorilla/securecookie                          BSD 3-clause "New" or "Revised" License (96%)
github.com/ory/hydra/vendor/github.com/gorilla/sessions                              BSD 3-clause "New" or "Revised" License (96%)
github.com/ory/hydra/vendor/github.com/gtank/cryptopasta                             Creative Commons Zero v1.0 Universal (96%)
github.com/ory/hydra/vendor/github.com/hashicorp/golang-lru/simplelru                Mozilla Public License 2.0
github.com/ory/hydra/vendor/github.com/hashicorp/hcl                                 Mozilla Public License 2.0
github.com/ory/hydra/vendor/github.com/imdario/mergo                                 BSD 3-clause "New" or "Revised" License (96%)
github.com/ory/hydra/vendor/github.com/jmoiron/sqlx/reflectx                         MIT License (98%)
github.com/ory/hydra/vendor/github.com/julienschmidt/httprouter                      BSD 3-clause "New" or "Revised" License (95%)
github.com/ory/hydra/vendor/github.com/lib/pq/oid                                    MIT License (98%)
github.com/ory/hydra/vendor/github.com/magiconair/properties                         BSD 2-clause "Simplified" License (95%)
github.com/ory/hydra/vendor/github.com/matttproud/golang_protobuf_extensions/pbutil  Apache License 2.0
github.com/ory/hydra/vendor/github.com/mendsley/gojwk                                BSD 2-clause "Simplified" License (96%)
github.com/ory/hydra/vendor/github.com/mitchellh/mapstructure                        MIT License
github.com/ory/hydra/vendor/github.com/mohae/deepcopy                                MIT License
github.com/ory/hydra/vendor/github.com/oleiade/reflections                           MIT License
github.com/ory/hydra/vendor/github.com/ory/fosite                                    Apache License 2.0
github.com/ory/hydra/vendor/github.com/ory/go-convenience                            MIT License
github.com/ory/hydra/vendor/github.com/ory/herodot                                   Apache License 2.0
github.com/ory/hydra/vendor/github.com/ory/ladon                                     Apache License 2.0
github.com/ory/hydra/vendor/github.com/ory/pagination                                Apache License 2.0
github.com/ory/hydra/vendor/github.com/pborman/uuid                                  BSD 3-clause "New" or "Revised" License (96%)
github.com/ory/hydra/vendor/github.com/pelletier/go-toml                             MIT License
github.com/ory/hydra/vendor/github.com/pkg/errors                                    BSD 2-clause "Simplified" License
github.com/ory/hydra/vendor/github.com/pkg/profile                                   BSD 2-clause "Simplified" License (97%)
github.com/ory/hydra/vendor/github.com/pmezard/go-difflib/difflib                    BSD 3-clause "New" or "Revised" License (98%)
github.com/ory/hydra/vendor/github.com/prometheus/client_golang/prometheus/promhttp  Apache License 2.0
github.com/ory/hydra/vendor/github.com/prometheus/client_model/go                    Apache License 2.0
github.com/ory/hydra/vendor/github.com/prometheus/common                             Apache License 2.0
github.com/ory/hydra/vendor/github.com/prometheus/procfs                             Apache License 2.0
github.com/ory/hydra/vendor/github.com/rubenv/sql-migrate                            MIT License
github.com/ory/hydra/vendor/github.com/rubenv/sql-migrate/sqlparse                   MIT License
github.com/ory/hydra/vendor/github.com/sirupsen/logrus                               MIT License
github.com/ory/hydra/vendor/github.com/spf13/afero/mem                               Apache License 2.0 (95%)
github.com/ory/hydra/vendor/github.com/spf13/cast                                    MIT License
github.com/ory/hydra/vendor/github.com/spf13/cobra                                   Apache License 2.0 (95%)
github.com/ory/hydra/vendor/github.com/spf13/jwalterweatherman                       MIT License
github.com/ory/hydra/vendor/github.com/spf13/pflag                                   BSD 3-clause "New" or "Revised" License (96%)
github.com/ory/hydra/vendor/github.com/spf13/viper                                   MIT License
github.com/ory/hydra/vendor/github.com/stretchr/testify                              MIT License (94%)
github.com/ory/hydra/vendor/github.com/toqueteos/webbrowser                          MIT License
github.com/ory/hydra/vendor/golang.org/x/crypto                                      BSD 3-clause "New" or "Revised" License (96%)
github.com/ory/hydra/vendor/golang.org/x/net                                         BSD 3-clause "New" or "Revised" License (96%)
github.com/ory/hydra/vendor/golang.org/x/oauth2                                      BSD 3-clause "New" or "Revised" License (96%)
github.com/ory/hydra/vendor/golang.org/x/sys/unix                                    BSD 3-clause "New" or "Revised" License (96%)
github.com/ory/hydra/vendor/golang.org/x/text                                        BSD 3-clause "New" or "Revised" License (96%)
github.com/ory/hydra/vendor/gopkg.in/gorp.v1                                         MIT License (97%)
github.com/ory/hydra/vendor/gopkg.in/square/go-jose.v2/cipher                        Apache License 2.0
github.com/ory/hydra/vendor/gopkg.in/square/go-jose.v2/json                          BSD 3-clause "New" or "Revised" License (96%)
github.com/ory/hydra/vendor/gopkg.in/yaml.v2                                         Apache License 2.0

Release methodology

We use semver semantics for version tags and trigger automated test and build pipelines for binaries, Docker Images, SDKs (swagger-codegen currently for Node, PHP, Go), docs, and changelogs.

Releases happen often and breaking changes are documented extensively.

Releases are announced via the ORY Security Newsletter.

Community Size and any Existing Sponsorship

Unfortunately, most companies do not wish to be identified publicly. They fear that disclosed vulnerabilities leave them open to attackers. We are allowed to disclose them privately with the TOC on request. The adopters whose decision makers have agreed to be identified publicly include:

• Gruppe Deutsche Börse AG (German Stock Exchange operating EUREX and the Frankfurt Exchange)
• Raspberry PI Foundation
• Arduino

We are currently working with existing adopters on publicly disclosing their use case.

Communication channels

• GitHub
• Discord
• Discourse

Documentation

• Developer Guide
• REST API

Statement on alignment with CNCF mission

Access Control is a topic that every developer has to solve. In the past, one had to rely on libraries and middleware e.g. rbac for the language at hand. With k8s and the service mesh, this landscape is quickly changing due to CNCF projects like OPA, Istio Auth* patterns, Kubernetes RBAC, and other systems.

ORY's commitment is to build an open source platform that solves easy and hard access control scenarios while providing maximum security and reliability. Access control should not be a "least effort" solution, rather something that is focused, open source, peer-review, and relies on open standards.

With this vision in mind we believe that ORY Hydra fits the CNCF's mission. Apart from technological decision we are confident that the concept of a lean, API-first OAuth 2.0 / OpenID Connect solution fits the vision and the idea of the CNCF mission.

We believe strongly that the ORY ecosystem, including existing and future projects, greatly improves cloud native offerings for developers and companies alike.

Thank you for reviewing this application!

I will leave this to you all as my last request before stepping aside from caring about this.

Please consider removing inception. It was described to me as being there mainly for things like "linkerd" so service meshes before service meshes were cool. Now service meshes are cool. Actually I can't stop hearing about service meshes. Everyone is drinking the service mesh koolaid.

Can you directly tie the service mesh awareness now to accepting linkerd? because I honestly think it was more Envoys release that caused service meshes to become A Thing ™️

I think the inception phase is just plain wrong. Open source is awesome because projects that are good and fill a real need get traction. Without a doubt they get traction by being open source and actually filling a need people have. Look at docker, or literally anything in the explore section of github https://github.com/explore. Projects get organic growth when they are good! I am not buying this whole "we need to put it in inception so people notice it" thing. That's quite frankly BS. If it doesn't have traction maybe that's because no one needs it.

Inception feels like an attempt to play god. Or become a startup incubator. This should not be the role of the foundation to bootstrap growth of random open source projects. Let the projects grow organically and when they have so much growth they cannot handle it, then let them join.

Not that I have a project with enough users, but if I did I'd honestly consider adding it to a real foundation like Software Conservancy and not Linux foundation derivative which are all 501(c)(6) which is a trade association (see https://www.irs.gov/charities-non-profits/other-non-profits/business-leagues)

In the words of Regina George "stop trying to make fetch happen". It will happen if it happens. Thanks.

It's great that we now have a formal project proposal process, one thing we haven't done yet is to clarify acceptance criteria for new technologies to include in CNCF (outside of what is specified in the charter: https://cncf.io/governance). We can choose to do this as an amendment section to the project proposal process or include in another document.

Who, what, why?

OpenMetrics aims to evolve the Prometheus exposition format into its own standard to help adoption. The project is currently nearing technical completion after which we will write the specs and Internet Draft to publish an RFC.

This effort has been ongoing for well over a year with healthy buy-in from CNCF TOC, especially @monadic , the community, and several companies.

The main pool of active contributors is coming from Prometheus team, Google, and Uber.

Cloud-Native & CNCF Alignment

We support the goals of CNCF and have a combined track record of more than a person-decade working on furthering these practices. We see the scope of OpenMetrics going beyond "just" CNCF, hopefully changing the legacy space as well.

Would it be possible for Loris Degioanni and Mark Stemm of Sysdig to present Sysdig's Falco to the TOC on the March 6th, 2018 call? https://sysdig.com/opensource/falco/

In short, Falco leverages Sysdig's ability to tap into system calls, and provides a rules engine to alert when a container performs "abnormal" operations. This alert can be used to take action on the container -such as kill it, stop it, take a Sysdig capture - or notify another system.

Hi,

We kindly request to review the following information and provide instructions for the next steps.

We will be honored to be part of CNCF.

Thank you!

netdata

Name of project: netdata

netdata description

netdata is an open source, distributed performance and health monitoring system. At its core is a highly optimized, lightweight monitoring agent that is installed on all systems (physical servers, container hosts, container guests, VM hosts, VM guests, IoT).

A netdata running at a VM or container host (or a privileged container guest) can monitor all the VMs and containers of the system using cgroups. But netdata may also be installed inside containers or VMs to monitor just them.

netdata is distributed in nature, attempting to eliminate most of the centralized functions in monitoring. Each netdata installation is (by default) autonomous, providing all monitoring functions by itself (data collection, metrics database, web API for querying the database, visualization, health monitoring and notifications). Complex hierarchies of netdata servers are also supported (autonomous, headless collectors, headless proxies, store and forward proxies, database masters).

Each netdata node supports metrics archiving to industry standard time-series dbs (prometheus, graphite, opentsdb and all compatible ones - these are only used for archiving - netdata does not need these servers and never reads the metrics back). This means netdata can also be used as a data collector for other monitoring solutions.

netdata key differentiations are:

1. per second data collection of all metrics, using just 1% CPU of a single core (the netdata core is a multithreaded lockless daemon, written in C, highly optimized to adapt to the system it runs). netdata metrics resolution can only be compared with console tools.
2. fast, really fast, its API responds to all queries in less than 1 ms, providing sub-second latency between collection and visualization.
3. highly interactive visualization, using carefully selected, adapted and integrated javascript libraries netdata provides speedy and snazzy dashboards for monitoring and evaluating the performance of the system and its applications.
4. autodetection of all metrics, out of the box, netdata collects more that 5000 distinct metrics, most of which support auto-detection, offering virtually zero configuration installations.
5. sophisticated health monitoring, it also comes with a few hundred alarms pre-configured for detecting common system and application issues and supports industry standard notification methods (email, syslog, slack, pagerduty, twilio, pushover, irc channels, messagebird, pushbullet, discord, alerta, flock, telegram, etc)
6. open and embeddable, a) netdata has a plugin architecture for data collection supporting any language using stdout for metrics collection, b) netdata is a very fast, fully featured, statsd server, c) interactive netdata charts can be embedded on any web page by just adding a div element (without writing javascript). For example netdata charts can be embedded on Atlassian's Confluence pages.
7. meaningful, netdata organizes metrics into collections with appropriate meaning, context and scope, making monitoring and performance troubleshooting a lot more effective (the default netdata dashboards are also optimized for quickly spotting anomalies). Furthermore, this structure allows netdata to be used as an educational tool for understanding and learning the underlying monitored technologies.
8. secure by design, the design of netdata allows using it in the most demanding setups, including PCI Level 1 certified environments. netdata runs in userspace, unprivileged (there are a few exceptions for plugins that can only collect data when running with escalated privileges - netdata isolates these plugins). netdata does not directly expose any of the collected data on the wire. The only data exposed are processed metric data and related metadata (everything that is visible on the netdata dashboards). Furthermore, all communication between netdata components is unidirectional (slave->master, plugin->server), so that plugins and slaves cannot be manipulated from the outside.

netdata currently runs on Linux, FreeBSD and MacOS.
It was first released in Mar 30, 2016.

You can also have an overview of its internals, with this infographic (click it, it is interactive):

netdata community

home page: https://my-netdata.io
github repo: https://github.com/firehol/netdata

metric	snapshot	live
Github Watchers	1.2k
Github Stars	30k
Github Forks	2.5k
Contributors	163
Docker Hub Pulls	15M

twitter: https://twitter.com/linuxnetdata, followers: 1.8k
facebook page: https://www.facebook.com/linuxnetdata/, likes: 800, followers: 850

Usage statistics

Since May 16th 2016 (the date the global public netdata registry was released):

in the last 24 hours:

Keep in mind the above usage statistics reflect a (probably) small part of the netdata community, counting only those using the public netdata registry. Every netdata can be a netdata registry too, so most enterprise users configure their own.

netdata license

netdata is distributed under GPLv3+.

netdata external dependencies

netdata redistributes a number of third party libraries and tools. The full list, including their licenses, can be found here: https://github.com/firehol/netdata/blob/master/REDISTRIBUTED.md

To compile the netdata daemon only 2 libraries are needed:

1. zlib
2. libuuid

We also provide statically built packages (x64, alpine muslc), that can be installed on any system that does not have these dependencies (these packages require only a Linux kernel, so they can run even on systems with no package management).

Plugins may depend on third party libraries (for example, python plugins need python installed, although we provide key python dependencies so that the core python plugins will work on any version of python).

Source control

Github - https://github.com/firehol/netdata

Initial committers

• @ktsaou, also founder of https://firehol.org

netdata currently has several maintainers and key contributors for its core functions. The full list can be found at the repo contributors page.

The key contributors so far are:

• @l2isbad, core python dev, currently working on Go plugins too
• @paulfantom, was the core python dev a year ago, now working on other projects
• @Ferroin, many python plugins and a lot more work on various aspects of netdata
• @ccremer, contributed many python plugins to netdata
• @facetoe, postgres plugins and more
• @simonnagl, working on java plugins
• @philwhineray, packaging and CI automation
• @alonbl, autotools
• @vlvkobal, ported netdata to FreeBSD and MacOS, occasionally working on netdata
• @titpetric, dockerization of netdata

netdata has several packaging maintainers for integrating netdata to distributions. The full list can be found at this github issue.

Release methodology

We only merge stable and tested code to the official netdata repo. Once every a few months we release a new version (10 releases so far). Check the repo releases page for more information.

Communication channels

Github issues.

Documentation

Currently hosted on a gihub wiki. We need to work a lot more on documentation - currently it lacks uniformity and several parts of it are missing or are not adequate for general use.

The founder sponsored documentation rewrite, but there has not been much progress, so we need to find another solution.

Existing sponsorship

netdata received several sponsorships (mainly hosting and SaaS). You can find the full list at the netdata donations page.

The only direct cost is DNS registration, which is covered by the founder.

Statement on alignment with CNCF mission

netdata is the definition of cloud native monitoring. It is distributed by nature, eliminating most centralized components, lightweight to be used for monitoring containers and microservices, open and flexible enough to be integrated with any system and application, both for data collection (netdata is also a statsd server), but also for visualization and real-time health monitoring.

netdata is a mature, secure and stable application, that is used in production environments all over the world, and it has a track record of community acceptance.

What netdata is looking for

We believe that being part of CNCF:

1. gives users a clear signal that netdata has its place in modern infrastructure stacks.
2. will increase exposure and adoption of netdata.

We also hope that CNCF will help us:

3. direct netdata development is areas that are critical for the modern infrastructure.
4. find our way through open-source licensing, trademarking, etc. providing legal advice and help.

Hi Folks

We'd like to introduce the TOC to gluster-kubernetes and would appreciate it if we could get a slot on the next CNCF TOC meeting to present the project as a candidate project to join the CNCF. Gluster-Kubernetes is an Apache licensed storage platform that deploys and runs Gluster in kubernetes. It has native support in K8s for volume plugins and provisioners and was built by members of the Kubernetes Storage SIG. Downstream, Red Hat offers gluster-kubernetes as a product called Container Native Storage (CNS). CNS has been a GA product since July 2016.

Hello team,

Last year we did a presentation to the TOC about REX-Ray/libStorage. At the time the relevance of storage to cloud native was less clear and the SWG was asked to discuss this topic. Since then CSI was formed and the industry is rallying around this new interop API. With the introduction of storage projects like Rook and Vitess, it feels like the right time to readdress this important project.

Is the TOC open to get some time on the calendar to discuss REX-Ray again as a possible CNCF project?

REX's focus moving forward is to support the CSI eco-system. It is focused on a simple and common user experience across many cloud and storage platforms. Architecturally it packages any CSI plugin implementations to provide value universally beyond the current scope of the CSI specification.

OpenMessaging, a vendor-neutral open standard for distributed messaging and streaming, which includes the establishment of industry guidelines and messaging, streaming specifications to provide a common framework for finance, e-commerce, IoT and big-data area. The design principles are the cloud-oriented, simplicity, flexibility, and language independent in distributed heterogeneous environments. Conformance to these specifications will make it possible to develop a heterogeneous messaging applications across all major platforms and operating systems.

GitHub: https://github.com/openmessaging
Website: http://openmessaging.cloud/
License: Apache 2.0

Alignment to CNCF:

Makes OpenMessaging to be a spec. in messaging and streaming field, making other spec. such as CloudEvents more widely adopted in messaging.

Connects different cloud platform (Alibaba Cloud, Azure, Google, and AWS) through OpenMessaging, users are free to choose according to OpenMessaging Benchmark, like DB-Engines in No-SQL field.

The broader Messaging community is actively exploring how to collaborate and improve the application developer experience, creating cutting-edge features, making messaging runtime schedule and deployment on Kubernates is a natural evolution of these efforts.

Consider OpenMessaging is a Linux Foundation Project, our founding members are including
Alibaba Cloud (https://www.alibabacloud.com)
Yahoo (https://www.yahoo.com/)
DIDi Chuxing (http://www.didichuxing.com/)
Streamlio (https://streaml.io/)

What do we want to get out of submitting to the CNCF?

Expanding the contributor base (we hope all existing messaging solutions could be involved in, not only including Apache RocketMQ, RabbitMQ, Apache Pulsar incubating). We'd love to get others to contribute.

Expanding the ecosystem of OpenMessaging to integrate with CNCF ecosystem projects, improving and standardizing the messaging and streaming field as a whole.

I've spoken with Dan Kohn, Chris Aniszczyk, Alexis Richardson and Keith, shall we dear TOC members schedule a presentation for OpenMessaging on May 15th, Thanks for any information you can provide!

Now that the graduation criteria is approved (#24), we should update the project proposal process to indicate the project type at proposal time.

RSocket is an application-layer network protocol designed for micro-services and browser interaction. It is built upon a message-driven, asynchronous, and multiplexed design and embraces "reactive" principals from the Reactive Manifesto. The protocol is transport, payload, programming model, and language agnostic and includes useful features such as flow control and resumability as core concepts. The project is backed by a diverse community of committers and is used at very large scale by some well known companies.

The RSocket team believes that this project aligns well with section 1(c) of the CNCF Charter by standardizing a loosely-coupled communication protocol. We believe that RSocket can benefit not only the projects within the CNCF, but applications that run on top of those projects as well.

By bringing RSocket under the CNCF umbrella, the team hopes to expand the community outside of the Java and C++ strongholds that it currently occupies. By having a neutral host, we hope to foster a larger community interested in contribution and adoption.

Website: http://rsocket.io
GitHub: https://github.com/rsocket
License: Apache License, Version 2.0

Who, what, why?

TiKV is an open-source distributed transactional key-value store written in Rust built by the company, PingCAP. It provides strong consistency, ACID compliance, and horizontal scalability. TiKV’s transaction model is based on Google’s Percolator model with a few optimizations, and it uses the Raft consensus protocol (with a Multi-Raft implementation) to execute data replication in order to provide High Availability. It has been deployed in production in more than 200 companies.

TiKV currently has a vibrant community with 60+ contributors from 9 countries, 3000+ stars, and almost 400 forks. It also receives institutional contribution from the following organizations:

• Samsung
• Mobike (world's biggest dockless bikesharing company; ~30 million rides per day)
• Toutiao (popular news aggregator app; 120 million DAUs)
• Ele.me (food delivery platform, 200 million users)
• Tencent Cloud (2nd largest public cloud provider in China)
• UCloud (3rd largest public cloud provider in China)

GitHub: https://github.com/pingcap/tikv
License: Apache 2.0

Cloud-Native & CNCF Alignment

TiKV is designed to be cloud-native since the project started two years ago, and it has already been made available for users via Kubernetes in Tencent Cloud. The PingCAP team is also working on an operator tool to more easily deploy, operate, and manage TiKV clusters via Kubernetes in any cloud environment--public, private or hybrid.

Donation Goals

We conceived TiKV to be a standalone project that can serve as a building block for developers to build other systems on top of it. Contributing it to CNCF will take that vision one step closer to reality, by putting it in a neutral environment to foster more community activities, contribution, and adoption.

A stronger TiKV community supported by CNCF will accelerate its development to support more languages, more storage orientation like column family, and other useful features.

We look forward to having a chance to present and discuss TiKV with the TOC.

Who, what, why?

Harbor is a enterprise-grade container registry project from VMware. The project includes a variety of important features including replication between disparate Harbor nodes, authentication via LDAP/AD, repository grouping by project with role-based access control, vulnerability scanning, audit logging, trusted content through image signing, and an HTML5 web interface. Harbor complies with the OCI Distribution Specification.

Harbor currently has a robust community with 70+ contributors from 15+ countries, 4000+ stars, 1.1k+ forks and 10k+ downloads.

GitHub: https://www.github.com/vmware/harbor
Website: http://vmware.github.io/harbor
License: Apache 2.0

Cloud-Native & CNCF Alignment

The project's mission is to build a fully featured container registry for Kubernetes.

Harbor users tell us that image registries are a critical need for cloud native environments. Users include BeyondSoft, BingoCloud, Boco Inter-Telecom, Caicloud, Hydsoft, Pivotal, Rancher, Shanghai OnStar, TrendMicro, and many more.

Donation Goals

Our primary goal of contributing Harbor to CNCF is to have the project in an environment supportive of collaboration to help grow the contributor and user communities.

Now that the OCI Distribution specification has been finalized, the Harbor community can focus on building critical features for large-scale cloud-native deployments: clustering, lifecycle management, more robust multi-tenancy, more fine-grained RBAC functionality, storage and network quotas, etc.

We are looking forward to having a chance to discuss Harbor with the TOC.

Keycloak is an Open Source Identity and Access Management Solution for today’s Cloud Native Applications and Services. It provides an easy way to secure applications and services with minimum effort.

The Keycloak team believes that this project aligns well with section 1(c) of the CNCF Charter by providing a standard and simple way to secure Cloud Native applications and services. Out of the box, Keycloak provides an extensive set of features such as user federation, admin console and account management console. Securing applications and services can be done with only a few lines of code through Keycloak adapters that are provided for a range of languages and frameworks. Keycloak also provides both OpenID Connect and SAML 2.0 enabling any application that have support for either to be easily secured.

With it's already large community support, bringing Keycloak into the CNCF, the team hopes to continue to expand the list of features, making it even easier to secure different types of applications and reach an even wider community interested in contribution and adoption.

Website: https://keycloak.org
GitHub: https://github.com/keycloak
License: Apache License, Version 2.0

Our CI Working Group has been tasked with demonstrating best practices for integrating, testing, and deploying projects within the CNCF ecosystem across multiple cloud providers. The Cross-Cloud CI uses multiple project CI pipelines (cross-project) driving multi-cloud deployments (cross-cloud) with e2e tests.

We have 3 projects on Cross-Cloud CI now, Prometheus, CoreDNS and Kubernetes.

The ii coop demo, presented by @dlx and @hh, is 10 minutes long and we would love to gather the TOC's feedback.

Thank you for your consideration.
@caniszczyk @dankohn

Strimzi enables users to run Apache Kafka on Kubernetes. It is using the proven operator concept and aims to address the whole Apache Kafka life cycle:

Creating clusters
Managing running clusters
Optimizing running clusters for performance and efficiency
Scaling clusters up and down
Managing topics, users and permissions

Apache Kafka has emerged as a leading platform for building real-time data pipelines. It is distributed and horizontally scalable. That makes Apache Kafka a good candidate for running on top of Kubernetes. Apache Kafka is used as one of the basic building blocks for event driven and microservice based architectures. It provides a powerful tool for connecting scalable and decoupled components.

The Strimzi team believes that the project aligns closely with the Cloud Native Computing Foundation (CNCF) mission as described in section 1 of the CNCF Charter.

In particular:
Apache Kafka is a complex application consisting of multiple separate components (Apache Zookeeper, Apache Kafka brokers, etc.). Strimzi packages Apache Kafka into containers and makes deploying Apache Kafka clusters as easy as if it was just a simple deployment.
Strimzi provides a central process for managing Apache Kafka clusters. It aims to utilize Kubernetes features such as scalability to achieve efficient Apache Kafka deployments which run wherever Kubernetes runs.
While Apache Kafka itself is not part of this proposal, we believe it also aligns closely with the CNCF mission.
Strimzi can benefit applications that run on top of other CNCF projects such as Kubernetes. Being able to easily operate Apache Kafka on Kubernetes could act as an “enabler” for developers to adopt cloud native principles.

We hope that by bringing the Strimzi project under the CNCF umbrella as a neutral host, we will be able to further expand the community and the adoption of the project.

Website: http://strimzi.io/
GitHub: https://github.com/strimzi
Video Reference: Strimzi Operator with Tom Bentley (Red Hat) - Operator Framework SIG Meeting July 2018 https://youtu.be/37DDC-Cy2ZI

License: Apache License, Version 2.0

Hi folks,

We'd like to introduce the TOC to SPIFFE and SPIRE an Apache 2.0 licensed platform originally proposed by @jbeda for issuing identities to software systems in heterogenous environments. It is particularly well suited for elastic or ephemeral cloud workloads and container schedulers such as Kubernetes. The goal of the project is to provide this API on a wide range of platforms.

In presenting this to the TOC, we will demonstrate how SPIRE can be used to securely issue identities to workloads running in a Kubernetes cluster, and workloads running outside of that cluster, and discuss the ways in which those identities can be used. We also hope to discuss the ways that SPIFFE and SPIRE support the CNCF mission, and a path forward to CNCF acceptance.

Ideally we'd like to present the first week of November.

Hello!

We would like to introduce the Open Policy Agent (OPA) project to the TOC. OPA is an Apache 2.0 licensed, general-purpose policy engine. OPA can be applied to any system, at any layer of the stack. OPA’s goal is to enable policy-based control throughout the cloud native ecosystem.

As part of the presentation, we can provide an overview of how OPA works as well examples of integrations with projects such as Kubernetes, Istio, and Docker. In addition, we will provide an overview of future work planned with our design partners at Google.

The goal of the discussion would be to figure out how OPA can be accepted into the CNCF.

What is Virtual Kubelet?
Virtual Kubelet is an open source Kubernetes kubelet implementation that masquerades as a kubelet for the purposes of connecting Kubernetes to other APIs. Using Virtual Kubelet users can connect their Kubernetes cluster to multiple providers like IoT Edge, Service Fabric Mesh, AWS Fargate, VIC, CRI, Azure Container Instances, and many more. Thus benefiting from Kubernetes alongside the benefits that the provider offers. Within the Virtual Kubelet interface we've enabled bring your own private VNet, monitoring, volumes, port-forwarding, exec and more.

Through these features Virtual Kubelet enables:
Limited operational overhead to scale up applications in Kubernetes
Extending Kubernetes to any technology with an API


GitHub: https://github.com/virtual-kubelet/virtual-kubelet
License: Apache 2.0



Cloud-Native and CNCF Alignment
Virtual Kubelet works within the ecosystem of Kubernetes rather than being a replacement architecture but we also are a standalone component that can be easily installed or deleted. Virtual Kubelet truly enables people to extend beyond the lines of a traditional node. The VK community is growing with over 50 contributors from Microsoft, VMWare, Amazon, and more. Release 1.0 is expected in December.

Donation Goals


By open sourcing an interface to enable any kind of provider to build an abstraction into Kubernetes has been proven very powerful. Kubernetes becomes a default interface backed by multiple services, technologies and providers.

Virtual Kubelet needs a home where the ecosystem around it can grow beyond just a couple of use cases. We are excited to inspire programmers to build into the interface even if it's just a "silly" provider. We also want to leverage the CNCF's expertise and knowledge about running an open source component in an inclusive way.

Telepresence is a developer tool for Kubernetes. Telepresence lets developers code their Kubernetes services locally, while creating a bi-direction network proxy to a remote Kubernetes cluster. This lets developers who are working on multi-service apps to get the benefits of both local development (fast feedback cycle, IDE, debugger, etc.) and cloud development (unlimited compute/network resources, realistic environment).

GitHub: https://github.com/datawire/telepresence
Website: https://www.telepresence.io
License: Apache 2.0

Alignment to CNCF:

1. Makes Kubernetes easier to use for app devs (and anyone else, really).
2. The broader CNCF/Kubernetes community is actively exploring how to improve the application developer experience. Adding more projects for the app dev is a natural evolution of these efforts.

Some public end users:

• Bitnami (https://kccnceu18.sched.com/event/Dqug -- presenting on this at KubeCon)
• Verloop (https://www.telepresence.io/case-studies/verloop)
• Sight Machine (https://www.telepresence.io/case-studies/sight-machine)

I've spoken with Brian Grant and Alexis Richardson both of whom are supportive of Sandbox.

What do we want to get out of submitting to the CNCF?

1. Expanding the contributor base (the vast majority of contributors have been Datawire-related folks). We'd love to get others to contribute.
2. Expanding the visibility of Telepresence to improve both the project and the Kubernetes app dev experience as a whole.

I`m in china , not easy to go to CNCF TOC meeting. sorry.
how should i propose my project :
https://github.com/ipdcode/containerfs

Weave Scope provides observability, troubleshooting and control for distributed applications, automatically building a map of your services. Weave Scope doesn't require any instrumentation, detecting processes, containers, connections and hosts out of the box. It provides seamless integration with Docker, Kubernetes, DC/OS and AWS ECS.

People choose Weave Scope because it provides insights to distributed application with zero configuration, it's very easy to install, and it helps a lot in illustrating infrastructure-related demos and tutorials.

First released in 2015, Weave Scope had been downloaded from Docker Hub more than 327 million times.

The project received contributions from 54 people so far. Aside from Weaveworks employees, many contributors have other affiliations. Earlier in 2018, Weaveworks started fostering a Scope community with autonomous governance, which has resulted in growth of external contributions. You can find out more in the minutes of weekly community meetings.

Weaveworks would like to contribute Weave Scope to CNCF as an Incubation project to facilitate for more people from diverse organizations to work on it.

Weave Net is a container overlay network from Weaveworks: it implements the CNCF CNI and Docker CNM plugin interfaces, and also Kubernetes NetworkPolicy.

Typical reasons people choose Weave Net are because it is easy to install, or because they want host-to-host encryption, or support for multicast in a public cloud.

First released in 2014, the Weave Net Docker images have now been "pulled" more than 30 million times.

There have been contributions from 59 people so far - mostly Weaveworks but a wide range of other affiliations too.

Weaveworks would like to contribute Weave Net to CNCF ownership to facilitate more people from diverse organisations working on it.

There is an interest to form Working Groups around specific topics.

We should have a simple formal process to establish these.

We'd like to add an agenda item to the Nov 7th TOC call where the wg-serverless team can present the whitepaper and summarize the work//outcome.

Hi,
We, AppsCode, publish a number of charts in Helm stable charts. We collect usage events from our various tools. Currently this generally means we send a Google analytics event every time a cli command is executed. This can be disabled via a flag --enable-analytics=false. This is also noted in the readme file for charts.

We are trying to expose this flag in our charts hosted on stable charts repo with default opt-in (--enable-analytics=true). There are opposing opinions on this topic. Given the potential legal implications, it seems prudent to get opinion from the CNCF folks. If there is a more appropriate forum , please forward us there.

So, here are some questions from me:

• Should it be ok to collect analytics with default opt-in for non-interactive/server side tools?

• Should stable charts be able to dictate how app developers collect analytics?

NB: Helm charts issue: helm/charts#4450

In November, we should schedule project graduation reviews as some of our projects are close to meeting graduation requirements: https://github.com/cncf/toc/blob/master/process/project_proposals.adoc

I'd like to see Kubernetes and Prometheus be first to present since they were the first two projects in CNCF and have almost met all the qualifications.

The Istio team would like to request presenting to the TOC on Nov 7th: https://istio.io/

Are you OK with this @cncf/toc cc: @monadic @bgrant0607

Who, What, Why?

Habitus is a build workflow tool for Docker images. Using Habitus, users can:

• Build multi-stepped Docker images across a shared cluster of build servers.
• Use and move build artifacts between different steps
• Provide secrets during build (for example private SSH keys to pull build dependencies in private repositories) without leaving trace
• Squashing layers in Docker images after build
• Enforce build step dependencies
• Building images on a multi-tenanted environment like a SaaS CI provider

Through these features Habitus makes the following possible:

• Construction of complex multi-stepped builds
• Reduction of attach surface and image size by moving the build artifacts from a build-time image to a runtime image
• Keeping their private repositories secure by preventing secrets being left inside of images by mistake


GitHub: https://github.com/cloud66-oss/habitus
Website: http://www.habitus.io/
License: Apache 2.0



Adopters: Adopters: Cloud 66 VMware Sony Bank of America More: A great deal of Github users at their respective companies: https://github.com/cloud66-oss/habitus/stargazers

Cloud-Native and CNCF Alignment

With containers being a core tenant of cloud native computing, a flexible, easy to use and robust tool to facilitate building of container images is a critical part of developing a successful cloud native infrastructure setup at any company aiming to use containers.

Donation Goals



By making it possible, safe and simple to build container images, Habitus lowers one of the first and big barriers of entry into cloud native infrastructure for many users by promoting and simplifying best practices around secret control, facilitating build of compiled languages like Java or Golang in multiple steps and improving operation security by reducing attack surface of runtime images.

Habitus needs a well respected, vendor-neutral home that can help serve as a starting point for promoting better standards for building containers. In addition to increased visibility, we hope that inclusion in the CNCF will foster communication between Habitus and other projects in the ecosystem. As the project grows, we would want to leverage the CNCF’s expertise around project governance and community standards as those are fundamental to the long term success of the project.

The project does not have any infrastructure requests at this time. CI is currently hosted on Codeship and covered by the free tier for open source projects.

TOC nominations are starting TODAY for the 6 TOC slots that open up in Jan 2019 that are selected by GB members (members can propose UP TO TWO NOMINEES, where you can only nominate up to one candidate from your organization, the other candidate has to be outside your organization): https://github.com/cncf/toc/blob/master/process/election-schedule.md

The seats that open up are:

Jonathan Boulle (term: 3 years - start date: 1/29/2016)
Bryan Cantrill (term: 3 years - start date: 1/29/2016)
Camille Fournier (term: 3 years - start date: 1/29/2016)
Benjamin Hindman (term: 3 years - start date: 1/29/2016)
Ken Owens (term: 3 years - start date: 1/29/2016)
Alexis Richardson (term: 3 years - start date: 1/29/2016)

Here's the timeline for the election, we are giving ample time due to the holidays:

• Oct 26th: Nominations Open (TODAY)
• Nov 30th: Nominations Close
• Dec 1st: Qualification Period Opens
• Dec 14th: Qualification Period Closes (end of KubeCon Seattle)
• Dec 17th: Election Opens
• Jan 22nd: Election Closes
• Jan 29th: Election Results Posted!

In summary, these nominations are for the 6 slots nominated by CNCF members. You have to be a CNCF member in order to nominate someone. Each CNCF member CAN NOMINATION ONLY TWO PEOPLE MAXIMUM, where only one of them can come from your company (the other candidate can come from anywhere). See CNCF Charter Section 6(e) for full election process details: https://www.cncf.io/about/charter

From today's TOC call there's been a desire to update the reference architecture. @kenowens12 from the @cncf/toc will be leading this effort.

One of the challenge with shipping 'ready-to-go' containers (containers that do not need further modification) is the assignment of uid/gid values to run as non-root-- especially for containers that use a volume. User namespaces look to address the stateless use case, but there is a gap for stateful services (and vm-managed by k8s) to address the filesystem uid+gid collision issue.

I'm curious to get feedback on a convention of leveraging IANA Private Enterprise Numbers as the basis for a registry of 3rd party uid+gid values. I recognize that previous efforts to reserve tcp port numbers was severely limited due to the small range allowed. However, with ~4B available UID's, it seems there would be enough head room to consider the ability for CNCF implementations to (optionally) reserve UID/GID range based on a convention.

Something along the lines of:
0 - 2,000,000,000 (reserved for local user and group id)
2,000,000,000 - UID MAX (2,000,000,000 + PEN number for 3rd parties)

Example uids:
2,000,000,002 --> 'ibm' uid / gid
2,000,000,003 --> 'cmu' uid / gid
etc..

The kubernetes repo's directory structure has been adjusted, and should update the pause's info:
https://github.com/cncf/toc/blob/master/proposals/kubernetes.adoc

The link "https://github.com/kubernetes/kubernetes/blob/master/third_party/pause/LICENSE" get the 404 error.

The maintainers of the Rook project would like to present to the TOC about graduation from Sandbox to Incubating stage. Rook was initially accepted as a CNCF hosted project on 2018-01-29.

Since being accepted, Rook has continued to grow in accordance with the Incubating stage graduation criteria in terms of size and quality of production deployments, number of contributors to the project and frequency of commits.

Does August 7th work with the TOC schedule? A full proposal and presentation will be put together in the coming weeks.

As suggested by @caniszczyk, we submit light-4j for consideration to be included in CNCF projects.

Github repo: https://github.com/networknt/light-4j
Document: https://doc.networknt.com/

More information can be be found in the following document.

https://docs.google.com/document/d/1p1v2Fy05SUy5vTTPMhySdpT7KsHJNh4-u7QgGdKEOAA/edit?usp=sharing

To get started with RESTful APIs, these two tutorials will be a good starting points.

https://doc.networknt.com/tutorial/rest/openapi/petstore/
https://doc.networknt.com/tutorial/rest/swagger/petstore/

Our own benchmarks
https://github.com/networknt/microservices-framework-benchmark

Third party benchmarks
https://www.techempower.com/benchmarks/previews/round15/

This is no longer true: "All projects start in the incubator TLP"

Hello,
Recently we released Kamus, a solution for secret encryption/decryption for Kubernetes platform. In a high-level overview, Kamus solve a common problem for containerized applications - how to pass secrets securely? Kamus designed to encrypt secrets for a specific application, represented by a service account. Only this application can decrypt the secret, and no one else. By this, Kamus offer a secure, zero-trust, GitOps solution to the problem. The design is inspired by Travis encrypted secrets solution.

Kamus was developed by Soluto (I'm one of the developers). None of the existing solutions was good enough for us, so we had to build a new solution. It is used by us in production for more than 6 months and we are highly satisfied with it. For this reason, we decided to release it as an open source product, so others can enjoy it too. From the same reason, we would love to contribute it to the CNCF.

Kamus is a natural fit to the CNCF. It is designed to ease the process of building applications, by simplifying the process of secrets management. By using Kamus, secrets can be stored in the same place with the deployment manifest files, which make it easier to deploy and monitor applications.

We are proposing it as a sandbox project because it's in alpha version currently - we had some people who showed interest, but currently there are no users.

Before opening this issue, I read the proposal document, understood the different project levels and looked on other sandboxes project proposals. I'm also in the process of demoing it on a few relevant kubernetes groups (including sig apps and kubernetes community). Please let me know if there is anything else I need to provide in order to propose Kamus.

To replace it with sandbox.

The Cortex team would like to make an initial TOC presentation for moving Cortex the CNCF Sandbox.

https://github.com/weaveworks/cortex

The project implements a horizontally scalable time series database backend for Prometheus, using Kubernetes as the orchestration engine. Originally implemented to manage hosted Prometheus as a multi-tenant service on AWS, the project has expanded to support other cloud stores such as GCP.

FAQs:

At time of writing the main users include three vendors, all of whom embed a Prometheus-aaS in their products, as well as some large scale Prometheus adopters like Electronic Arts.

With growing community interest, Weaveworks recently took the first step towards a community driven dev model & governance. The intent is for the independent project to be known as "Cortex".

Relationship to Prometheus: The Cortex project is not a general purpose TSDB, because it currently supports Prometheus metrics only. It could evolve to support a superset of this (eg events, tracing). Currently the Prometheus org does not include any sub-projects for non-standard Prometheus storage. Several exist: Cortex, Thanos, InfluxDB, Metrictank. The question of how to express a formal relationship between Prometheus and the various 3rd party storage tools remains a matter for the Prometheus team.

Finally, this project needs 2 TOC sponsors. As I have a vested interest in the project, I am opting out of any sponsorship / decisions for this proposal.

We should probably clarify the archiving process, right now we only mention it in the sandbox process:

https://github.com/cncf/toc/blob/master/process/sandbox.md#sandbox-exit-requirements

We should make it more clear and detailed.

Thanks to @mattfarina for pointing this out.

Hey guys,

I have a tool that I would like to see become a Kubernetes sandbox project, but I am not sure exactly where to pitch it. Currently, the code lives within the corporation I work for, but we are looking to open source it (and hand the rights to the name over to the CNCF). The corporation is a member of the CNCF.

The project is still immature and likely should be considered alpha, but it is used in production by our team and should soon have a beta version.

Project Description:

Kuberhealthy is a monitoring system for Kubernetes that exposes an endpoint that indicates cluster health. Cluster health is determined through several synthetic checks, such as:

• Deploying and tearing down a daemonset
• Checking if pods are restarting too often
• Checking if all workloads in the kube-system namespace are healthy

This project was born from the need to monitor production Kubernetes clusters better. Metrics and status checks are often not enough to guarantee that a deployment or rolling update can occur properly. Over time, more checks will be added to Kuberhealthy in a modular and tunable way so that the tool is an easy and generic drop-in for any Kubernetes cluster.

Thanks for any information you can provide!