Networking on thursday

content/_template/01_opening.md

@@ -1,3 +0,0 @@
----
-title: Opening Keynotes
----

content/_template/_index.md

@@ -1,4 +0,0 @@
----
-archetype: chapter 
-title: template
----

content/day2/99_networking.md

@@ -52,3 +52,7 @@ I should follow up
 
 * 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 
+
+### Certmanager
+
+* The best swag (judged by coolness points)

content/day3/03_oss_business_value.md

@@ -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

content/day3/04_towards_great_docs.md

@@ -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)

content/day3/05_buildpacks.md

@@ -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

content/day3/99_networking.md

@@ -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

content/day3/_index.md

@@ -4,4 +4,4 @@ title: Day 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.

content/day4/01_container_images.md

@@ -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)

content/day4/02_ebpf.md

@@ -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™

content/day4/03_operator.md

@@ -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)
+```

content/day4/05_certmanager.md

@@ -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)

content/day4/99_networking.md

@@ -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

content/day4/_index.md

@@ -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)

content/lessons_learned/99_checkout.md

@@ -6,3 +6,4 @@ Just a loose list of stuff that souded interesting
 
 * Dapr
 * etcd backups
+* Prow (labeling)