Compare commits
5 Commits
57d04670ec
...
c2326acfea
Author | SHA1 | Date |
---|---|---|
Nicolai Ort | c2326acfea | |
Nicolai Ort | f3715316b5 | |
Nicolai Ort | c178fe095c | |
Nicolai Ort | c7797a0891 | |
Nicolai Ort | 480fcd4ae5 |
|
@ -1,3 +0,0 @@
|
||||||
---
|
|
||||||
title: Opening Keynotes
|
|
||||||
---
|
|
|
@ -1,4 +0,0 @@
|
||||||
---
|
|
||||||
archetype: chapter
|
|
||||||
title: template
|
|
||||||
---
|
|
|
@ -52,3 +52,7 @@ I should follow up
|
||||||
|
|
||||||
* The paid renovate offering now includes build failure estimation
|
* The paid renovate offering now includes build failure estimation
|
||||||
* I was told not to buy it after telling the technical guy that we just use build pipelines as MR verification
|
* I was told not to buy it after telling the technical guy that we just use build pipelines as MR verification
|
||||||
|
|
||||||
|
### Certmanager
|
||||||
|
|
||||||
|
* The best swag (judged by coolness points)
|
||||||
|
|
|
@ -0,0 +1,80 @@
|
||||||
|
---
|
||||||
|
title: Why is this so hard! Conveying the business value of open source
|
||||||
|
weight: 3
|
||||||
|
---
|
||||||
|
|
||||||
|
Bob a Program Manager at Google and Kubernetes steering commitee member with a bunch of contributor and maintainer experience.
|
||||||
|
The value should be rated even higher than the pure business value.
|
||||||
|
|
||||||
|
## Baseline
|
||||||
|
|
||||||
|
* A öarge chunk of CNCF contrinbutors and maintainers (95%) are company affiliated
|
||||||
|
* Most (50%) of the people contributed in professional an personal time )(and 30 only on work time)
|
||||||
|
* Explaining business value can be very complex
|
||||||
|
* Base question: What does this contribute to the business
|
||||||
|
|
||||||
|
## Data enablement
|
||||||
|
|
||||||
|
* Problem: Insufficient data (data collection is often an afterthought)
|
||||||
|
* Example used: Random CNCF slection
|
||||||
|
* 50% of issues are labed consistentöy
|
||||||
|
* 17% of projects label PRs
|
||||||
|
* 58% of projects use milestones
|
||||||
|
* Labels provide: Context, Prioritization, Scope, State
|
||||||
|
* Milestones enable: Filtering outside of daterange
|
||||||
|
* Sample queries:
|
||||||
|
* How many features have been in milestone XY?
|
||||||
|
* How many bugs have been fixed in this version?
|
||||||
|
* What have I/my team worked on over time?
|
||||||
|
|
||||||
|
### Triage
|
||||||
|
|
||||||
|
* Many projects don't triage b/C
|
||||||
|
* Auth (No Role that can only edit labels+milestones)
|
||||||
|
* Thought of as overhead
|
||||||
|
* Project is too small
|
||||||
|
* Tools:
|
||||||
|
* Actions/Pipelines for autolabel, copy label sync labels
|
||||||
|
* Prow: The label system for kubernetes projects
|
||||||
|
* People with high project but low code knowlege can triage -> Make them feel recognized
|
||||||
|
|
||||||
|
### Conclusions
|
||||||
|
|
||||||
|
* Consistent labels & milestones are critical for state analysis
|
||||||
|
* Data is the evidence needed in messaging for leadershiü
|
||||||
|
* Recruting triage-specific people and using automations streamlines the process
|
||||||
|
|
||||||
|
## Communication
|
||||||
|
|
||||||
|
### Personas
|
||||||
|
|
||||||
|
* OSS enthusiast: Knows the ecosystem and project with a knack for discussions and deep dives
|
||||||
|
* Maintainer;: A enthusiast that is tired, unter pressure and most of the time a one-man show that would prefer doint thechnical stuff
|
||||||
|
* CXO: Focus on ressources, health, ROI
|
||||||
|
* Product manager: Get the best project, user friendly
|
||||||
|
* Leads: Employees should meet KPIs, with slightly better techn understanding
|
||||||
|
* End user: How can tools/features help me
|
||||||
|
|
||||||
|
### Growth limits
|
||||||
|
|
||||||
|
* Main questions:
|
||||||
|
* What is theis project/feature
|
||||||
|
* Where is the roadmap
|
||||||
|
* What parts of the project are at risk?
|
||||||
|
* Problem: Wording
|
||||||
|
|
||||||
|
### Ways of surfcing information
|
||||||
|
|
||||||
|
* Regular project reports/blog posts
|
||||||
|
* Roadmap on website
|
||||||
|
* Project boards -> GitHub's feature for this is apparently pretty nice
|
||||||
|
|
||||||
|
### Questions by leadership
|
||||||
|
|
||||||
|
* What are we getting out? (How fast are bugs getting fixed)
|
||||||
|
* What is the criticality of the project?
|
||||||
|
* How much time is spent on maintainance?
|
||||||
|
|
||||||
|
## Conclusion
|
||||||
|
|
||||||
|
* Ther is significant unrealized valze in open source
|
|
@ -0,0 +1,79 @@
|
||||||
|
---
|
||||||
|
title: "Towards Great Documentation: Behind a CNCF-Led Docs Audit"
|
||||||
|
weight: 4
|
||||||
|
---
|
||||||
|
|
||||||
|
A talk about the backstage documentation audit and what makes a good documentation.
|
||||||
|
|
||||||
|
## Opening
|
||||||
|
|
||||||
|
* 2012 the year of the mayan calendar and the mainstream success of memes
|
||||||
|
* The classic meme RTFM -> Classic manuals were pretty long
|
||||||
|
* 2024: Manuals have become documentation (hopefully with better contents)
|
||||||
|
|
||||||
|
## What gets us to good documentation
|
||||||
|
|
||||||
|
### What is documentation
|
||||||
|
|
||||||
|
* Docs (the raw descriptions, qucikstart and how-to)
|
||||||
|
* Website (the first impression - what does this do, why would i need it)
|
||||||
|
* REAMDE (the github way of website + docs)
|
||||||
|
* CONTRIBUTING (Is this a one-man show)
|
||||||
|
* Issues
|
||||||
|
* Meta docs (how do we orchestrate things)
|
||||||
|
|
||||||
|
### Project documentation
|
||||||
|
|
||||||
|
* Who needs this documentation?
|
||||||
|
* New users -> Optimize for minimum context
|
||||||
|
* Experienced users
|
||||||
|
* User roles (Admins, end users, ...) -> Seperate into different pages (Get started based in your role)
|
||||||
|
* What do we need to enable with this documentation?
|
||||||
|
* Prove value fast -> Why this project?
|
||||||
|
* Educate on fundemental aspects
|
||||||
|
* Showcase features/uses cases
|
||||||
|
* Hands-on enablement -> Tutorials, guides, step-by-step
|
||||||
|
|
||||||
|
### Contributor documentation
|
||||||
|
|
||||||
|
* Communication channels have to be clearly marked
|
||||||
|
* Documented scheduled contributor meetings
|
||||||
|
* Getting started guides for new contributors
|
||||||
|
* Project governance
|
||||||
|
* Who is gonna own it?
|
||||||
|
* What will happen to my PR?
|
||||||
|
* Who maintains features?
|
||||||
|
|
||||||
|
### Website
|
||||||
|
|
||||||
|
* Single source for all pages (one repo that includes landing, docs, api and so on) -> Easier to contribute
|
||||||
|
* Usability (especially on mobile)
|
||||||
|
* Social proof and case studies -> Develop trust
|
||||||
|
* SEO (actually get found) and analytics (detect how documentation is used and where people leave)
|
||||||
|
* Plan website maintenance
|
||||||
|
|
||||||
|
### What is great documetnation
|
||||||
|
|
||||||
|
* Project docs helps users according to their needs -> Low question to answer latency
|
||||||
|
* Contributor docs enables contributions in a predictable manner -> Don't leave "when will this be reviewed/mered" questions open
|
||||||
|
* Website proves why anyone should invest time in this projects?
|
||||||
|
* All documetnation is connected and up to date
|
||||||
|
|
||||||
|
## General best practices
|
||||||
|
|
||||||
|
* Insular pages: One page per topic, preferably short
|
||||||
|
* Include API reference
|
||||||
|
* Searchable
|
||||||
|
* Plan for versioning early on (the right framework is important)
|
||||||
|
* Plan for localization
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
* Opentelemetry: Split by role (dev, ops)
|
||||||
|
* Prometheus:
|
||||||
|
* New user conent in intro (concept) and getting started (practice)
|
||||||
|
* Hierarchie includes concepts, key features and guides/tutorials
|
||||||
|
|
||||||
|
## Q&A
|
||||||
|
|
||||||
|
* Every last wednesday in the month is a cncf echnical writers meetin (cncf slack -> techdocs)
|
|
@ -0,0 +1,51 @@
|
||||||
|
---
|
||||||
|
title: Container Image Workflows at Scale with Buildpacks
|
||||||
|
weight: 5
|
||||||
|
---
|
||||||
|
|
||||||
|
A talk by Broadcom and Bloomberg (both related to buildpacks.io).
|
||||||
|
And a very full talk at that.
|
||||||
|
|
||||||
|
## Baselinbe
|
||||||
|
|
||||||
|
* CN Buildpack provides the spec for buildpacks with a couple of different implementations
|
||||||
|
* Pack CLI with builder (collection of buildopacks - for example ppaketo or heroku)
|
||||||
|
* Output images follow oci -> Just run them on docker/podman/kubernetes
|
||||||
|
* Built images are `production application images` (small attack surface, SBOM, non-root, reproducible)
|
||||||
|
|
||||||
|
## Scaling
|
||||||
|
|
||||||
|
### Builds
|
||||||
|
|
||||||
|
* Use in CI (Jenkins, GitHub Actions, Tekton, ...)
|
||||||
|
* KPack: Kubernetes operator -> Builds on new changes
|
||||||
|
|
||||||
|
### Multiarch support
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
flowchart LR
|
||||||
|
subgraph ii(OCI Image Index)
|
||||||
|
lamd(linux/amd64)
|
||||||
|
larm(linux(arm64)
|
||||||
|
end
|
||||||
|
ii->image
|
||||||
|
subgraph image
|
||||||
|
layer1
|
||||||
|
layer2
|
||||||
|
layer3
|
||||||
|
end
|
||||||
|
```
|
||||||
|
|
||||||
|
* Goal: Just a simple docker full that auto-detects the right architecture
|
||||||
|
* Needed: Pack, Lifecycle, Buildpacks, Build images, builders, registry
|
||||||
|
* Current state: There is an RFC to handle image index creation with changes to buildpack creation
|
||||||
|
* New folder structure for binaries
|
||||||
|
* Update config files to include targets
|
||||||
|
* The user impact is minimal, because the builder abstracts everything away
|
||||||
|
|
||||||
|
### Majority
|
||||||
|
|
||||||
|
* kpack is slsa.dev v3 compliant (party hard)
|
||||||
|
* 5 years of production
|
||||||
|
* scaling up to tanzu/heroku/gcp levels
|
||||||
|
* Multiarch is being worked on
|
|
@ -0,0 +1,10 @@
|
||||||
|
---
|
||||||
|
title: Networking
|
||||||
|
weight: 99
|
||||||
|
---
|
||||||
|
|
||||||
|
Who have I talked to today, are there any follow-ups or learnings?
|
||||||
|
|
||||||
|
## VMware
|
||||||
|
|
||||||
|
* Custoemr/partner dinner
|
|
@ -4,4 +4,4 @@ title: Day 3
|
||||||
weight: 3
|
weight: 3
|
||||||
---
|
---
|
||||||
|
|
||||||
Spent most of the early day with headache.
|
Spent most of the early day with headache therefor talk notes only start at noon.
|
||||||
|
|
|
@ -0,0 +1,16 @@
|
||||||
|
---
|
||||||
|
title: "TODO:"
|
||||||
|
weight: 1
|
||||||
|
---
|
||||||
|
|
||||||
|
## Problems
|
||||||
|
|
||||||
|
* Dockerfiles are hard and not 100% reproducible
|
||||||
|
* Buildpoacks are reproducible but result in large single-arch images
|
||||||
|
* Nix has multiple ways of doing things
|
||||||
|
|
||||||
|
## Solutions
|
||||||
|
|
||||||
|
* Degger as a CI solution
|
||||||
|
* Multistage docker images with distroless -> Small image, small attack surcface
|
||||||
|
* Language specific solutions (ki, jib)
|
|
@ -0,0 +1,54 @@
|
||||||
|
---
|
||||||
|
title: "eBPF’s Abilities and Limitations: The Truth"
|
||||||
|
weight: 2
|
||||||
|
---
|
||||||
|
|
||||||
|
A talk by isovalent with a full room (one of the large ones).
|
||||||
|
|
||||||
|
## Baseline
|
||||||
|
|
||||||
|
* eBPF lets you run custom code in the kernel -> close to hardware
|
||||||
|
* Typical usecases: Networking, Observability, Tracing/Profiling, security
|
||||||
|
* Question: Is eBPF truing complete and can it be used for more complex scenarios (TLS, LK7)?
|
||||||
|
|
||||||
|
## eBPF verifier
|
||||||
|
|
||||||
|
* The verifier analyzes the program to verify safety
|
||||||
|
* Principles
|
||||||
|
* Read memory only with correct permissions
|
||||||
|
* All writes to valid and safe memory
|
||||||
|
* Valid in-bounds and well formed control flow
|
||||||
|
* Execution on-cpu time is bounded: sleep, scheduled callbacks, interations, program acutally compketes
|
||||||
|
* Aquire/release and reference count semantics
|
||||||
|
|
||||||
|
## Demo: Game of life
|
||||||
|
|
||||||
|
* A random game of life map
|
||||||
|
* Implemented as a tetragon plugin
|
||||||
|
* Layout: Main control loop that loads the map, generates the next generation, and returns a next run function
|
||||||
|
* The timer callback pattern is used for infinite run
|
||||||
|
|
||||||
|
## eBPF Limits & workarounds
|
||||||
|
|
||||||
|
* Instruction limit to let the verifier actually verify the program in reasonable time
|
||||||
|
* Limit is based on: Instruction limit and verifier step limit
|
||||||
|
* nowadays the limit it 4096 unprivileged calls and 1 million privileged istructions
|
||||||
|
* Only jump forward -> No loops
|
||||||
|
* Is a basic limitation to ensure no infinite loops can ruin the day
|
||||||
|
* Limitation: Only finite iterations can be performed
|
||||||
|
* Loops: Newer versions support loops with upper bounds (`for x=0;: x<100`)
|
||||||
|
* Is the instruction limit hard?
|
||||||
|
* Solution: subprogram (aka function) and the limit is only for each function -> `x*subprogramms = x*limit`
|
||||||
|
* Limit: Needs real skill
|
||||||
|
* Programs have to terminate
|
||||||
|
* Well eBPF really only wants to release the cpu, the program doesn't have to end per se
|
||||||
|
* Iterator: walk abitrary lists of objects
|
||||||
|
* Sleep on pagefault or other memory operations
|
||||||
|
* Timer callbacks (including the timer 0 for run me asap)
|
||||||
|
* Memory allocation
|
||||||
|
* Maps are used as the memory management system
|
||||||
|
|
||||||
|
## Result
|
||||||
|
|
||||||
|
* You can execure abitrary tasks via eBPF
|
||||||
|
* It can be used for HTTP or TLS - it's just not implemented yet™
|
|
@ -0,0 +1,55 @@
|
||||||
|
---
|
||||||
|
title: What's New in Operator Framework?
|
||||||
|
weight: 3
|
||||||
|
---
|
||||||
|
|
||||||
|
By the nice opertor framework guys at IBM and RedHat.
|
||||||
|
I'll skip the baseline introduction of what an operator is.
|
||||||
|
|
||||||
|
## Operator DSK
|
||||||
|
|
||||||
|
> Build the operator
|
||||||
|
|
||||||
|
* Kubebuilder with v4 Plugines -> Supports the latest Kubernetes
|
||||||
|
* Java Operator SDK is not a part of Operator SDK and they released 5.0.0
|
||||||
|
* Now with server side apply in the background
|
||||||
|
* Better status updates and finalizer handling
|
||||||
|
* Dependent ressource handling (alongside optional dependent ressources)
|
||||||
|
|
||||||
|
## Operator Liefecycle Manager
|
||||||
|
|
||||||
|
> Manage the operator -> A operator for installing operators
|
||||||
|
|
||||||
|
### OLM v1 APIs
|
||||||
|
|
||||||
|
* New API Set -> The old CRDs were overwhelming
|
||||||
|
* More GitOps friendly with per-tenant support
|
||||||
|
* Prediscribes update paths (maybe upgrade)
|
||||||
|
* Suport for operator bundels as k8s manifests/helmchart
|
||||||
|
|
||||||
|
### OLM v1 Components
|
||||||
|
|
||||||
|
* Cluster Extension (User-Facing API)
|
||||||
|
* Defines the app you want to install
|
||||||
|
* Resolvs requirements through catalogd/depply
|
||||||
|
* Catalogd (Catalog Server/Operator)
|
||||||
|
* Depply (Dependency/Contraint solver)
|
||||||
|
* Applier (Rukoak/kapp compatible)
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
flowchart TD
|
||||||
|
uapi(User facing api)-->|Can I find this operator|catalaogd
|
||||||
|
catalogd-->|Check if all dependencies are checked|depply
|
||||||
|
depply-->|Please install|kapp
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
flowchart LR
|
||||||
|
oa(operator author)-->ba(Bundle and att to catalog)
|
||||||
|
ba-->catalogd(Catalogd Handle unpackling)
|
||||||
|
|
||||||
|
user-->ufa(User facing api)
|
||||||
|
ufa-->|Resolve package|catalogd
|
||||||
|
ufa-->|Create app on cluster|appcr(App CR / kapps)
|
||||||
|
```
|
|
@ -0,0 +1,73 @@
|
||||||
|
---
|
||||||
|
title: "Cryptographically Signed Swag: Cert-Manager’s Stamped Certificates"
|
||||||
|
weight: 5
|
||||||
|
---
|
||||||
|
|
||||||
|
A talk by the certmanager maintainers that also staffed the certmanager booth.
|
||||||
|
Humor is present, but the main focus is still thetechnical integration
|
||||||
|
|
||||||
|
## Baseline
|
||||||
|
|
||||||
|
* Certmanager is the best™ way of getting certificats
|
||||||
|
* Poster features: Autorenewal, ACME, PKI, HC Vault
|
||||||
|
* Numbers: 20M downloads 427 contributors 11.3 GitHub stars
|
||||||
|
* Currently on the gratuation path
|
||||||
|
|
||||||
|
## History
|
||||||
|
|
||||||
|
* 2016: Jetstack created kube-lego -> A operator that generated LE certificates for ingress based on annotations
|
||||||
|
* 2o17: Certmanager launch -> Cert ressources and issuer ressources
|
||||||
|
* 2020: v1.0.0 and joined CNCF sandbox
|
||||||
|
* 2022: CNCF incubating
|
||||||
|
* 2024: Passed the CNCF security audit and on the way to graduation
|
||||||
|
|
||||||
|
## The booth works
|
||||||
|
|
||||||
|
### How it came to be
|
||||||
|
|
||||||
|
* The idea: Mix the digital certificate with the classical seal
|
||||||
|
* Started as the stamping idea to celebrate v1 and send contributors a thank you with candels
|
||||||
|
* Problems: Candels are not allowed -> Therefor glue gun
|
||||||
|
|
||||||
|
### How it works
|
||||||
|
|
||||||
|
* Components
|
||||||
|
* RASPI with k3s
|
||||||
|
* Printer
|
||||||
|
* Certmanager
|
||||||
|
* A go-based webui
|
||||||
|
* QR-Code: Contains link to certificate with privatekey
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
flowchart LR
|
||||||
|
ui(UI in go)-->|Generate cert ressource|kubeapi
|
||||||
|
kubeapi-->|Issue certificate|CertManager
|
||||||
|
CertManager-->|Certificate|ui
|
||||||
|
ui-->|print|Printer
|
||||||
|
```
|
||||||
|
|
||||||
|
### What is new this year
|
||||||
|
|
||||||
|
* Idea: Certs should be usable for TLS
|
||||||
|
* Solution: The QR-Code links to a zip-download with the cert and provate key
|
||||||
|
* New: ECDSA for everything
|
||||||
|
* New: A stable root ca with intermediate for every conference
|
||||||
|
* New: Guestbook that can only be signed with a booth issued certificate -> Available via script
|
||||||
|
|
||||||
|
## Learnings
|
||||||
|
|
||||||
|
* This demo is just a private CA with certmanager -> Can be applied to any PKI-usecase
|
||||||
|
* The certificate can be created via the CR, CSI driver (create secret and mount in container), ingress annotations, ...
|
||||||
|
* You can use multiple different Issuers (CA Issuer aka PKI, Let's Encrypt, Vault, AWS, ...)
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
flowchart LR
|
||||||
|
ui-->|Input certificate subject details|CertManager
|
||||||
|
cai(CA Issuer)-->|CertManager|Souurce for certificate
|
||||||
|
CertManager-->|Creates|sr(Secret Ressource)
|
||||||
|
```
|
||||||
|
|
||||||
|
## Conclusion
|
||||||
|
|
||||||
|
* This is not just a demo -> Just apply it for machines
|
||||||
|
* They have regular meetings (daily standups and bi-weekly)
|
|
@ -0,0 +1,34 @@
|
||||||
|
---
|
||||||
|
title: Networking
|
||||||
|
weight: 99
|
||||||
|
---
|
||||||
|
|
||||||
|
Who have I talked to today, are there any follow-ups or learnings?
|
||||||
|
|
||||||
|
## Fastly
|
||||||
|
|
||||||
|
* They were nice and are always up to talk if we ever need something
|
||||||
|
|
||||||
|
## Ozone
|
||||||
|
|
||||||
|
{{% notice style="note" %}}
|
||||||
|
They will follow up with a quick demo
|
||||||
|
{{% /notice %}}
|
||||||
|
|
||||||
|
* A interesting tektone-based CI/CD solutions that also integrates with oter platforms
|
||||||
|
* May be interesting for either ODIT or some of our customers
|
||||||
|
|
||||||
|
## Docker
|
||||||
|
|
||||||
|
* Talked to one salesperson just aboput the general conference
|
||||||
|
* Talked to one technical guy about docker buildtime optimization
|
||||||
|
|
||||||
|
## Rancher/Suse
|
||||||
|
|
||||||
|
* I just got some swag, Maik got a demo focussing on runtime security
|
||||||
|
|
||||||
|
## Kong
|
||||||
|
|
||||||
|
* They didn't have any Insomina stickers and the insomnia guy apparently already left
|
||||||
|
|
||||||
|
## Planetscale
|
|
@ -0,0 +1,6 @@
|
||||||
|
---
|
||||||
|
archetype: chapter
|
||||||
|
title: Day 4
|
||||||
|
---
|
||||||
|
|
||||||
|
The last day with a limited sponsor expo (10:00-14:30) and a bunch of people on the move (not me)
|
|
@ -6,3 +6,4 @@ Just a loose list of stuff that souded interesting
|
||||||
|
|
||||||
* Dapr
|
* Dapr
|
||||||
* etcd backups
|
* etcd backups
|
||||||
|
* Prow (labeling)
|
||||||
|
|
Loading…
Reference in New Issue