DEV Community: José Castillo Lema

Development workflows on inmutable distros: rootless setup

José Castillo Lema — Sat, 21 Oct 2023 05:00:00 +0000

Continuation of Samsai notes on Toolbox-based Emacs Flatpak workflow.

I have been using inmutable OS distributions for a while (Fedora Silverblue and Sericea, see my dotfiles). They have the following characteristics:

System root (baseOS) is mostly immutable
System software installation/updates are handled as images and applied on reboot
For installing desktop applications, Flatpak is the recommended default route
Toolbx can be used to set up containerized Linux environments for developer tools, these containers will mount your home directory and certain important files for GUI programs to work as well
Local user (rootless) installations

I personally follow these guidelines when installing new applications:

If it is a desktop application, prefer Flatpak (and some terminal ones too, i.e.: Neovim and Emacs)
For terminal applications, consider Toolbx or local installations
Do not install desktop applications into Toolbx
Avoid duplication (i.e.: installing the same editors or development environments in several places)
Try to avoid rpm-ostree layering on baseOS as much as possible

The development workflow story on inmutable distros hasn’t really been standardized yet, as these distros are quite new. Let’s take a look at several approaches and finally discuss the local (rootless) installation method.

Layering with rpm-ostree (not a good idea)

You can also install development tools directly on the inmutable distros install using package layering with rpm-ostree. So, if you want to, you can install your editor, compilers, build tools and linters straight on the Silverblue install.

However, this isn’t really how most people view you should use Silverblue. The application installation process is a bit more annoying, although experimental support for installing software without rebooting does exist nowadays. It also makes your system install kind of messy due to large numbers of overlayed packages.

I wouldn’t take this route because while you aren’t strictly speaking losing all of the benefits of inmutable distros, you are making life quite difficult for yourself compared to just using regular Fedora Workstation for instance. You also don’t get the benefits of separating your system from your application environments and expose yourself to more potential breakages.

Toolbx approaches

Single toolbx container for all dev activities

The easiest way to have everything working in a predictable and simple manner is to create a single Toolbox container, which has all of the development tools for every single project installed within it. This means that the container contains your text editor of choice, compilers, linters, build tools and all of their dependencies.

The benefit of this approach is that it is extremely close to how you’d work on any other Linux distribution.

This approach has several drawbacks:

All software pilled into one environment
Keeping the text editor inside the Toolbox still results in somewhat poor integration with the host system
Install desktop applications into toolbx containers instead of Flatpak applications

A toolbx container per language / project

Another (better IMO) possibility is to separately set up a Toolbox container for each project you work on. This means that all of your project environments are fully separated from each other and all of them only carry tools and dependencies relevant to the project in question.

Loss of a Toolbox container limits the damage to a particular project and per-project Toolboxes are fairly simple to recreate.

Drawbacks:

Certain parts of your development workflow need to be duplicated. You potentially need to install your text editor and all of its required dependencies and tools in each environment.
Keeping the text editor inside the Toolbox still results in somewhat poor integration with the host system.

Flatpak approach

You can install Flatpak SDKs such as the Rust build tools like this:

$ flatpak install org.freedesktop.Sdk.Extension.rust-stable

And then load them into a Flatpak editor using an SDK extension flag:

$ FLATPAK_ENABLE_SDK_EXT=rust-stable flatpak run com.visualstudio.code

or just load every SDK available in your local setup:

$ FLATPAK_ENABLE_SDK_EXT=* flatpak run com.visualstudio.code

This causes the tools and libraries from that SDK to be made visible to the Flatpak application. There are Flatpak SDKs for a few languages like Java, Rust, Haskell, PHP and Node, but obviously support for all use-cases does not exist. But if you only plan to develop in languages that already have an SDK ready or are willing to learn how to package more SDKs, then this approach is definitely viable for things like Neovim, Emacs and VSCode Flatpaks.

Drawbacks:

Some languages do not have an SDK available
Limited to the language runtime versions available in the SDKs
Duplication of the language runtime (plus you will need to install all the library dependencies on the Flatpak to have proper code support from your editor)

Combined approach

You can also mix approaches such that part of the development activity happens outside Toolbox and part of it inside the Toolbox. The simplest case would be installing your text editor via Flatpak for example and then connecting from that text editor to a Toolbox for project-specific tools like compilers.

The benefit here is that you can install tools where they make most sense and where they integrate the best. So, you will get your nice app launchers and the ability to keep project environments separate.

Tools available:

For VSCode
- Dev Containers extension
- toolbox-vscode: a script that configures the current toolbox container to work with the Remote Containers Visual Studio Code extension
For Emacs
- toolbox-tramp
For Neovim
- nvim --remote ?
- nvim-remote-containers

User (rootless) installations

I have not seen much information about this method anywhere and for me as of today it is the prefered approach. Flatpak applications (i.e.: editors) cannot access the root filesystem (i.e.: the preinstalled python package on /usr/bin/python). However they have full access to the home directory (same as Toolbx containers).

So installing the development runtimes and tools locally (and then configuring your Flatpak editor to use them) provides an excelent out of the box developer experience without the need of Flatpak SDKs nor plugins to enable your editor to access the Toolbx containers.

Drawbacks:

It can be more time consuming to set up than normal rpm installs in some scenarios
No automatic updates

Let’s take a look at local installs for several platforms.

OCaml

We will leverage the OCaml Package Manager (opam) to install the platform (or several versions) and local switches to each project:

$ curl https://github.com/ocaml/opam/releases/download/2.1.5/opam-2.1.5-i686-linux -Lo ~/bin/opam && chmod +x ~/bin/opam

From a toolbx container with proper development tools, i.e.: this one incialize the opam environment and install the platform tools:

⬢ $ opam init
⬢ $ opam install dune ocaml-lsp-server odoc ocamlformat utop

Optionally, install some extras for Emacs, Vim and Neovim:

⬢ $ opam install ocp-indent ocp-index merlin tuareg

We need to add the opam path (~/bin) to our editor of choice (i.e.: VSCode) path:

$ sudo flatpak override --env=PATH='/app/bin:/usr/bin:/home/$USER/bin:/home/$USER/.opam/default/bin' com.visualstudio.code

Finally, open the project in VSCode and choose the corresponding opam switch.

Using local switches

It is possible to define a switch within the source of a project to be used specifically in that project. If a local switch is detected in the current directory or a parent, opam will select it automatically.

⬢ $ opam switch create .

Finally, open the project in VSCode and choose the corresponding recommended opam switch.

Golang

Download latest version:

$ mkdr ~/go
$ curl https://go.dev/dl/go1.21.3.linux-amd64.tar.gz -Lo ~/go.tar.gz
$ tar xf ~/go/go.tar.gz
$ mv ~/go/go ~/go/go-1.21.3

Add the following environment variables to your environment:

export GOROOT=$HOME/go/go-1.21.3
export GOPATH=$HOME/go
export PATH=$PATH:$GOROOT/bin:$GOPATH/bin

Check installation:

$ go version
go version go1.21.3 linux/amd64

Finally, open VSCode (it should automatically detect the local Golang installation), install the Go VSCode extension and click on ⚠ Analysis Tools Missing to install those.

Python

Local install

Install both python and pip in the local user environment.

From a toolbx container with proper development tools, i.e.: this one download and compile Python:

⬢ $ wget https://www.python.org/ftp/python/3.12.0/Python-3.12.0.tgz
⬢ $ tar -xf Python-3.?.?.tar.xz
⬢ $ cd Python-3.?.?.tar.xz
⬢ $ ./configure --prefix=$HOME
⬢ $ make install
⬢ $ ln -s ~/bin/python3 ~/bin/python
⬢ $ pip install readline

Then you can just pip install any dependencies, open the project in VSCode and choose the corresponding Python environment ~/bin/python. I do not tend to pip install the requirements of the projects thought (only the indispensable ones, like i.e.: ansible), instead prefer the virtual environments approach that will be described next.

Using python virtual environments

Before opening the project in VSCode:

$ flatpak run --command=sh com.visualstudio.code
[📦] python -m venv .
[📦] source bin/activate
()[📦] pip install -r requirements.txt

Then open the project in VSCode and choose the local virtual environment.

Ansible

Python local install is a pre-requisite.

Local ansible installation:

python -m pip install --user ansible ansible-lint

Ansible will be installed on ~/.local/bin, so we need to add this path to our editor of choice (i.e.: VSCode):

$ which ansible
~/.local/bin/ansible
$ sudo flatpak override --env=PATH='/app/bin:/usr/bin:/home/$USER/.local/bin' com.visualstudio.code

Installed the Ansible extension by Red Hat in VSCode and enabled Lightspeed.

When opening VSCode it should automatically detect the local Ansible installation.

Kubemark on OpenShift

José Castillo Lema — Tue, 19 Sep 2023 05:00:00 +0000

Kubemark is a performance testing tool which allows users to run experiments on simulated clusters, by creating “hollow” Kubernetes nodes. What this means is that the nodes do not actually run containers or attach storage, but they do behave like they did, with updates to etcd and all the trimmings. At the same time, hollow nodes are extremely light (<30 MiB).

The primary use case of Kubemark is scalability testing, as simulated clusters can be much bigger than the real ones. The objective is to expose problems with the master components (API server, controller manager or scheduler) that appear only on bigger clusters (e.g. small memory leaks).

Hands to work

We won’t be using the Cluster API Kubemark Provider for this demo, and instead we will be using directly Kubemark itself.

Let’s assume we have a working OpenShift cluster available. We will be leveraging a Red Hat OpenShift Local instance (formerly Red Hat CodeReady Containers) for this demo:

❯ oc version
Client Version: 4.13.6
Kustomize Version: v4.5.7
Server Version: 4.13.6
Kubernetes Version: v1.26.6+73ac561

❯ oc get node
NAME STATUS ROLES AGE VERSION
crc-2zx29-master-0 Ready control-plane,master,worker 54d v1.26.6+73ac561

Let’s create a new project , secret and corresponding permissions :

❯ oc new-project kubemark
Now using project "kubemark" on server "https://api.crc.testing:6443".

❯ oc create secret generic kubeconfig --from-file=kubeconfig=$KUBECONFIG
secret/kubeconfig created

❯ oc adm policy add-scc-to-user privileged -z default
clusterrole.rbac.authorization.k8s.io/system:openshift:scc:privileged added: "default"

Let’s create the Kubemark pod (which in turn will automatically instantiate a new node):

❯ cat <<EOF | oc apply -f -
apiVersion: v1
kind: Pod
metadata:
  labels:
    app: hollow-node
  name: kubemark-node
  namespace: kubemark
spec:
  containers:
    - args:
        - --v=3
        - --morph=kubelet
        - --name=kubemark-node
        - --extended-resources=cpu=1,memory=4G
      command:
        - /kubemark
      image: quay.io/cluster-api-provider-kubemark/kubemark:v1.26.7
      name: hollow-node
      securityContext:
        privileged: true
      volumeMounts:
        - mountPath: /kubeconfig
          name: kubeconfig
        - mountPath: /run/containerd/containerd.sock
          name: containerd-sock
  volumes:
    - name: kubeconfig
      secret:
        defaultMode: 420
        secretName: kubeconfig
    - hostPath:
        path: /run/crio/crio.sock
        type: Socket
      name: containerd-sock
EOF
pod/kubemark-node created

Let’s check the if new node was properly registered:

❯ oc get po
NAME READY STATUS RESTARTS AGE
kubemark-node 1/1 Running 0 5s

❯ oc get node
NAME STATUS ROLES AGE VERSION
crc-2zx29-master-0 Ready control-plane,master,worker 54d v1.26.6+73ac561
kubemark-node Ready <none> 4s v1.26.7

The cluster should be healthy:

❯ oc get co
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE
authentication 4.13.6 True False False 12d
cluster-api 4.13.6 True False False 13d
config-operator 4.13.6 True False False 54d
console 4.13.6 True False False 12d
control-plane-machine-set 4.13.6 True False False 54d
dns 4.13.6 True False False 12d
etcd 4.13.6 True False False 54d
image-registry 4.13.6 True False False 12d
ingress 4.13.6 True False False 54d
kube-apiserver 4.13.6 True False False 54d
kube-controller-manager 4.13.6 True False False 54d
kube-scheduler 4.13.6 True False False 54d
kube-storage-version-migrator 4.13.6 True False False 12d
machine-api 4.13.6 True False False 54d
machine-approver 4.13.6 True False False 54d
machine-config 4.13.6 True False False 54d
marketplace 4.13.6 True False False 54d
network 4.13.6 True False False 54d
openshift-apiserver 4.13.6 True False False 12d
openshift-controller-manager 4.13.6 True False False 12d
openshift-samples 4.13.6 True False False 54d
operator-lifecycle-manager 4.13.6 True False False 54d
operator-lifecycle-manager-catalog 4.13.6 True False False 54d
operator-lifecycle-manager-packageserver 4.13.6 True False False 119m
platform-operators-aggregated 4.13.6 True False False 119m
service-ca 4.13.6 True False False 54d

And there should a few pods already “running” in the new hollow node:

❯ oc get pods -A --field-selector spec.nodeName=kubemark-node
NAMESPACE NAME READY STATUS RESTARTS AGE
hostpath-provisioner csi-hostpathplugin-8p9j5 4/4 Running 0 17m
openshift-dns dns-default-lt7g8 2/2 Running 0 17m
openshift-dns node-resolver-9plz7 1/1 Running 0 17m
openshift-image-registry node-ca-x7hq7 1/1 Running 0 17m
openshift-ingress-canary ingress-canary-l2mlx 1/1 Running 0 17m
openshift-machine-config-operator machine-config-daemon-smq5z 2/2 Running 0 17m
openshift-multus multus-7xp8p 1/1 Running 0 17m
openshift-multus multus-additional-cni-plugins-rv6j7 0/1 Init:0/6 0 17m
openshift-multus network-metrics-daemon-zh2vz 2/2 Running 0 17m
openshift-network-diagnostics network-check-target-l85xq 1/1 Running 0 17m
openshift-sdn sdn-rv9mb 2/2 Running 0 17m

Let’s try to create some pods on the new hollow node:

❯ oc run test --image nginx --overrides='{"spec": { "nodeSelector": {"kubernetes.io/hostname": "kubemark-node"}}}'
pod/test created

❯ oc get po -o wide test
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
test 1/1 Running 0 36s 192.168.192.168 kubemark-node <none> <none>

Finally, bear in mind that in order to create new hollow nodes you will have to change two fields in the pod definition:

The pod name: metadata.name
The name of the hollow node: spec.containers.args.--name

DevConf.CZ 2023 - Writing a K8s Operator for Knative Functions

José Castillo Lema — Tue, 23 May 2023 05:00:00 +0000

About

DevConf.CZ is an annual, free, Red Hat sponsored community conference for developers, admins, DevOps engineers, testers, documentation writers and other contributors to open source technologies. At DevConf.CZ, FLOSS communities sync, share, and hack on upstream projects together.

DevConf.cz Mini is a bi-annual, highly focused, local, in-person version of DevConf.cz. It offers an opportunity to return to our conference themes in a smaller setting and establishes a platform for the Czech Republic and EMEA based community to sync, share and hack on upstream projects together.

There is no admission or ticket charge for DevConf.CZ events. However, you are required to complete a free registration. Watch this site for updates about registration.

We are committed to fostering an open and welcoming environment at our conference. We set expectations for inclusive behavior through our code of conduct and media policies, and are prepared to enforce these.

Schedule

Writing a K8s Operator for Knative Functions

Serverless and Function as a Service (FaaS) are getting more and more attention from customers and developers as a way to develop, run and manage applications functionality without the burden of infrastructure related knowledge. All big cloud providers offer them already, e.g., AWS Lambda, Google Cloud Functions or Microsoft Azure Functions. One of the most relevant upstream projects for serverless is Knative, which recently added support for functions (create, build, and deploy) on top of K8s clusters.

This workshop will introduce you to the the PHYSICS European project and its FaaS model, as well as to building Kubernetes operators. You will implement a K8s Operator, using the operatorsdk framework, to provide the functionality of the Knative CLI. This will allow easier creation, build and deployment of functions with Knative just by creating Kubernetes (CR) objects, and will help you learn the internals about how K8s Operators work in a real life example.

Friday June 16, 2023 • 2:15pm - 3:35pm CEST

Speakers

Luis Tomas Bolivar - Software Engineer at Red Hat
Jose Castillo Lema - Software Engineer at Red Hat

Workshop

physics-devconf

This repository provides an easy way to deploy a KinD cluster with Knative (using this script) on top of a Fedora 37 VM.

It also provides a couple of sample scripts to deploy a Knative service and a function.

Index

physics-devconf
- Index
- Goals
- Deploy the environment (VM)
- Access the environment
- Create a new (python) function and invoke it
- Fork the base operator github repository and deploy locally
- Solution
- Links

Goals

Get familiar on how to create/test Knative functions
Get familiar with the operator SDK

Deploy the environment (VM)

The VM requires 4 vCPUs and 6GB of memory. It takes approximately 10 minutes to come up:

$ vagrant up
Bringing machine 'default' up with 'libvirt' provider...
==> default: Checking if box 'fedora/37-cloud-base' version '37.20221105.0' is up to date...
==> default: Creating image (snapshot of base box volume).
==> default: Creating domain with the following settings...
...
    default: configmap/config-br-defaults configured
    default: ⑦ Dapr
    default: ./allocate.sh: line 251: dapr: command not found
    default: popd
    default: ~/go/src/github.com/knative/func
    default:
    default: cat <<EOF | sudo tee /etc/docker/daemon.json
    default: {"insecure-registries": ["localhost:50000"]}
    default: EOF
    default: {"insecure-registries": ["localhost:50000"]}

The provision script installs:

Docker
Golang
Pip
Git
Curl
Wget
Cosign
Kubectl
Kn - the Knative client
Func - Knative functions
Kind
Operator-sdk

Access the environment

 $ vagrant ssh

Check if all the pods are running:

 $ kubectl get pods -A
 NAMESPACE NAME READY STATUS RESTARTS AGE
 contour-external contour-56cfd44877-gmzdd 1/1 Running 0 2m30s
 contour-external contour-56cfd44877-wj844 1/1 Running 0 2m30s
 contour-external contour-certgen-v1.22.0-qbbx6 0/1 Completed 0 2m30s
 contour-external envoy-4j2vr 2/2 Running 0 2m30s
 contour-internal contour-865fdc98f9-48vv9 1/1 Running 0 2m29s
 contour-internal contour-865fdc98f9-l22kw 1/1 Running 0 2m29s
 contour-internal contour-certgen-v1.22.0-5t52p 0/1 Completed 0 2m30s
 contour-internal envoy-vlxrb 2/2 Running 0 2m29s
 knative-eventing eventing-controller-64b4b79c45-bxk6f 1/1 Running 0 4m5s
 knative-eventing eventing-webhook-86f7dd95db-phc9x 1/1 Running 0 4m5s
 knative-eventing imc-controller-769d8b7f66-hx2lj 1/1 Running 0 3m33s
 knative-eventing imc-dispatcher-55979cf74b-8n2w9 1/1 Running 0 3m33s
 knative-eventing mt-broker-controller-f97f8747-r7nnr 1/1 Running 0 3m21s
 knative-eventing mt-broker-filter-77c75d69fb-j4972 1/1 Running 0 3m21s
 knative-eventing mt-broker-ingress-d96f6d8b5-g4ng6 1/1 Running 0 3m21s
 knative-serving activator-75777fd57c-hwsth 1/1 Running 0 4m49s
 knative-serving autoscaler-57d647d6ff-cs2bx 1/1 Running 0 4m49s
 knative-serving controller-677995dc7b-9tbmj 1/1 Running 0 4m48s
 knative-serving domain-mapping-5676fb7bcf-92xmf 1/1 Running 0 4m48s
 knative-serving domainmapping-webhook-fcbd7dff4-5v26r 1/1 Running 0 4m48s
 knative-serving net-contour-controller-847758c4bf-kltdx 1/1 Running 0 2m
 knative-serving webhook-544b958c69-h7vmz 1/1 Running 0 4m48s
 kube-system coredns-6d4b75cb6d-btqsp 1/1 Running 0 5m16s
 kube-system coredns-6d4b75cb6d-shbkf 1/1 Running 0 5m16s
 kube-system etcd-func-control-plane 1/1 Running 0 5m35s
 kube-system kindnet-mr2xx 1/1 Running 0 5m16s
 kube-system kube-apiserver-func-control-plane 1/1 Running 0 5m30s
 kube-system kube-controller-manager-func-control-plane 1/1 Running 0 5m30s
 kube-system kube-proxy-vpb8z 1/1 Running 0 5m16s
 kube-system kube-scheduler-func-control-plane 1/1 Running 0 5m32s
 local-path-storage local-path-provisioner-6b84c5c67f-575j5 1/1 Running 0 5m16s
 metallb-system controller-6c58495cbb-j52ls 1/1 Running 0 3m3s
 metallb-system speaker-v5hd2 1/1 Running 0 3m3s

Check if the local registry is running:

 $ docker ps
 CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
 59be051ba43c registry:2 "/entrypoint.sh /etc…" 2 minutes ago Up 2 minutes 127.0.0.1:50000->5000/tcp func-registry
 caf78811a6a9 kindest/node:v1.24.6 "/usr/local/bin/entr…" 4 minutes ago Up 4 minutes 127.0.0.1:39609->6443/tcp, 127.0.0.1:80->30080/tcp, 127.0.0.1:443->30443/tcp func-control-plane

Create a new (python) function and invoke it

Create the Knative function:

 $ func create -l python test-hw
 Created python function in /home/vagrant/test-hw

Take a look around and change the func.py code as follows:

 $ cd test-hw

 $ ls
 app.sh func.py func.yaml Procfile README.md requirements.txt test_func.py

 $ cat func.py


 from parliament import Context
 from flask import Request
 import json

 # parse request body, json data or URL query parameters
 def payload_print(req: Request) -> str:
     if req.method == "GET":
         return "DevConf.cz 2023!"

 def main(context: Context):
     """
     Function template
     The context parameter contains the Flask request object and any
     CloudEvent received with the request.
     """

     # Add your business logic here
     print("Received request")

     if 'request' in context.keys():
         return payload_print(context.request), 200
     else:
         print("Empty request", flush=True)
         return "{}", 200

Build (and push) the function to the internal registry:

 $ export FUNC_REGISTRY=localhost:50000/kn-user
 $ func build --push
 🙌 Function image built: localhost:50000/kn-user/test-hw:latest
 🕕 Pushing function image to the registry "localhost:50000" using the "" user credentials

Check that the image has been correctly pushed into the internal registry:

 $ curl localhost:50000/v2/_catalog
 {"repositories":["kn-user/test-hw"]}

Deploy the function to the kind cluster:

 $ func deploy --build=false --push=false
 ✅ Function deployed in namespace "default" and exposed at URL:
      http://test-hw.default.127.0.0.1.sslip.io

Check that the function has been correctly deployed. A new Knative service (ksvc) object is created, which triggers the Knative controllers to create the other k8s objects (deployment and route). After approximately one minute minute the deployment is scaled down to 0 replicas if not used to spare resources:

 $ kubectl get ksvc
 NAME URL LATESTCREATED LATESTREADY READY REASON
 test-hw http://test-hw.default.127.0.0.1.sslip.io test-hw-00001 test-hw-00001 True

 $ kubectl get deploy
 NAME READY UP-TO-DATE AVAILABLE AGE
 test-hw-00001-deployment 0/0 0 0 104s

 $ kubectl get route
 NAME URL READY REASON
 test-hw http://test-hw.default.127.0.0.1.sslip.io True

 $ kubectl get pods
 (empty if more than a minute has passed)

Invoke the function:

$ curl http://test-hw.default.127.0.0.1.sslip.io
DevConf.cz 2023!

Check that the deployment has been scaled up:

$ kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
test-hw-00001-deployment 1/1 1 1 3s

Fork the base operator github repository and deploy locally

Fork this github repository into your github account: https://github.com/luis5tb/devconf-knative-operator
Clone your fork locally inside the VM (change YOUR_USER by yours):

$ git clone https://github.com/YOUR_USER/devconf-knative-operator.git

In case you want to start an operator from scratch do the next instead (change YOUR_USER by yours):

$ mkdir devconf-knative-operator
$ cd devconf-knative-operator

# Create base operator
$ operator-sdk init --domain example.com --repo github.com/YOUR_USER/devconf-knative-operator

# Add API
$ operator-sdk create api --group knf --version v1alpha1 --kind KnativeFunction --resource --controller

There are three important files to consider:
- controllers/knativefunction_controller.go : implements the operator reconcile loop
- api/v1alpha1/knativefunction_types.go : the KnativeFunction CRD definition
- config/samples/knf_v1alpha1_knativefunction.yaml : an example KnativeFunction CRD
Let’s take a look at api/v1alpha1/knativefunction_types.go , as you can see it defines an example Foo field:

...
type KnativeFunctionSpec struct {
    // Foo is an example field of KnativeFunction. Edit knativefunction_types.go to remove/update
    Foo string `json:"foo,omitempty"`
}
...

Let’s modify the operator reconcyle loop in controllers/knativefunction_controller.go :
Test your code by deploying it. You will need two terminals, T1 and T2.
[T2] In a second terminal create a sample CRD:

$ cat <<EOF | kubectl apply -f -
---
apiVersion: knf.example.com/v1alpha1
kind: KnativeFunction
metadata:
labels:
    app.kubernetes.io/name: knativefunction
    app.kubernetes.io/instance: knativefunction-sample
    app.kubernetes.io/part-of: devconf-knative-operator
    app.kubernetes.io/managed-by: kustomize
    app.kubernetes.io/created-by: devconf-knative-operator
name: knativefunction-sample
spec:
   foo: test
EOF

[T1] In the first terminal you should see something like:

2023-06-16T08:12:54Z    INFO    Received a request to create a new knativefunction  {"controller": "knativefunction", "controllerGroup": "knf.example.com", "controllerKind": "KnativeFunction", "KnativeFunction": {"name":"knativefunction-sample","namespace":"default"}, "namespace": "default", "name": "knativefunction-sample", "reconcileID": "9be34733-bca6-4134-bf6d-8f0ed69106bd", "Foo =": "test"}

[Challenge] The goal now is to extend the operator to deploy the existing Knative function (from step 6). Once this is accomplished, extend the operator to build, push and deploy any function located on a given github repository.

Solution

Deploy a CR to force the controller to reconcile and get the function deployed. First you need to edit the config/samples/knf_v1alpha1_knativefunction.yaml with the desired options:
To check the operator did its job, beside seeing the make install run logs, you can check as before:

DEV Community: José Castillo Lema

Development workflows on inmutable distros: rootless setup

Layering with rpm-ostree (not a good idea)

Toolbx approaches

Single toolbx container for all dev activities

A toolbx container per language / project

Flatpak approach

Combined approach

User (rootless) installations

OCaml

Using local switches

Golang

Python

Local install

Using python virtual environments

Ansible

Kubemark on OpenShift

Hands to work

DevConf.CZ 2023 - Writing a K8s Operator for Knative Functions

About

Schedule

Speakers

Links

Workshop

physics-devconf

Index

Goals

Deploy the environment (VM)

Access the environment

Create a new (python) function and invoke it

Fork the base operator github repository and deploy locally

Solution

Links