Andrey Smirnov smira

flowchart TD
    BASE("Base Cloud Provider Code")
    QEMU("QEMU Cloud Provider")
    METAL("METAL Cloud Provider")
    TALEMU("Talemu Cloud Provider")
    KUBEVIRT("KubeVirt Cloud Provider")
    MC("Managed Control Planes")
    MP("Machine Pools /manual scaling/")
 MCA("Machine Class auto scaling")

This is an OpenPGP proof that connects my OpenPGP key to this Github account. For details check out https://keyoxide.org/guides/openpgp-proofs

[Verifying my OpenPGP key: openpgp4fpr:DB997306E3102F11C4E8F5527B26396447AB6DFD]

kexec

syscalls

Load new kernel + initrd from files:
- kexec_file_load
- Go syscall
Call reboot with LINUX_REBOOT_CMD_KEXEC:

Problem

While running Go 1.14 inside docker, you might hit error:

runtime: increase the mlock limit (ulimit -l)

Solution

Talos on Firecracker

Build Firecracker from source (it's fast and easy, builds in docker): https://github.com/firecracker-microvm/firecracker/blob/master/docs/getting-started.md#building-from-source
Adjust /dev/kvm permissions: https://github.com/firecracker-microvm/firecracker/blob/master/docs/getting-started.md#prerequisites
Build Talos, you will need build/vmlinux & build/initramfs.xz.
Prepare configs for Talos: osctl config generate fire https://172.16.0.2:6443. Make following changes to the config: add resolvers to the machine.network config: nameservers: ["8.8.8.8", "1.1.1.1"] (IP config will come from kernel args), update install location: install: disk: /dev/vda (default is sda).

Keybase proof

I hereby claim:

I am smira on github.
I am smira (https://keybase.io/smira) on keybase.
I have a public key ASCfXEW-IQLnzRSPqo6Srl9r12mKESkh0HGByExjMS9G9Ao

To claim this, I am signing this object:

This is DRAFT of release notes

aptly 1.1.0 release is following (a bit late) scheduled every 3 months release of aptly.

Custom Filesystem Publishing

aptly supported configuring number of S3 and Swift publishing endpoints for a long time, but local filesystem publishing was limited to default directory ~/.aptly/public and hardlinking files. There was number of requests to allow use of symlinks or file copy to support publishing to different filesystems and shared locations like NFS.

With PR #521 from @seeraven aptly supports configuration of custom filesystem endpoints. Each endpoint has its own filesystem root, it might support either hardlinks, symlinks or simple file copy to reference files from aptly internal package pool.

	---
	#######
	# Generated with: helm template cilium/cilium --version 1.9.1 --set kubeProxyReplacement=disabled --set ipam.mode=kubernetes --namespace kube-system > cilium.yaml
	# Patched with:
	# * nodeSelector:
	# kubernetes.io/arch: amd64
	# * disable-envoy-version-check: "true"
	########
	#######
	# Source: cilium/templates/cilium-agent-serviceaccount.yaml

	---
	# Source: crds/calico/kdd/crd.projectcalico.org_bgpconfigurations.yaml
	apiVersion: apiextensions.k8s.io/v1
	kind: CustomResourceDefinition
	metadata:
	name: bgpconfigurations.crd.projectcalico.org
	spec:
	group: crd.projectcalico.org
	names:
	kind: BGPConfiguration

	package linux

	import (
	"fmt"
	"syscall"
	"unsafe"
	)

	// Values for waitid() idtype parameter
	//