Skip to main content

Trying OKD4: home lab needs to grow


I've spent last week tinkering with OKD4, which is open source base for OpenShift. OpenShift in turn is Red Hat's distribution of Kubernetes. Such opensource/commercial differentiation is quite popular among Red Hat products. OKD/OpenShift relation is like AWX/Ansible Tower, Spacewalk/Satellite, WildFly/JBoss, oVirt/RHEV etc.

I already had previous version deployed - 3.11, then called Origin, not OKD. My cluster consists of two old ThinkPads and a virtual machine, and I was planning to redeploy OKD4 on them. But first some PoC on virtual machines.

So I started with minimal viable cluster – 3 schedulable master nodes. (There's a Code Ready Containers version, too – 1 node cluster, but it's non-upgradable). Requirements table looks scary – 4 CPU cores and 16GiB per master – but that's probably an overkil, right?

As it turned out, I won't be able re-use my legacy hardware to host new cluster. Oh boy, OKD4 is massive.

/dżogstaff/2020.07.25-okd-size.png

That's the cluster dashboard just after the installation. For all practical purposes it's an empty platform, I haven't deployed any of my stuff yet. Almost 5 CPU cores used and 10 gigs of memory. Huh.

My VMs setup is below minimal requirements, each has 10GiB of RAM and 3 CPU cores. I'm used to think that you can't skimp on memory, but you can assign fewer CPU cores – at worst everything would be slower. That won't fly with OKD. Components define CPU needs with requires: sections. If you don't deliver, you'll get admission errors and the pods will not run.

So my home lab would need to be expanded with 64GiB of RAM and some 16 threads CPU, just for OKD. Speaking of CPU…

I'm seriously taken-aback with CPU usage of this empty cluster. I don't know exactly what's using so much. There is Prometheus scraping metric, one CronJob and a handful of healthchecks, that's all. Everything should be event-driven and just be idle when not running any workload. Right now OKD wastes tremendous amount of power just to do nothing.

Enough complaining. I like how OKD is managed and configured.

OKD owns the master nodes, including operating system (Fedora CoreOS). Everything is managed from within the cluster, and configured like normal Kubernetes resources - via YAML. LDAP connectivity, custom logo, apiserver's TLS certificates… create a ConfigMap, update a field in resources definition and it just happens.

I much prefer eventual consistency, asynchronously achieved by k8s operators, to using openshift-ansible. The latter touches everything and tends to break when something isn't 100% right. Which is cumbersome when each run takes 40+ minutes.

With OKD you have clean bootstrapping (with ignition config served by bootstrap k8s node – how cool is that?) and you receive basic working cluster, which you customize using kubernetes YAMLs.

Documentation is also very nice and seem to cover every common (and some less common) case.

Indianie poszli w las


Aktualizacja Fedory do najnowszej stabilnej wymagała spojrzenia w oczy kwestii indiańskiej. Od lat jako serwera WWW używałem Cherokee, ale w końcu został usunięty z dystrybucji jako porzucony. Faktycznie, sporadyczne commity, bugi niepoprawione od lat… software przekroczył już termin przydatności.

Chwilę rozważałem, w którą stronę iść. Postanowiłem jednak uniknąć pułapki niszy i wybrać coś popularnego. Czyli dobry, sowiecki nginx.

Jedną z zalet Cherokee był klikalny (w formie strony web) konfigurator. Wadą był klikalny konfigurator, przez który plik konfiguracyjny miał format dla maszyn, a nie ludzi. Do migracji zaopatrzyłem się w przewodnik po dyrektywach Cherokee→nginx, ale zupełnie nie był potrzebny. Tekstowa konfiguracja nginx jest logiczna i przyjemna. Do tego jest apaczem naszych czasów, więc w necie są przykłady na praktycznie wszystko.

Przy okazji pozbyłem się też nghttpx. Nginx obsługuje HTTP/2 natywnie, a w konfiguracji łatwo mi było rozdzielić rzeczy wewnętrzne od tych dostępnych internetu. Win-win.

Aktualizacja dystrybucji poszła jak zwykle gładko, z drobnym wyjątkiem: PostgreSQL. Przy przejściu z wersji 11 na 12 przestają być obsługiwane tabele z oids. Miałem w swojej instacji kilka takich, jeszcze z czasów studiów (circa 20 lat temu). Po chwili deliberacji tabele wyrzuciłem – na co komu rezerwacje siłowni w DS 3 z początku wieku?

W Fedorze, gdy już mamy nową wersję PostgreSQL w systemie, do operacji na niezmigrowanej bazie trzeba użyć starych binariów. Czyli start za pomocą /usr/lib64/pgsql/postgresql-11/bin/postmaster -D /var/lib/pgsql/data, potem normalnie psql.

O temperaturze i dokładności


Za oknem ciepło i słonecznie, ale dzisiaj skupiłem się na temperaturze wewnątrz komputera. Wykresiki dot. dysku NVMe pokazywały takie dziwne, nieokrągłe końcówki:

# sensors nvme-*
nvme-pci-0100
Adapter: PCI adapter
Composite:    +36.9°C  (low  =  -0.1°C, high = +69.8°C)
                     (crit = +89.8°C)

Dokładnie to widać tu:

nvme-pci-0100
Composite:
  temp1_input: 36.850
  temp1_max: 69.850
  temp1_min: -0.150
  temp1_crit: 89.850
  temp1_alarm: 0.000

Co ciekawe, polecenie nvme smart-log /dev/nvme0 pokazuje „pełne” stopnie. Poprawienie wydruku lm_sensors jest trywialne, w konfiguracji wystarczy dopisać:

chip "nvme-pci-0100"
        # bump readings, all ends with *.85
        compute temp1   @+0.15, @-0.15

I od razu wartości wyglądają na bardziej ludzkie:

# sensors nvme-*
Composite:    +37.0°C  (low  =  +0.0°C, high = +70.0°C)
                       (crit = +90.0°C)

No dobrze. Ale dlaczego takie przesunięcie? Piętnaście setnych to nie jest np. ⅛, co od biedy możnaby podciągnąć pod zaokrąglenia bitowe.

Zacząłem od źródła, czyli specyfikacji Non-Volatile Memory Host Controller Interface Specification (NVMe). Stoi tam:

Composite Temperature: Contains a value corresponding to a temperature in degrees Kelvin that represents the current composite temperature of the controller and namespace(s).

Poza tym, że jest tu błąd – nie ma „stopni” Kelwina, są po prostu kelwiny – to zaczyna wyłaniać się logiczne rozwiązanie.

Jak wiadomo ze szkoły, początek skali, zero kelwinów to -273°C… nie! To -273,15°C. Dla wygody zazwyczaj pomijamy tę końcówkę. I stąd ta rożnica.

Szybkie spojrzenie w kod źródłowy wyjaśnia też różnice w prezentacji. nvme-cli operuje na liczbach całkowitych, odejmując od odczytanej ze sprzętu wartości 273, co daje temperaturę w stopniach Celsjusza.

Z kolei podsystem hwmon w Linuksie operuje na tysięcznych częściach stopnia, a do przeliczenia używane jest makro kelvin_to_millicelsius(). Oczywiście w tym przypadku końcówka piętnastu setnych jest stosowana. Niestety, dane wejściowe nie zapewniają wymaganej dokładności, i efekt jest nie do końca zadowalający. To taka ilustracja powiedzenia, że nadgorliwość gorsza od faszyzmu.

Bojkot Amazona


Amazon, firma najbogatszego czowieka świata, dostarcza ostatnio coraz więcej powodów do bojkotu. Napędza bezsensowny konsumpcjonizm, ale to nie jedyny grzech. W przejściowym okresie przed pełną robotyzacją wszystkiego zatrudnia ludzi (bądź zleca pracę ludziom). I traktuje ich kiepsko – żeby ratownik medyczny błądził po firmie 20 minut zanim trafił do poszkodowanej (która ostatecznie zmarła) – to skandaliczny, wręcza karalny poziom procedur BHP.

Nie jest to jednostkowy przypadek, raczej systematyczne podejście do zasobów^Wpracowników. Amazończycy w ramach protestu zwalniają się. Innym pozostaje bojkot.

Osobiście nie rozumiem sukcesu sklepu Amazona. Wyszukiwanie praktycznie nie działa, filtrów nie ma, pokazywana cena z dostawą potrafi drastycznie wzrosnąć po dodaniu do koszyka (albo nawet zalogowaniu się na konto!). Nic zachęcającego, a jednak są największym detalistą.

Bojkot Amazona ułatwia sama firma. Na stronie AWS IP address ranges wyszczególnione są wszystkie podsieci IP, które wystarczy zablokować na firewallu. Drobna trasformata pliku:

#!/usr/bin/python

import json

with open("ip-ranges.json", "r") as aws_ips:
    data = json.load(aws_ips)


for v4_net in data["prefixes"]:
    print(f"iptables --append AWS --source {v4_net['ip_prefix']} --match comment --comment {v4_net['region']} --jump koniec")


for v6_net in data["ipv6_prefixes"]:
    print(f"ip6tables --append AWS --source {v6_net['ipv6_prefix']} --match comment --comment {v6_net['region']} --jump koniec")

Wcześniej trzeba przygotować tablicę koniec, którą stosuje w celu poprawnego zamykania połączeń:

iptables --new koniec
iptables --append koniec --protocol tcp --jump REJECT --reject-with tcp-reset
iptables --append koniec --jump REJECT --reject-with icmp-port-unreachable

ip6tables --new koniec
ip6tables --append koniec --protocol tcp --jump REJECT --reject-with tcp-reset
ip6tables --append koniec --jump REJECT --reject-with icmp6-adm-prohibited

Teraz wystarczy to połączyć i dodać w tablicy FORWARD skok do AWS. I bum! Przestaje nam działać 1/3 internetu, w tym jakiś Netflix, Spotify, Adobe, Stripe i wiele innych. Prztykanie głównego gracz na rynku wiąże się z wyrzeczeniami.

Oszukany 😭


Lo and behold. Dałem się oszukać w internecie. Bycie kierownikiem zespołu IT w banku i picie wódki z Piotrem Koniecznym nie oznacza, że jestem odporny na na wszystki scamy.

Na OLX „zakupiłem” procesor, zapłaciłem, a kiedy upomniałem się o wysyłkę – konto sprzedającego już nie istniało. Email który mi podał również.

Patrząc wstecz, było kilka czerwonych flag, jednak i tak dałem się złapać. Na pewno moją czujność obniżyły: 100% sukcesów w dotychczasowych transakcjach na OLX i emocjonalne podejście „niezła okazja, trzeba brać”. Natomiast powinienem zwrócić uwagę na:

  • cena niższa o ok. 10% niż podobnych ogłoszeń; niby nic, zwłaszcza przy używanym CPU sprzed 7 lat, ale kieruje uwagę wprost na ogłoszenie oszusta

  • podane w opisie kontakt tylko przez OLX i brak telefonu; oszustowi ułatwia prowadzenie równocześnie wielu wałków, nam utrudnia weryfikację. Policja też wydaje się być bardziej obeznana z uzyskiwaniem danych klienta od telekomów, niż z serwisów internetowych

  • płatność przez PayPal i prośba o zaznaczenie opcji "przesyłam pieniądze znajomemu" aby uniknąć prowizji. Co jeszcze powoduje ta opcja? Brak możliwości założenia sporu via PayPal, bo to przecież nie sprzedaż tylko kasa dla ziomka. Podobnie, Policja rozumie płatność kartą i przelewy z konta, ma gotowe formularze na zwolnienie z tajemnicy bankowej, ale użycie pośredników płatniczych zbija z pantałyku

Oszustwo zgłosilem na komisariacie, potwierdzenie wysłałem z opisem sytuacji do OLX (mają więcej danych i mogą zablokować telefon/IP/tokeny/cokolwiek oszusta). Zgłoszenie chargeback w banku wymagało najwięcej zachodu, bo w BNP Paribas w dwóch oddziałach nie przyznają się do znajomości tego trybu. Dostałem kartkę A4 na której opisałem sytuację i zażądałem chargeback, teraz czekam.

Miejcie oczy otwarte i niech się komuś nie wydaje, że skoro klika w internety od 25 lat, to nie sposób go oszukać.

Projekt Gom Dżabbar


Jakby ktoś nie wiedział (impossible!) to w tym roku będzie miał premierę film Diuna, reżyserem jest Denis Villeneuve (pan zrobił Arrival, Blade Runner 2049, Sicario itp).

Oryginalny sześcioksiąg Diuny przeczytałem dwa razy; najpierw w okolicach 7. klasy podstawówki, natomiast drugie podejście piętnaście lat temu. Wychowalem sie na tym uniwersum: Dune 2 (The Building of a Dynasty… wciąż słyszę The planet Arrakis, known as Dune z intra), książkach i filmie Lyncha. Może by sobie odświeżyć?

(nota bene, przed Lynchem Diunę próbował ekranizować Alejandro Jodorowsky. Nie udało się, ale ekipa wzięła przygotowane pomysły i stylistykę i poszła nakręcić Obcego w 1979).

Wracając do książek. Oryginalną serię dokończył syn Franka Herberta z kolegą, dopisując Hunters of Dune oraz Sandworms of Dune. Tych jeszcze nie czytałem, więc również trafiły do kolejki. Ale poza sequelami powstało też kilka prequeli. Czyż więc wspaniałym pomysłem nie byłoby przeczytanie wszystkiego w kolejności wydarzeń w uniwersum? Tak jak zrobiłem np. z cyklem Fundacji czy Enderem? W internetach można znaleźć pomocną listę z chronologią. Tak zrodził się mój prywatny Projekt Gom Dżabbar.

Na razie przeczytałem 3,5 książki oraz 3 opowiadania. Recenzje (o ile miałem siłę) znajdują się na Lubimy Czytać. Ogólnie – dramat, głównie fabularnie, warsztatowo też słabo. Z niecierpliwością wyczekuję, aż dobrnę do oryginałów Herberta. Na razie kryptonim projektu oddaje w 100% odczucia towarzyszące czytaniu książek autorstwa Briana Herberta i Kevina J. Andersona.

Do premieru filmu zostało 10 miesięcy i 4 dni.

W 2019 nastąpił koniec


Nastąpił koniec sporej liczby seriali. Nie przypominam sobie roku z aż taką kumulacją finałów. A pożegnaliśmy się m. in. z:

  • The Affair – ciekawy eksperyment z pokazywaniem tych samych wydarzeń z różnych perspektyw dał radę na 5 sezonów

  • The Big Bang Theory

  • Designated Survivor – pomysł OK, dalej niestety generic political procedural

  • Elementary

  • Man in the High Castle

  • Mr Robot

  • Game of Thrones – meh

  • Orange is the New Black – everybody loses

  • Preacher

  • Silicon Valley – końcówka bardziej smutna niż śmieszna

  • Suits – tu był nawet jeden odcinek, w którym wszyscy nazwzajem na siebie NIE krzyczeli

Zakończył się też wielki, 11-letni rozdział z Avengers. W sumie dobrze, bo trudno odcinki marvelowego film-serialu odróżnić od siebie, a i Tony Stark już nie taki żywy jak na początku.

Time needed to dist-upgrade Fedora


Every couple of months I upgrade my main home computer to the latest Fedora. As this process is not instantaneous, this means some time without internet, wifi, smart home controls etc. This time I decided to measure how long it takes exactly.

Hardware is mid-range home server: Core i5 CPU, 16GiB of RAM, storage is 2x HDD in btrfs raid1, over LUKS, bcached on NVMe drive.

I've used dnf system-upgrade to download packages, then I rebooted and started counting time.

Wallclock

Time since start

Time Δ

Phase

10:50

System booted. This will take a while displayed.

11:06

16m

+16m

Upgrade started. 5294 steps to finish.

11:23

33m

+17m

First thousand steps done.

11:41

51m

+18m

Second thousand steps done.

11:59

1h09m

+18m

Third thousand steps done.

12:11

1h21m

+12m

Fourth thousand steps done.

12:26

1h36m

+15m

Fifth thousand steps done.

12:29

1h39m

+3m

5294 steps done. Running scriptlets begin.

12:31

1h41m

+2m

Scriptlets done. Verification begin.

12:36

1h46m

+5m

Verification done. No messages for few minutes.

12:42

1h52m

+6m

Upgrade done, rebooting.

Basically, full distribution upgrade from Fedora 30 to 31 takes about 2 hours. This is with bcache mode set to writeback. With safer writethrough, upgrade takes couple more hours, but I don't have specific number.

It's election time in Fedora-land


It's time to influence the course of our beloved project – Fedora Linux. Before 5th of December 2019 we have a chance to select people for:

  • Fedora Engineering Steering Committee (FESCo)

  • Fedora Council

  • Mindshare (community groomers)

So, go read candidate interviews at Community Blog, think about them and cast the vote at https://elections.fedoraproject.org/

Over few iterations, I've noticed that my choice is little influenced by the interviews; I put more weight to what I remember about individuals from the mailing list traffic. I mean mainly fedora-devel, although I follow -infrastructure and -server, too. That in turns means, I won't be voting for Haralds, Kevins and Johns juniors haunting those lists, no matter how awesome their interview may be. Abrasive people should be extinguished, not promoted.

There's a minority of people I know personally. Often I do respect their skills, so Zbigniew got my vote.

But over the last few elections, interviews gave me hints who not to vote for. Candidate putting too much weight on modularity raises a red flag, and quickly falls into “do not vote” bucket.

There's a lot to unpack why modularity was like a sand thrown into Fedora's gears. Mailing list threads reached Debian's proportions, overshadowing discussions we had when we were considering systemd. Hard to read them all. Here's a shortcut – go read excellent Fedora's modularity mess at LWN.net. This summary is prime example of LWN's high writing standard. I urge you to pay for subscription to LWN – it's really worth it.

https://badges.fedoraproject.org/pngs/ivoted-f31.png

OpenShift's haproxy as IPv6 ingress


Kubernetes networking always struck me as some PoC mistakenly put into production. Among questionable design choices, Internet Protocol version 6 is hardly supported. But when using OpenShift's default router – haproxy – you can easily handle IPv6 at your ingress.

With recent version is even easier than before. I've started following Customizing HAProxy Router Guide, but after extracting config template I've discovered that all the ground work has been prepared already, for v3.7 and up.

OpenShift's HAProxy container reacts to ROUTER_IP_V4_V6_MODE environment variable. When set to v4v6, the router will gladly accept connections in both IP versions, legacy and v6.

You should oc -n default edit dc/router and in the long block of envvars add this:

- name: ROUTER_IP_V4_V6_MODE
  value: "v4v6"

While editing this, you may want to add ROUTER_ENABLE_HTTP2=true, too.

Gdzie się podziało to pół roku…


Huh. Ostatnie sześć miesięcy zniknęło mi nie wiem gdzie.

Po części to wina zmian zawodowych. Powiedziałem YOLO, wyszedłem poza strefę komfortu, i od lipca dołożyłem sobie obowiązków. Teraz jestem Head of DevOps w naszym kawałku NRD, czyli w Group Data Management Office. Dalej robię jakieś automatyzacje przy Big Data, chociaż bardziej to mój zespół robi. I pamiętajcie dzieci, DevOps to podejście, nie stanowisko.

Strava uprzejmie wypomniała mi, jak się zapuściłem. Dostałem świetny filmik z żałosnymi wynikami. A przeniesienie biura do Gdyni bardzo źle odbiło się na wspinaczce w Elewatorze. Wstyd.

Czas zjadła mi też nauka i certyfikacja. Certified Kubernetes Administrator, Certified Specialist in OpenShift Administration, SAFe Advanced Scrum Master (no joke!).

Pilnowanie fachowca urządzającego mieszkanie, oraz związane z tym wcześniejsze przygotowania też zabrały swoje.

A na koniec roku mały sukces. W końcu, po raz pierwszy udało mi się wylądować w F29 Retaliator. Wcześniej chyba się po prostu nie przykładałem.

F29 na lotnisku

Tak, po 25 latach od kiedy pierwszy w to zagrałem. Kolejny cel: wylądowanie w T.F.X.

Oh fuck.<br><br><a rel="nofollow" target="_blank" href="https://www.businessi...


Shared with: Public
- 2018-10-28T20:52:49+0000
Let's just hope for RH employees sake that they wont be forced to run notes. ..

Szaleństwem jest robić wciąż to samo i oczekiwać różnych rezultatów (BO2019 Gdańsk)


A ja robię. Po raz kolejny zgłosiłem do Budżetu Obywatelskiego w Gdańsku mój projekt – Ścieżkę rolkowo-biegowo-pieszą wokół zbiornika retencyjnego Jabłoniowa. Dostał numer 11 wśród projektów dzielnicowych dla Jasienia. I tym razem projekt wygra :)

Potrzebne są tylko głosy, które można oddawać od 10 do 24 września br. Jeśli mieszkacie w Gdańsku, to wejdźcie proszę na https://gdansk.zetwibo.pl/voting/info i oddajcie 5 głosów na jedenastkę. A jeśli nie mieszkacie, to zachęćcie znajomych stąd.

Głosować można na projekty w innych dzielnicach niż swoja. Nie trzeba mieć meldunku – wystarczy oświadczenie o byciu mieszkańcem Gdańska.

Dzięki!

Hey! Wanna abolish summer/winter time changes in EU? Or maybe you strongly wa...


- 2018-07-08T12:48:30+0000 - Updated: 2018-07-08T12:48:30+0000
Hey! Wanna abolish summer/winter time changes in EU? Or maybe you strongly want to maintain status quo?
Either way, use the democratic mechanism today and fill the consultation survey:
https://ec.europa.eu/eusurvey/runner/2018-summertime-arrangements?surveylanguage=EN

Public consultation on summertime arrangements

Shared with: Public
+1'd by: Martin Novy

Quick note: openHAB/ESPEasy/MQTT and easy fading


Connecting ESPEasy's GPIO outputs to switch elements in openHAB, using MQTT is quite simple:

Switch sD1MINI02MOS "Countertop light [%s]" <whites> {
  mqtt=">[motherqtt:/d1mini02/gpio/5:command:ON:1],>[motherqtt:/d1mini02/gpio/5:command:OFF:0]"
}

MQTT binding field explanations:

motherqtt

broker's name (defined in openhab.cfg)

/d1mini02/

ESPEasy %sysname%. Basically, a module name

gpio/5

GPIO number to control

command

openHAB will send a command

ON:1

what to send (“1”) when state changes to on

OFF:0

ditto when switching off

Switching ON/OFF gets boring quite fast. Luckily, ESPEasy exposes PWM (pulse width modulation) control of GPIO outputs. This gives possibility to vary brightness of light sources controlled by GPIOs. Let's modify the item definition to have light dimmed when set to OFF (not turned fully off):

Switch sD1MINI02MOS "Countertop light [%s]" <whites> {
  mqtt=">[motherqtt:/d1mini02/pwm/5:command:ON:1023],>[motherqtt:/d1mini02/pwm/5:command:OFF:128]"
}

Compared to direct gpio control: gpio became pwm, and 1/0 for ON/OFF became 1023 (fully filled impulse) and 128 (one eighth of full brightness).

Two things to remember: while ESPEasy's range of PWM is 0÷1023, openHAB's dimmer type only works support 0÷100 (like in percents). You cannot directly drive /pwm/ with openHAB's values, you need transforms. Second, when you start using /pwm/, standard /gpio/ stops working. You need to set /pwm/ to 0 to have /gpio/ control work again.

PWM fading is quite nice, but with binary ON/OFF state not very useful. But! Look closely at ESPEasy GPIO command set. There's a PWM command version with <duration>. This is useful for having lights turn on and off softly, instead of abruptly.

This requires slightly more complicated definition. We cannot use /pwm/ directly, instead control the /cmd endpoint:

Switch sD1MINI02MOS "Countertop light [%s]" <whites> {
  mqtt=">[motherqtt:/d1mini02/cmd:command:ON:PWM,5,1023,200],>[motherqtt:/d1mini02/cmd:command:OFF:PWM,5,0,600]"
}

Above definition will give pleasant, 200ms long fade in when turned ON, and 600ms long fade out when turned OFF. Compared to first definition, following has changed:

  • /gpio/5 (or /pwm/5) became /cmd

  • 1 (or 1023) for ON became PWM,5,1023,200 – control PWM, on GPIO number 5, set fill to 1023 during 200ms

  • symetrically, 0 (or 128) for OFF became PWM,5,0,600 – fade GPIO 5 to 0 during 600 ms

You provide final PWM value, fade starts from current value. Happy fading! :)