CNCF TOC Meeting

August 17th, 2016

LF Antitrust Policy Notice

CNCF meetings involve participation by industry competitors, and it is the intention of the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws.

​

Examples of types of actions that are prohibited at CNCF meetings and in connection with Linux Foundation activities are described in the Linux Foundation Antitrust Policy available at http://www.linuxfoundation.org/antitrust-policy. If you have questions about these matters, please contact your company counsel, or if you are a member of the Linux Foundation, feel free to contact Andrew Updegrove of the firm of Gesmer Updegrove LLP, which provides legal counsel to the Linux Foundation.

​

2

Meeting Logistics

Time: August 17th 8AM (Pacific)

http://uberconference.com/cloudnative

Conference Number: +1-415-579-0198 No Pin Needed

3

​

TOC - Members Present Today

​

4

Company

Apache Software Foundation

Cisco

CoreOS

Docker

GoDaddy

Google

Joyent

Mesosphere

Weaveworks

​

Note: TOC meetings shall require a quorum of two-thirds of the TOC total members to take a vote or make any decision. If a TOC meeting fails to meet the quorum requirement, discussions may proceed, however there shall be no voting or decisions.

Name

Camille Fournier

Ken Owens [vacation]

Jonathan Boulle

Solomon Hykes (vacation)

Elissa Murphy

Brian Grant

Bryan Cantrill

Benjamin Hindman

Alexis Richardson

​

​

Email

skamille@gmail.com

kenowens@cisco.com

jonathan.boulle@coreos.com

solomon.hykes@docker.com

elissam@godaddy.com

briangrant@google.com

bryan@joyent.com

benh@mesosphere.io

alexis@weave.works

​

​

​

Agenda

• Updates
• Cluster
• Ref Arch
• Projects: Pipeline, Incubation
• Presentation: CoreDNS (overview, proposal)
• Presentation: OpenTracing (BenS)
• Discussions
• AOB

​

​

​

​

5

OPEN CNCF Cluster Update

Proposed “Questions for Projects”

• Is the code that you’re going be running 100% open source? If so, what is the URL or URLs where it is located?
• How will this testing advance cloud native computing (specifically containerization, orchestration, microservices or some combination).
• Will your testing involve containers? If not, could it? What would be entailed in changing your processes to containerize your workload?

https://github.com/cncf/cluster/blob/master/.github/ISSUE_TEMPLATE.md has been revised

Actions: Camille - Zookeeper - please talk with Dan about onboarding

CNCF PR will be announcing wide availability for open source projects advancing cloud native computing

6

CNCF Reference Architecture Update

• Plan
• Review and provide approval or comments to Ken by the end of the week. Aim to finalize.
• Create Infographic (Dan & Chris)

​

• Notes
• Landscape introduced in email here
• See Ref Arch slides

​

​

​

​

​

7

Projects: Pipeline

• NATS (pubsub)
• TOC sponsor: Alexis Richardson (working on project proposal and legal issues moving to ALv2)
• Fluentd (logging)
• Needs discussion and sponsor
• Heron (real time stream processing)
• Discussion. TOC Sponsor: Ben Hindman (working on project proposal)
• Minio (storage)
• Needs discussion
• OpenTracing (sponsor: Bryan Cantrill) & OpenZipkin
• CoreDNS (Jonathan sponsoring)
• needs discussion / TOC sponsor: Jonathan Boulle
• (NEW) CockroachDB (distributed SQL DB)
• scheduling TOC community presentation and needs sponsor

​

​

​

​

​

​

8

Project Proposal: CoreDNS

• CoreDNS
• Overview Presentation
• Project Proposal
• Presenters
• Miek Gieben (Google)
• Michael Richmond (Infoblox)

9

CoreDNS

CNCF Overview

CoreDNS coredns.io

@corednsio

Origin

CoreDNS is young (~6 months), but based up on older, proven foundations:

• SkyDNS (~3 years old, is still seeing lots of production use)
• Forked from Caddy webserver (~2 years old)

Why:

• SkyDNS architecture does not lend itself well to the flexible world of cloud deployments: organic grown code base (monitoring, caching, … all bolted on)
• Other DNS servers (BIND9, NSD, Knot) are good for serving DNS, but are also not flexible - none of them support etcd as backend for example.

​

​

CoreDNS coredns.io

@corednsio

Evolution

• Forking back into Caddy, becoming server type. Leverage Caddy's popularity and community (7200 stars on github)
• Position as a better SkyDNS than SkyDNS (1250 stars on github)
• Becoming the cloud DNS server; can be used as library by others: docker, hashicorp, weave, etc.
• Useful outside cloud environments as well!

​

Building up the community, but will take time.

​

​

CoreDNS coredns.io

@corednsio

Architecture

• Chains DNS middleware, each �"feature" is contained in a middleware:
• monitoring (Prometheus),
• logging,
• file based DNS,
• etcd and k8s backends.
• Only load the middleware(s) you need
• Each middleware is self-contained — easy to add new behavior
• Is a servertype plugin in Caddy

​

CoreDNS coredns.io

@corednsio

Why CNCF

Service Naming and Discovery typically uses DNS for Discovery

• SkyDNS fills this role in Kubernetes, RancherOS, etc.
• CoreDNS is SkyDNS++
• CoreDNS design allows easy extension of DNS functionality to various container stacks.
• Fostering alternative implementations of cloud-native components.
• Reduced runtime complexity as compared to KubeDNS (=SkyDNS+etcd+kube2sky+healthchecking).

CoreDNS coredns.io

@corednsio

OpenTracing

Presenter: Ben Sigelman

opentracing.io | github.com/opentracing

​

(more slides)

​

15

Microservices: 1 story, N storytellers

Microservices are here to stay: decoupled CI, CD, eng teams, autoscaling, etc

… but they break legacy monitoring tools: great monitoring tells stories about your system. Process-scoped monitoring can never do that.

How do you “tell stories” about a modern architecture?�Distributed Tracing: consider all requests from all services, then connect the dots

… So why isn’t distributed tracing ubiquitous?

Because instrumentation.

Distributed tracing instrumentation has been broken until now.

Distributed tracing instrumentation must be:

• explicit: monkey patching is cute but does not work here
• decoupled: instrumentation should not dictate a specific vendor
• consistent: use the same nouns and verbs across platforms
• built for handoff: facilitate coordination and interoperability across both API and process boundaries

TL;DR on OpenTracing

Thesis: instrumentation is the hardest part of a tracing deployment

Optimizes: ROI for tracing instrumentation in apps or shared libs

Who cares?

• Application developers
• Maintainers of libraries on the critical path of distributed requests
• Tracing system authors

Pick your battles

Recent history and near future

• Q4 2015: Idea born at Adrian Cole’s distributed tracing workshop
• Initially called “DCP”: Distributed Context Propagation (sorta)
• Insufficiently catchy name; went with less correct “OpenTracing” terminology
• Jan 2016: Release Candidate API
• Q1+Q2: Iteration with multiple real-world tracing impls and systems
• July 2016: OpenTracing-Zipkin bindings in Java/Go/Python
• August 2016: Stable API; first round of OSS integrations merged
• Rest of 2016: Focus on integrations with context and IPC packages

Status as an OSS project

• A young and fast-growing project
• Hard to eval with hard numbers: not intended to be forked!
• Tracer Implementations: Zipkin, Uber’s Jaeger Zipkin sibling, Appdash, LightStep, and a few smaller tracing systems
• Companies: Airbnb, Apple, Bloomberg, Box, Clever, Docker, Github, Lyft, Medium, Pinterest, Stripe, Twilio, Uber, Zenefits, many smaller shops
• Important OSS integrations underway: gRPC, Finagle, various web frameworks (Dropwizard, Flask, etc)

%s/OpenTracing/OpenInstrumentation/g

Logging

Latency Metrics

Baggage

Distributed Causality

OpenTracing API

OpenTracing *= CNCF

• OpenTracing can and should have a mutualistic relationship with other/future CNCF projects; rising tides, etc
• Would also like a better story below the application layer (via container-level standards)
• Obvious tactical benefits regarding marketing, etc
• OpenTracing is not “A LightStep Thing”, and CNCF membership will make sure it stays that way
• As CNCF grows, it can help push OpenTracing OSS integrations forward
• TOC feedback will be helpful for large technical decisions and investments

Projects Proposals Process

Proposal: ratify & publish a “proposals process”.

This will require a vote.

​

ChrisA will make a PR updating the process

​

This week: For discussion, please review email

24

Projects Discussion

Projects - Goals of recruiting projects & how we work with initial projects to establish modus operandi & brand

​

Criteria for induction & the rising bar

​

Review intros from Minio, Fluentd, Heron, CoreDNS, OpenTracing. Discuss next steps.

​

​

25

Other

• “Below the waterline” update - Dan & Chris
• CLA: https://github.com/cncf/foundation/issues/1 (see doc)
• LinuxCon next week & CloudNativeDay
• Discuss Service Broker WG

26

Cadence

• Last meeting slides on 8/3/2016

​

• Meeting Cadence Reminder
• First and third Wednesday of every month
• Calls without TOC quorum will still be used to review issues

​

• Next Meeting: 9/07/2016

​

​

27

Thank You

28

Other topics to discuss in the future

• Example Apps & Patterns
• Website “how we help” etc.
• “Below the waterline”: Define Incubation, Development Model & other community management issues; Advice; Advocacy; ..

​

​

​

29

Marketing - Request

This is going well for Prometheus eg. with 1.0

Please contribute if you can

Some asks:

• We need speakers for events - email pr@cncf.io
• We need TOC members to volunteer for triaging CFP responses for CloudNativeCon (email events@cncf.io)

​

30

CNCF Reference Architecture

• Any comments? Vote?
• See slides

​

​

​

​

​

31