Info locales

🌞 08:21 | 13:06 | 17:50

⛅ +7jours ⇒ +7min +10min = +16 min

If you are a multi billion dollar company and are concerned about log4j, why not just email OSS authors you never paid anything and demand a response for free within 24 hours with lots of info? (company name redacted for *my* peace of mind) — twitter

Le Hollandais Volants -- Liens

Donc les boîtes qui utilisent log4j contactent les auteurs pour EXIGER leur aide sous 24 heures dans un mail à la limite de l’injonction.

Et évidemment, toujours aucun chèques à la clé.

D’où l’intérêt de mettre des disclaimers dans toutes les licences de tous vos projets, afin de pouvoir les envoyer chier.


— (permalink)

Really love NFTs described as content-free DRM. Just a wonderful turn of phrase. - Twitter

Le Hollandais Volants -- Liens

Joli : les NFT sont juste des DRM sans contenu.

Pour ma part j’attends de voir les premières actions en justice pour « violation de NFT ». Non seulement les NFT n’ont aucune valeur légale, mais ensuite la NFT n’est qu’une URL vers un objet. C’est cet URL qu’on achète, pas l’objet. L’objet, dans le cas d’un fichier numérique, n’importe qui peut aller le prendre gratuitement sans restrictions.

Donc quand les premiers se feront débouter des tribunaux, je pense que ça va remuer un peu le milieu.

Un peu comme le bitcoin en ce moment : il est cher parce que le produire coûte cher. Sauf que de plus en plus de pays interdisent leur production à cause de l’énergie que ça pompe. Du coup le cours dégringole (30% en un jour, sur toutes les cryptos, donc pas loin de 600 G$ de pertes au total).


— (permalink)

Pourquoi je ne m’abonnerai pas au PC Game Pass – Matronix.fr

Le Hollandais Volants -- Liens

Un avis sur le « Netflix des jeux vidéos » par Microsoft.

Yup, visiblement c’est aussi pourri que ça semble l’être :
– C’est de la location
– C’est un service, donc dans 5 ans, ça va fermer
– À un moment, on ne paiera que pour pouvoir finir un jeu qu’on aura installé y a des lustres
– Le logiciel en lui-même semble complètement verrouillé, opaque, lié à la machine et tourne constamment en tâche de fond invisible.

Ce qui est navrant, c’est que tous les jeunes et ceux qui débarquent dans le monde des JV n’auront jamais connu le monde d’avant, où :
– le jeu t’appartenait
– c’était juste un dossier de fichier dans /programme files/, qu’on pouvait copier d’un ordinateur à un autre sans perdre ni le jeu ni la progression
– que les consoles démarraient en 4 secondes
– que les jeux fonctionnent toujours 30 ans après.

Y avait peut-être pas de jeu en réseau avec les copains ni de mises à jours constantes (qui peuvent parfois apporter de bonnes choses, pas seulement des DLC payantes), mais globalement, je trouve que dans le principe de fonctionnement, c’était clairement mieux avant.

Et ceci est valable sur pratiquement tout : des fringues aux lave-linge en passant par les ordis, les voitures ou les téléphones.


— (permalink)

Pickles de chou rouge - recette végétalienne cuisine-libre.org

Le Hollandais Volants -- Liens

Ça doit marcher aussi avec du chou blanc. C’est bien parce que j’ai ça dans mon frigo :D


— (permalink)

Agriculture : Les chasseurs doivent indemniser les paysans pour les dégâts des sangliers, des cerfs et des chevreuils

Le Hollandais Volants -- Liens

Pour comprendre le titre :

les chasseurs ont longtemps pratiqué « des lâchers d’animaux d’élevage » et du « nourrissage tout au long de l’année dans certaines régions » des sangliers

… résultant aujourd’hui en une prolifération (qui n’a, a priori, rien de naturel) des sangliers.

En gros, on est à deux doigts de reproduire l’effet Cobra : https://fr.wikipedia.org/wiki/Effet_cobra


— (permalink)

The Story of Webb | Flickr

Le Hollandais Volants -- Liens

Quelques photos (par la Nasa, donc sous CC) à propos du JWST.

En particulier, notez la taille des panneaux hexagonaux. Et il y en a 18, tous mobiles et recouverts d’or sur le télescope.


— (permalink)

Mon autopsie de - M'enfin, Norauto - plaques d'immatriculations, m'enfin c'est écrit en tout petit nan ? - Arfy'z tranche du Net

Le Hollandais Volants -- Liens

Petit rappel de toujours toujours regarder les ch'tites lignes.

Ici, le site de Norauto indique « Oui, nous montons vos plaques ! » en plein milieu d’une page sur les plaques minéralogiques mentionnant la technique applicable aux plaques, le législation autour et un cas de figure où cette dernière s’applique. Soit.

En bas de la page en petit : « ah les plaques coûtent 15 € ».
Au moment de mettre les plaques dans le panier « chaque plaque sera installé pour 6 € ».

C’est comme si vous étiez au supermarché et qu’il n’y avait aucun prix nul part dans les rayons. Les prix sont affichés à l’accueil, à côté du règlement intérieur. Et une autre partie du prix n’est visible qu’une fois les produits posés sur le tapis à la caisse.

Impossible de dire que c’est de la fraude : les prix sont indiqués.

Mais ils sont indiqués en petit en bas et seulement une fois la pièce mise dans le panier. Question honnêteté, on a vu mieux. Ça reste tout de même limite :/

Une façon plus honnête aurait été « Nauroto s’occupe de monter vos plaques ! (coût pour le montage : 6€ par plaque + 15 € pour la production des plaques) ».

Là c’est clair.


— (permalink)

Résoudre rapidement Sutom / Wordle avec les Regex

Le Hollandais Volant

S’il y a bien un truc puissant en programmation, ce sont les expressions régulières, ou « regular expressions », Regex pour les intimes.

J’en avais déjà fait une petite introduction que je vous conseille de lire.

Aujourd’hui, voyons un usage à ces choses-là.
Depuis le début de l’année, le jeu Wordle (en anglais) et Sutom (en français) sont devenus viraux. Leur principe est celui du jeu télévisé « Motus ».

Sutom ?

Le principe du jeu est le suivant.

Le but est de deviner un mot.
La première lettre nous est toujours fournie. On connaît également la longueur du mot.
On a droit à 6 essais pour deviner le mot :

Début du jeu Sutom.

À chaque fois qu’on essaye un mot, on a des indices :

  • les lettres bien placées sont en rouge
  • les lettres présentes mais à leur mauvaise place sont en jaune
  • les autres lettres ne figurent pas dans le mot

Dans cet exemple, celui du 21 janvier 2022, si j’essaye le mot « Diamètre », j’obtiens :

Premier essai dans le jeu Sutom
Je sais désormais que :
– Le mot fait 8 lettres (incluant le D au début)
– D et I sont bien placés
– E et R sont mal placés (mais présents).
– A, T et M sont exclus (grisés sur le clavier)

D’essai en essai, on accumule les indices et la solution nous apparaît plus ou moins facilement.
Motus était un jeu télévisé, mais sur ces petits jeux en ligne, il n’y a rien à gagner. Il y a un seul mot par jour.

Si vous trouvez, vous recevez un code rigolo à partager sur les réseaux sociaux qui représentent les couleurs des cases du tableau. Comme personne n’essaie les mêmes mots, il est généralement unique à vous pour ce jour-là. C’est amusant :).

Utiliser les Regex pour jouer à Sutom

Sutom demande deux choses qu’un ordinateur a :

  • de la mémoire (du vocabulaire)
  • de la logique

Il suffit d’une liste de mots connus suffisamment complète ainsi que quelques règles de base pour permettre à un ordinateur de jouer à Sutom.

On pourrait créer un solveur où l’on prend la grille en photo et il nous donne la réponse. Ce serait un exercice intéressant à plusieurs niveaux, mais ce n’est pas ce que je vais faire ici.

Je me contenterai ici d’utiliser une liste de mots et les Regex mentionnées plus haut pour trouver la solution grâce aux indices du jeu.

J’ai fait cette page : Rechercher un mot. Elle contient 340 000 mots et un champ de recherche.
L’intérêt est que la recherche fonctionne par Regex !

Le but de cet article est de créer une Regex puissante qui va très vite filtrer les mots et nous sortir le bon, généralement après 1 ou 2 essais seulement.

Pour l’exemple du 21 janvier 2022, le mot commence par D et fait 8 lettres.

On a donc cette Regex :

D.{7}$

Vous pouvez copier ça dans le champ de recherche de la page de recherche de mots.

La Regex signifie « un “D”, suivi de 7 lettres » (donc bien 8 au total). Le « $ » à la fin signifie que c’est la fin du mot après ça. Si on ne le met pas, il va nous sortir les mots de 8 lettres ou plus. Or nous ne voulons que les mots de 8 lettres.

À ce stade, ma page me sort 37 042 mots. On peut en utiliser un de la liste ou en poser un qu’on connaitrait déjà.

Dans mon cas, j’essaye « DIAMETRE ». J’obtiens les informations suivantes :
– D et I sont bien placés
– E et R sont mal placés (mais présents).
– A, T et M sont exclus (grisés sur le clavier)

Il faut donc un mot qui débute par DI, qui ne contienne pas A, T, M, mais qui contienne E, R. et dont la longueur totale fasse toujours 7 lettres.

Le début de la Regex est simple : le mot commence par DI.

La Regex débute donc tout naturellement par :

di

Ensuite, il faut dire que parmi tous les mots commençant par « DI », on veut ceux comportant E et R.

Il s’agit d’utiliser une assertion positive avant (positive lookahead), pour dire « je veux un E et un R après le DI ». Il existe aussi des assertions arrière, pour vérifier ce qui se trouve avant, mais ça ne nous intéresse pas ici.
L’assertion positive est inclue dans notre Regex sous la forme (?=REGEX). Elle contient elle-même une seconde Regex.

Notre Regex interne est la forme « une lettre suivie de E ou R ». Notre assertion en entier donne donc :

(?=.*([er]))

Maintenant un peu de technique interne aux Regex.

Normalement quand on cherche « ABC », il cherche un « A » suivi d’un « B » suivi d’un « C ». La chaîne « A1B1C1 » ne marche pas, car les trois lettres ne se suivent pas.

Effectivement, après avoir matché le « A », le parseur se positionne après le A. Il regarde donc s’il y a un « B » juste après, et ainsi de suite, à chaque fois en venant avancer dans la chaîne.

Les assertions servent à matcher des trucs, mais ne font pas avancer dans notre Regex globale. Ainsi, quand on matche notre « AB », on avance de deux lettres dans le mot.

Quand on utilise l’assertion, on va parcourir le reste du mot et renvoyer un TRUE si un E et un R sont trouvés. Si c’est le cas, l’assertion est valide (elle retourne TRUE), mais l’on vient se remettre juste après le DI.

À ce stade, la Regex entière a filtrée les mots débutant par DI et contenant un E et un R.

Il reste à filtrer les mots pour éliminer ceux avec A, T, M.

Pour ça, on veut exclure des mots. On va utiliser une assertion négative avant (negative lookahead) pour dire « je ne veux pas de A, T, M après le “DI” ».

L’assertion négative se construit avec (?!REGEX). Elle est négative, car on retourne FALSE si la REGEX à l’intérieur de l’assertion retourne TRUE.

Dans notre cas, on veut refuser A, T et M. Ce qui donne :

(?!.*[atm])

Maintenant, il nous reste à dire qu’il nous faut 6 lettres.
Inutile de lister les lettres : on peut utiliser le simple « . ». Les assertions ont déjà filtré les lettres qui nous intéressent ou non. On a donc :

.{6}

Mis bout à bout, on a :

di(?=.*([er]))(?!.*([atm])).{6}$

Le filtre me trouve 79 mots (sur 340 000). Pas mal, mais pas suffisant pour gagner au jeu. Il faut en essayer un au hasard. J’essaye donc le mot « DISPOSER ».

Qui donne :

Essai du mot « disposer » dans Sutom.
J’apprends donc que le mot est de forme « DI...SER ». J’apprends également qu’on peut éliminer les lettres O et P, en plus de A, T, M.

On peut donc modifier notre assertion négative avant pour filtrer ces deux lettres supplémentaires. De plus, le E et le R sont bien placés : on sait où ils sont. Notre assertion positive avant devient inutile.

La Regex globale devient :

di(?!.*([atopm])).{3}ser$

Qui signifie :

  • « di »
  • puis « on ne veut pas de A, T, O, P, M »
  • puis on revient après le « di », on met trois lettres n’importe lesquelles
  • puis on met « ser »
  • et c’est la fin du mot.

Et là, bim, mon outil de recherche ne me sort plus qu’un seul mot.

Il se trouve que c’est le bon :

SUTOM #14 3/6

🟥🟥🟦🟦🟡🟦🟡🟦
🟥🟥🟦🟦🟦🟥🟥🟥
🟥🟥🟥🟥🟥🟥🟥🟥

Bingo !
Ou plutôt « Motus » !
(ou Sutom)

Bien-sûr cela fonctionne, car tous les mots dans le dictionnaire utilisé par le jeu sont contenus dans le dictionnaire de ma page.

Ma page n’utilise pas le même dictionnaire. C’est volontaire, car je veux un dictionnaire plus large. Mais il arrive bien à filtrer des choses.

Notez que ma page permet de filtrer les accents et les tirets aussi. Sutom ne les affiche pas (ou plutôt il compte le É ou le È comme un E).

Enfin, j’ai aussi un outil de visualisation de Regex. Il est repris d’un code déjà existant (pas de moi) mais ça permet de visualiser ce que signifient les expressions assez compliquées de Regex.

Jean-Michel Blanquer à Ibiza parodié par des militants devant son ministère | Le HuffPost

Le Hollandais Volants -- Liens
Un groupe de manifestants, avec certains en maillot de bain et portant des masques à l’effigie du ministre de l’Éducation, ont dansé dans la soirée de ce mercredi 19 janvier devant le ministère où une pancarte “Réunion protocole sanitaire en cours, ne pas déranger M. le ministre”, avait été accrochée.

J’adore la créativité de la France quand il en vient à manifester :-D


— (permalink)

brusicor⁰² sur Twitter : "Je pense que je peux m’inscrire à des compétitions de placement de dominos. Indicateur universel de Van Urk en haut, indicateur universel de Yamada en bas. Échelle de pH de 2,5 (gauche) à 12 (droite) https://t.co/YFNi8mnawf" / Twitter

Le Hollandais Volants -- Liens

Une photo magnifique avec un indicateur de pH : un composé chimique qui change de couleur en fonction du pH.

Le fonctionnement de ces composés est assez simple : un indicateur de pH simple possède deux formes chimiques, une jaune et une bleu. Le changement d’une forme à l’autre se fait par la réaction avec l’ion hydrogène. Or la quantité d’ion hydrogène c’est ce qui détermine l’acidité : beaucoup = acide ; peu = basique.

Si on verse l’indicateur dans un milieu acide, l’indicateur va réagir avec l’acide et devenir jaune.
Si on verse l’indicateur dans un milieu basique, il va rester bleu.

Entre ces deux extrème, il peut y avoir un peu d’ion H+, moyennement, beaucoup… etc. À chaque fois, il y a donc autant d’indicateur jaune, et d’autant moins d’indicateur bleu.

Résultat : on a donc des proportions variable de bleu et de jaune (donc des verts, tirant plus ou moins soit sur le jaune, soit sur le bleu) en fonction de l’acidité.

Ici c’est ce qu’il a fait.

Sauf qu’il utilise un indicateur qui n’a pas deux états possible, mais beaucoup plus, à chaque fois ils sont tous présents dans toutes les solutions. Juste, en quantités variables.

Perso, un jour, j’avais réalisé ça avec l’indicateur de pH se trouvant naturellement dans le chou rouge : https://lehollandaisvolant.net/?mode=links&id=20181219192809

Si vous n’avez pas de chou rouge, essayez avec du thé noir. Le thé noir bien infusé est brun foncé. Ajoutez un acide (jus de citron, vinaigre…), ça devient brun claire ! La différence est moins spectaculaire que le chou, mais parfaitement remarquable.

Les indicateurs d’acidité sont réellement utilisés en chimie et permettent de voir le pH d’une solution.

Il existe aussi d’autres types d’indicateurs, qui détectent autre chose que l’acidité. Par exemple, l’indicateur se trouvant dans les éthylotests (les cristaux jaunes là) réagissent et deviennent vert en présence d’éthanol. Idem dans les test Covid ou même les tests de grossesse : c’est un indicateur qu’il y a dessus, or les virus, tout comme les hormones, restent des molécules et donc des réactifs.

Je ferais un article sur ça !


— (permalink)

How to Import an Amazon EKS Cluster Into Red Hat Advanced Cluster Management

OpenShift blog

Prerequisites

  1. AWS account
  2. Red Hat account
  3. eksctl installed on your local machine
  4. kubectl installed on your local machine
  5. oc CLI installed on your local machine
  6. OpenShift cluster as Hub cluster

Install ACM on OpenShift Hub cluster

Login to the OpenShift Web Console as a Cluster administrator.

Install Red Hat Advanced Cluster Management (ACM) from the OperatorHub within OpenShift Web Console as shown here:

Note: ACM Operator gets installed in the open-cluster-management namespace/project

Download Pull Secret

Login to Red Hat Hybrid Cloud Console with your credentials.

Navigate to Downloads and scroll down to the Tokens section. Select Download to get a copy of your pull secret on your local machine.

Upload Pull Secret to ACM

Login to your OpenShift cluster using oc CLI.

Run the following command to switch to open-cluster-management namespace/project:

$ oc project open-cluster-management

Run the following command to upload the pull secret to open-cluster-management namespace/project:

$ oc create secret generic eks-secret \  --from-file=.dockerconfigjson=pull-secret.txt \
--type=kubernetes.io/dockerconfigjson

eks-secret is the name of the secrets object, and pull-secret.txt is the pull secret downloaded in the previous step.

Install MultiClusterHub

After the ACM Operator gets installed successfully, navigate to “Installed Operators” and select “Advanced Cluster Management for Kubernetes” as shown:

Click on “Create instance” for MultiClusterHub.

Expand “Advanced Configuration”. Scroll down to “Image Pull Secret” and search for the secret uploaded in the previous step (for example, eks-secret). Select this secret and hit “Create”.

Create an EKS cluster

Create a YAMIL file eks-cluster-1.21.yaml with the following information. Save it to your local machine.

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: eks-cluster # EKS Cluster name
region: us-east-2 # Region Code to place EKS Cluster
version: "1.21"
managedNodeGroups:
- name: primary # Name of node group in EKS Cluster
instanceType: t3.small # Instance type for node group
desiredCapacity: 3 # Number of worker nodes- default is 2

Change the config parameter values according to your desired setting. There are many more configuration parameters, which you can find if you type eksctl create cluster –help.

Run the following command, which was used to create an EKS cluster.

$ eksctl create cluster --config-file eks-cluster-1.21.yaml

The above command creates an EKS cluster with worker nodes (EC2 instance type t3.small) in the us-east-2 region using Kubernetes version 1.21

Import EKS cluster

Switch to the “Advanced Cluster Management” view from the OpenShift Web Console:

Select “Clusters” under the Infrastructure menu and select “Import cluster”:

Provide a name for the EKS cluster that will be imported and choose “Run import commands manually” option from the drop down for Import mode:

Select “Save import and generate code”.

Select “Copy command” and run the command from the command line against the EKS cluster.

Your EKS cluster will successfully get imported into ACM.

Ça veut dire quoi, mourir de vieillesse? | Slate.fr

Le Hollandais Volants -- Liens

Une excellente question, car, comme l’article commence : « Médicalement, on ne meurt pas de vieillesse ».


— (permalink)

Le contrôle parental anti-porno va-t-il interdire la vente de PC sans système d'exploitation en France ? - Numerama

Le Hollandais Volants -- Liens

Si c’est juste un problème d’OS, ils peuvent toujours vendre un PC avec une distro Linux dessus.

Ben quoi, c’est pas trolldi ?

D’un autre côté, un PC sans OS n’a pas de quoi bloquer les sites porno, on est d’accord, mais ça n’a pas non plus de quoi les consulter ! Problème réglé :-D.

Toujours pas trolldi ?

Parce que si le problème c’est d’avoir des SI sans contrôle parental, faudra en installer sur les frigos, montres connectés, zapette de télé, balladeur MP3, voiture, GPS…

Quel jour on est ? Trolldi ? Non ?

Ho bon ça va hein… ça va encore être une loi qui va favoriser indirectement Microsoft ! Même s’il existe une loi qui interdit la vente liée d’un PC et d’un OS. Mais on n’est pas à ça près en puritanistan.

Ouais on est jeudi !


— (permalink)

Appli anti-Covid : la police allemande prise la main dans le sac à données personnelles

Liens SebSauvage
« La police de Mayence, en Allemagne, vient de reconnaître avoir eu accès illégalement aux données personnelles collectées par Luca-App, une application similaire à TousAntiCovid. »
Oh ben ça alors. Une application qui collecte des données "pour le bien de tous" et ensuite détournée de son usage initial.
(Permalink)

Spring

Liens SebSauvage
Une ballade dans les sous-bois (en WebGL)
(Permalink)

LastPass appears to be holding users' passwords hostage alongside more expensive pricing plans | AlternativeTo

Liens SebSauvage
LastPass est un gestionnaire de mots de passe en ligne payant.
Il semblerait qu'à la veille de changer leurs tarifs (les augmenter bien sûr) comme par hasard les options d'export des données utilisateur tombent en panne sur *toutes* les plaformes (application mobile, extension navigateur, etc.).
Du coup je présume que soit vous payez soit vous n'avez plus accès à vos mots de passe ?

N'utilisez pas ce service. Utiliser KeepassXC ou BitWarden.
(Permalink)

Velvetyne Type Foundry - Libre fonts

Liens SebSauvage
Une fonderie qui distribue des polices de caractères originales, mais surtout Libres: Non seulement vous pouvez librement les réutiliser dans vos créations (même de manière commerciale), mais vous avez le droit de les modifier !
Si vous aimez les polices originales de ce genre, jetez aussi un coup d'oeil sous Ubuntu/Mint dans les paquets fonts-larabie-* (installées dans /usr/share/fonts/truetype/larabie/)
(Permalink)

Un sénateur veut rémunérer auteurs et éditeurs en taxant chaque revente de livre d’occasion

Liens SebSauvage
On a le droit de dire qu'il y a des coups de pelle qui se perdent ???
(via https://lehollandaisvolant.net/?id=20220119131302)
(Permalink)

What's New Since CSS3 in 2015? | CSS-Tricks - CSS-Tricks

Le Hollandais Volants -- Liens

Un petit récapitulatif des nouveaux CSS depuis CSS3 : filtres, media-queries, dark/light, path, grid…


— (permalink)

Bonsplans.tech : toutes les bonnes affaires du moment

Le Hollandais Volants -- Liens

Tiens, je ne savais pas que Next Inpact avait son site de bon plans (façon Dealabs). Miam miam !


— (permalink)

9 Best Practices for Deploying Highly Available Applications to OpenShift

OpenShift blog

OpenShift is used to host critical applications across enterprises around the world. As with all critical applications, application teams expect their applications to be highly available, achieving industry standard benchmarks such as five nines of availability to provide continuous service to their customers.

OpenShift provides many different constructs to help you deploy your applications in a highly available manner, such that outages are avoided even if application instances or their underlying infrastructure become unhealthy or are restarted. In this article, we will explore nine best practices for deploying highly available applications to OpenShift.

1: Multiple replicas

Running more than one instance of your pods ensures that deleting a single pod will not cause downtime. For example, you are running a single instance of your application; if it gets deleted, you may find your application completely unavailable, though this is usually short-lived. In general, if you only have one replica of the application, any abnormal termination of it will result in downtime. In other words, you must have at least two running replicas of the application. Services have an integrated load balancer that will distribute network traffic to all pods of deployment. 

Recommendation 

We recommend setting multiple replicas as part of a deployment.

spec:
 replicas: 3

2: Update strategy

There are two deployment strategies, “Rolling” and “Recreate”:

The Rolling strategy is the default deployment strategy. It replaces pods, one by one, of the previous version of the application with pods of the new version while ensuring at least one pod is running. 

In Recreate deployment, we fully scale down the existing application version before we scale up the new version. The recreate method involves some downtime during the update process. Downtime might not be an issue for applications that can handle maintenance windows or outages. However, if there is a mission-critical application with high service level agreements (SLAs) and availability requirements, choosing a Rolling Update deployment strategy would be the right approach.

Recommendation 

We recommend using “RollingUpdate” when possible.

strategy
 type: RollingUpdate

3: Handling SIGTERM signal gracefully

When an OCP deployment is restarted or a pod is deleted, Kubernetes sends a SIGTERM signal to all the containers of the pod in an attempt to give the container an opportunity to gracefully shut down. Common use cases of handling SIGTERM gracefully would be to finish handling client requests or to persist state.

The default grace period to handle SIGTERM is 30 seconds. If users expect this to take longer, they can increase this by using the terminationGracePeriod deployment setting.

Recommendation 

Handle the SIGTERM signal in applications to ensure that applications shut down gracefully. Adjust the terminationGracePeriod setting as required.

spec:
...
 spec:
   terminationGracePeriodSeconds: 30
   containers:
   ...

4: Probes

​​Probes (health checks) play a vital role in monitoring application health. Readiness probes determine whether an application is ready to accept traffic. Liveness probes determine if the application should be restarted.

A: Liveness

Liveness probes are used to restart applications when they enter a broken state. It is a self-healing feature of Kubernetes/OpenShift and is important for applications to have to ensure they can attempt to recover in an automated fashion.

livenessProbe:
 tcpSocket:
   port: 8080
 initialDelaySeconds: 15
 periodSeconds: 20

B: Readiness

Readiness probes are used to take applications out of the load-balancing pool when they enter an undesirable state and become unable to serve traffic. They prevent clients from connecting to the application when it needs to be taken out of the load balancing pool temporarily to recover (but not be restarted).

The application accepts traffic when the readiness probe passes and the app becomes “Ready”. The app does not accept traffic and remains separate from the pool when the readiness probe has either failed or has not passed yet.

readinessProbe:
 tcpSocket:
   port: 8080
 initialDelaySeconds: 5
 periodSeconds: 10

C: Startup

Some applications have high startup times. For example, there may be a large number of initialization tasks, or the application may be dependent on an external service that is not yet ready. This makes setting liveness and readiness probes difficult because it is challenging to determine how long an application will take to start. To remedy this, users can leverage the “startup probe” to identify the moment an application starts. Then, once the startup probe returns successfully, the liveness and readiness probes will begin monitoring the application’s health:

startupProbe:
 httpGet:
   path: /healthz
   port: 8080
 failureThreshold: 30
 periodSeconds: 10

Recommendation 

Our recommendation is to leverage Liveness probes and Readiness probes to help ensure applications are healthy and constantly in a state to serve traffic. Use Startup probes to determine the point at which the application has started up.

5: External dependencies readiness

When the app starts, it should not crash due to a dependency such as a database that is not ready. You also want to ensure that dependencies are healthy during the life of your application. You can use initContainers/startupProbe to check external dependencies before running your main container. While the application is running, you can use the main container’s readinessProbe to ensure that it is only ready when connected to a healthy dependency.

We have discussed readinessProbes in the previous section. Here is an example of an init container that waits for a database to become ready:

initContainers:
   - name: wait-postgres
    image: postgres:12.1-alpine
    command:
    - sh
    - -ec
    - |
      until (pg_isready -h example.org -p 5432 -U postgres); do
        sleep 1
      Done

Recommendation 

We recommend using an initContainer or startupProbe to postpone application startup until dependencies are healthy. While your application is running, use a readinessProbe to continue to monitor the dependency’s health.

6: PodDisruptionBudget

A PDB (Pod Disruption Budget) limits the number of pod replicas that the cluster is allowed to take down for maintenance operations. PDB would ensure that the number of replicas running is never brought below the number specified. When a node is drained, all the pods on that node are deleted and rescheduled. If you are under a heavy load, the drain event could affect your availability. To maintain availability during cluster maintenance, you can define a Pod Disruption Budget.

Recommendation 

PDB is recommended for critical applications running in production. It provides you the means to specify a maximum limit to the number of application pods that can be unavailable during managed maintenance.

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
 name: my-pdb
spec:
 selector:  
matchLabels:
    foo: bar
 minAvailable: 2 

7: Autoscaling

OpenShift has two autoscalers available for the automatically scaling application pods:


Horizontal pod autoscaler (HPA) 

HPA is a feature used to scale pods out automatically based on gathered metrics. By using an HPA, you can maintain availability and improve responsiveness under unexpected traffic conditions.

HPA scales pod replicas based on the following formula:

X = N * (c/t)

In the above formula, X is the desired number of replicas, N is the current number of replicas, c is the current value of the metric, and t is the target value. You can find more details about the algorithm in the documentation.

The following example illustrates an HPA for CPU utilization, where the pods scale up or down to maintain a minimum of 3 and a maximum of 10, with a target mean CPU utilization of 50%.

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
 name: php-apache
spec:
 scaleTargetRef:
   apiVersion: apps/v1
   kind: Deployment
   name: php-apache
 minReplicas: 3
 maxReplicas: 10
 metrics:
 - type: Resource
   resource:
     name: cpu
     target:
       type: Utilization
       averageUtilization: 50

Another example to illustrate HPA for Memory utilization: HPA will scale pods up/down keeping a minimum of 3 and a maximum of 10 with an average memory of 500Mi:

<same as previous example>
 metrics: 
 - type: Resource
   resource:
     name: memory 
     target:
       type: AverageValue 
       averageValue: 500Mi

NOTE: The above examples use the autoscaling/v2beta2 API version, which is the most recent version at this time. For CPU utilization metrics, you can either use autoscaling/v1 or autoscaling/v2beta2 API version. For Memory utilization metrics, you must use the autoscaling/v2beta2 API version.

Vertical pod autoscaler (VPA)

While an HPA is used to scale additional pods to meet demand, a VPA is used to scale resources vertically for individual pods. A VPA optimizes the CPU and memory request values and can maximize the efficiency of cluster resources.

Similar to an HPA, a VPA automatically calculates target values by monitoring resource utilization.  However, unlike an HPA, a VPA evicts pods in order to update them with new resource limits. The VPA accounts for any governing pod disruption budget policies to ensure that disruptions do not occur during the eviction process. Finally, when the workload is re-deployed, the VPA mutating admission webhook overwrites the pod resource with optimized resource limits and requests before the pods are admitted to a node.

Following is an example VPA for auto mode. In auto mode, VPA assigns resource requests on pod creation and updates the existing pods by terminating them when the requested resources differ significantly from the new recommendation.

​​apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
 name: vpa-recommender
spec:
 targetRef:
apiVersion: "apps/v1"
kind:   Deployment
name:   frontend
 updatePolicy:
updateMode: "Auto"

There are other available modes, which can be found at OpenShift docs.

Things to consider before using VPA:

  • You must have a minimum of two replicas for the VPA to automatically delete pods.
  • Pods must be running in the project before VPA can recommend resources and apply the recommendations to new pods.
  • VPA reacts to most out-of-memory events, but not in all situations.

        Recommendations

  • Avoid using HPA and VPA in tandem, unless you configure the HPA to use either custom or external metrics.
  • In production, use VPA in Recommendation mode. That would be helpful to understand what the optimal resource request values are and how they vary over time.
  • Use HPA ​​for a sudden increase in resource usage over VPA, as VPA provides recommendations over a longer time period.

8: Leverage Pod Topology Spread Constraints

One of the core responsibilities of OpenShift is to automatically schedule pods on nodes throughout the cluster. However, if all pod replicas are scheduled on the same failure domain (such as a node, rack, or availability zone), and that domain becomes unhealthy, downtime will occur until the replicas are redeployed onto another domain. To prevent such an incident, you can leverage Pod Topology Spread Constraints.

Pod Topology Spread Constraints is a feature that allows you to disperse pod replicas evenly across your cluster. Below shows an example set of Pod Topology Spread Constraints.

kind: Pod
apiVersion: v1
metadata:
name: my-pod
labels:
  foo: bar
spec:
topologySpreadConstraints:
- maxSkew: 1
  topologyKey: node
  whenUnsatisfiable: DoNotSchedule
  labelSelector:
    matchLabels:
      foo: bar
- maxSkew: 1
  topologyKey: zone
  whenUnsatisfiable: DoNotSchedule
  labelSelector:
    matchLabels:
      foo: bar
containers:
- image: "docker.io/ocpqe/hello-pod"
  name: hello-pod

This example defines two pod topology spread constraints. The first is used to ensure that pods are distributed across nodes by referencing the topology label “node” (defined by the “topologyKey” setting). To be effective, each node in the cluster must have a label called “node” with a unique value. The “maxSkew” setting tells OpenShift the maximum acceptable difference in the number of pods between any two nodes.

The second pod topology spread constraint in the example is used to ensure that pods are evenly distributed across availability zones. To be effective, each node in the cluster must have a label called “zone” with the value being set to the availability zone in which the node is assigned. By using two separate constraints in this fashion, you can ensure that your pods are distributed evenly across availability zones and the nodes within those zones.

Recommendation

Use Pod Topology Spread Constraints to ensure that pods are distributed across failure domains. Cluster operators should ensure that nodes are labeled in a consistent manner for the constraints to reliably distribute workloads.

9: Deploy applications using Blue/Green or Canary strategies

One major goal for most enterprises is to deploy applications and features without interrupting users or processes that interact with your application. To help ensure a successful rollout, Blue/Green and Canary deployments are both popular options for deploying new releases of an application. Let’s explore how the Blue/Green strategy can be performed in OpenShift.

Blue/Green Deployments

Blue/Green deployments involve deploying a new version of your application alongside the old version. The old version can be referred to as “blue”, and the new version can be referred to as “green”. During the deployment, traffic is flipped from the blue side to the green side. In the event an issue occurs, traffic can be flipped back to the blue side.

This traffic flip can be performed using an OpenShift route. Below shows an example of a route selecting a blue service:

apiVersion: route.openshift.io/v1
kind: Route
metadata:
name: my-app
spec:
port:
  targetPort: 8080
to:
  kind: Service
  name: my-app-blue

To perform a traffic flip after deploying the green side, the route’s “to” section can be updated to target the green service:

<same as previous>
  kind: Service
  name: my-app-green

Blue/Green deployments are powerful, but in some cases, it is not desirable to shift 100% of traffic to the other side. This is where Canary deployments come in, which provide greater flexibility over the amount of traffic being shifted.

Canary Deployments

Canary deployments allow you to route a subset of traffic to the new version of your application. Whereas blue/green deployments involve shifting 100% of traffic to the new version, canary allows you to shift, for example, 10% to the new version. Then, you can slowly ramp up to 100% as desired.

Below is an example of an OpenShift route that shifts 10% to the new version of an application (green):

apiVersion: route.openshift.io/v1
kind: Route
metadata:
name: my-app
spec:
port:
  targetPort: 8080
to:
  kind: Service
  name: my-app-blue
  weight: 90
alternateBackends:
  - kind: Service
    name: my-app-green
    weight: 10

The percentage of traffic being handled by a given service is calculated using the formula weight / sum_of_weights. The my-app-blue service will handle 90% of traffic because 90/(90+100) is 0.9, therefore, the green service will handle 10%. Using canary deployments in this fashion allows you to slowly ramp up traffic as you monitor your application’s health.

Recommendation

Use Blue/Green or Canary deployments to prevent disruptions during the rollout of new application versions. Use Canary deployments if greater flexibility of the traffic rollout is required.

Un sénateur veut rémunérer auteurs et éditeurs en taxant chaque revente de livre d’occasion

Le Hollandais Volants -- Liens

Génial, après la taxe #copyreich sur les téléphones d’occasion reconditionné, la voilà qui se pointe pour les livres d’occasion aussi.

Je n’ai rien contre les auteurs, hein, mais comme je ne rémunère pas Siemens ou Samsung quand je revend mon frigo, il n’est pas normal que l’on taxe les gens plusieurs fois pour la même chose !

J’imagine du coup qu’ils vont aussi interdit les boîtes à livres, considérés comme des bibliothèques pirate sauvages, et responsables du terrorisme livresque. Bouhou les vilains !

ÉDIT : dans les commentaires on lit le cas des manuels scolaires, rendus à la librairie à la fin de l’année. Je vois déjà les éditeurs baver devant cette loi (pondue au passage par un type lui-même auteur, évidemment).


— (permalink)

Why introverts make exceptional designers & how leaders can support them | by Jeremy Bird | Jan, 2022 | UX Collective

Le Hollandais Volants -- Liens

Concernant tous ceux qui veulent vous payer vos interventions ou conférences en visibilité :

No recruiter has ever mentioned speaking engagements I’ve done as the reason why they reached out. No boss has said, “you spoke at X, we’d like to fund your projects or give you a promotion.”

Voilà.


— (permalink)

Le cauchemar américain de la COVID-19 - World Socialist Web Site

Liens SebSauvage
Oui je sais encore le Covid-19, désolé. C'était juste pour poser ici cette statistique ahurissante: 2000 morts par jour aux USA. Et en augmentation. L'équivalent de 13 Airbus qui s'écrasent par jour.
Complément: https://www.nature.com/articles/d41586-022-00104-8
(Permalink)

Le blocage de publicité ne constitue pas une violation du droit d'auteur, estime un tribunal. Adblock Plus remporte une victoire contre un éditeur qui l'accusait de « modifier le code des sites »

Liens SebSauvage
Je pose ça là.
Encore heureux !
Sinon si je désactive Javascript dans mon navigateur, je viole le droit d'auteur d'Axel Springer parceque leur publicités ne s'affichent plus ?  pfff...

Ah ces médias qui exigent qu'un navigateur se comporte comme une télévision et affiche exactement ce qu'ils veulent. Non un navigateur ce n'est pas ça. Vous m'envoyez des données et *je choisis* de mon côté comment elles seront affichées.

Ceci dit, N'UTILISEZ PAS ADBLOCK PLUS, puisque ce bloqueur de publicités affiche quand même des publicités.
Prenez l'original, le seul, l'unique uBlock-origin: https://addons.mozilla.org/fr/firefox/addon/ublock-origin/
(Permalink)

Kelyan et moi !

Blog Sohann

Cette année, dans ma classe, on est 2 petits loulous diabétiques: Kelyan et moi! Kelyan est chez les grands, il a 6 ans. On forme une bonne équipe tous les 2, on s'amuse vraiment bien ensemble. On se voit à l'école et on se voit aussi à l'extérieur:

  • Kelyan vient souvent jouer à la maison:

description

description

  • je vais aussi parfois chez lui:

description

description

  • maman nous a emmenés tous les 2 à la ludothèque:

description

  • on va parfois se balader ensemble et on est jumeaux de vélos!

description

description

C'est chouette pour moi d'avoir un bon copain et de pouvoir partager le diabète. Avec Kelyan on a la même pompe, les mêmes capteurs et les mêmes lecteurs de glycémie! On compare même nos autocollants sur nos capteurs quand on les change! Valérie la maîtresse nous trouve très autonomes avec notre diabète à l'école :-)

C'est chouette aussi pour maman de pouvoir partager sur la vie de parents de diabétique avec Yasmine la maman de Kelyan. On discute, on se soutient, on se dépanne des capteurs...

Enhancing GitOps with the Patch Operator

OpenShift blog

Introduction

GitOps is the combination of two winning approaches: infrastructure as code and Git-based workflows to accept configuration changes and deploy them. In Kubernetes, GitOps generally is implemented with a set of manifests (or manifest templates) stored in a Git repository and a Kubernetes operator that deploys these manifests into a Kubernetes cluster. At the time of writing, the two most popular operators in this space are Argo CD and Flux (see also this article for an in depth comparison).

I have been using Argo CD recently both with my customers as well as for my personal experiments and I believe that GitOps is definitely an approach that everyone working with Kubernetes should adopt.

That being said, there are two limitations that I have found that inhibited me from building robust, reusable Git workflows.

The first limitation is that, as a de facto rule, GitOps operators can only manipulate resources that they create. They will not change pre-existing resources. However, any Kubernetes distribution will most likely include a significant amount of pre-configured settings and components. As consumers of these environments, we typically need to perform some customizations on these pre-existing components to suit our needs. This is certainly true for OpenShift, which, as a sophisticated Kubernetes distribution, includes a vast number of additional features and configuration options.

The second limitation is that it is hard to create configurations that depend on the current state of a cluster. Existing GitOps operators expect all of the parameters to be passed from the source repositories without the ability to discover values based on the state of existing objects within the cluster (this is not fully accurate in the case of Flux and Helm, because Flux supports using the Helm lookup function). One such example that highlights this issue is that most Kubernetes clusters (including OpenShift) have the concept of a base domain (the domain that all FQDNs of endpoints exposed by the cluster share). This naturally becomes a parameter that would be needed across a variety of cluster and user level configurations, including applications deployed to the cluster.

Templated Patches

It turns out that by using templated patches, we can solve both of the limitations of the current GitOps operator implementations called out previously.

Templated patches are patches whose actual value is realized by merging a template with a set of  parameters. Consider, for example, this patch:

spec:

  base_domain: {{ (lookup "config.openshift.io/v1" "DNS" "" "cluster").spec.baseDomain }}

Here we use the golang template notation and processing engine. This patch sets the spec.base_domain field of a fictitious object to the current value of the base domain for an OpenShift cluster, which can be found in a cluster level object named cluster of type DNS and apiVersion  config.openshift.io/v1. We are using the lookup function to retrieve the value from a field within an existing object from a running cluster.

With this primitive we can solve both of the issues stated above. If we have a way to declare the intention to make a patch to an existing object, then we can use a templated patch to describe what kind of change we need.

The Patch Operator

We created the patch-operator to support both the above use cases. Instructions on how the usage including the installation can be found within the project repository.

While the patch-operator supports a number of use cases, l start off by discussing creation time injection.

Creation time injection

This operator allows you to install a mutating webhook to intercept the creation of any object type and apply a patch to it. Support is also available to manage resource updates as well, but the overall use case described favors patching at creation time. Instructions on how to create the webhook can be found within the operator documentation.

This feature, like most, can be best illustrated with an example: Let’s say we want to configure a cert-manager Issuer, a Kubernetes Custom resource included as part of the cert-manager solution which represents Certificate Authorities that are able to generate signed certificates, to integrate with Let’s encrypt. This is handy for demonstration and production scenarios as it will provide certificates from trusted Certificate Authority to be exposed by your cluster.  

The following object represents the resource that we need to create:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-issuer
spec:
acme:
  server: 'https://acme-v02.api.letsencrypt.org/directory'
  email: user@example.com
  privateKeySecretRef:
    name: letsencrypt-staging
  solvers:  
  - dns01:
      route53:
        accessKeyID: << access_key >>
        secretAccessKeySecretRef:
          name: cert-manager-dns-credentials
          key: aws_secret_access_key
        region: << region >>
        hostedZoneID: << hosted_zone_id >>

As you can see, three of the fields depend on the current configuration of the cluster, and in most cases, cannot be known beforehand.

The value of these fields can be discovered from the running cluster and injected with a templated patch.

The patch-operator creation time injection can be activated by an annotation, so an updated manifest would be as follows:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-issuer
namespace: {{ .Release.Namespace }}
annotations:
  "redhat-cop.redhat.io/patch": |
    spec:
      acme:
      - dns01:
          route53:
            accessKeyID: {{ (lookup "v1" "Secret" .metadata.namespace "cert-manager-dns-credentials").data.aws_access_key_id | b64dec }}
            secretAccessKeySecretRef:
              name: cert-manager-dns-credentials
              key: aws_secret_access_key
            region: {{ (lookup "config.openshift.io/v1" "Infrastructure" "" "cluster").status.platformStatus.aws.region }}
            hostedZoneID: {{ (lookup "config.openshift.io/v1" "DNS" "" "cluster").spec.publicZone.id }}
spec:
acme:
  server: 'https://acme-v02.api.letsencrypt.org/directory'
  email: {{ .Values.letsencrypt.email }}
  privateKeySecretRef:
    name: letsencrypt-staging
  solvers:  
  - dns01:
      route53:
        accessKeyID: dummy
        secretAccessKeySecretRef:
          name: cert-manager-dns-credentials
          key: aws_secret_access_key
        region: dummy
        hostedZoneID: dummy

The mutating webhook detects the presence of the injection annotation redhat-cop.redhat.io/patch on the incoming object, performs the resolution of the templated patch, including using the lookup function, it patches the object and then it returns the mutated object.

With this approach, we unlock the capability to reuse the same resource across any cluster and can store this manifest in our GitOps repository.

Patch enforcement

There are situations in which injection at creation time might not be enough. This might be because the resources we need values from may not exist yet, or because the injected values might change over time, or because someone might inadvertently change the values in the patched object to something different from what we need. In either of these cases, as administrators, we need to make sure that our patch is always enforced.

To address these use cases, the patch-operator provides a way to declaratively express the need for a patch that will be permanently enforced. This is accomplished via the Patch CRD.

Let’s take a look at a few examples.

The Patch CRD allows for declaring the source objects (from which we need to look up values) and target object (to which we need to apply the patch), the patch template, and a few more fields to govern how the patch is handled (see the reference in the documentation for a field by field explanation). Here is an example:

apiVersion: redhatcop.redhat.io/v1alpha1
kind: Patch
metadata:
name: test-complex-patch
spec:
patches:
 test-complex-patch:
   targetObjectRef:
     apiVersion: v1
     kind: ServiceAccount
     name: test
     namespace: test-patch-operator
   patchTemplate: |
     metadata:
       annotations:
         {{ (index . 1).metadata.name }}: {{ (index . 2).metadata.name }}  
   sourceObjectRefs:
   - apiVersion: v1
     kind: Namespace
     name: test-patch-operator
   - apiVersion: v1
     kind: ServiceAccount
     name: default
     namespace: test-patch-operator

This simple test patch adds an annotation on the test Service Account located in the test-patch-namespace namespace. The annotation key and value are respectively sourced from the test-patch-namespace namespace name and the name from the default service account.

When this patch is created, the patch-operator watches the source and target objects, and if and when any of them changes over time, the patch is reapplied, thus enforcing the desired state.

Let’s go another step forward and see some real world use case scenarios

Injecting the cluster default certificate

Often when configuring OpenShift, we need to replace the default certificate within the ingress controller (a pre-existing resource). The details associated with the certificate can be injected using the following Patch:

apiVersion: redhatcop.redhat.io/v1alpha1
kind: Patch
metadata:
name: letsencrypt-ingress-operator
namespace: openshift-config
spec:
patches:
 letsencrypt-ingress-operator-patch:
   targetObjectRef:
     apiVersion: operator.openshift.io/v1
     kind: IngressController
     name: default
     namespace: openshift-ingress-operator
   patchTemplate: |
     spec:
       defaultCertificate:
         name: lets-encrypt-certs-tls

This configuration alone may not be enough to properly configure the ingress controller certificate. This is due to the fact that the ingress controller expects the certificate and private key to be stored in a secret containing the keys. In fact, the ingress controller (weirdly) expects the cert and key at the secret keys: cert and key respectively. But the convention (which is followed by cert-manager) in Kubernetes is to generate TLS secrets in which the secret keys are: tls.crt and tls.key respectively. We can the use another patch to solve this challenge:

apiVersion: redhatcop.redhat.io/v1alpha1
kind: Patch
metadata:
name: letsencrypt-certs
namespace: openshift-config
spec:
patch:
 targetObjectRef:
   apiVersion: v1
   kind: Secret
   name: lets-encrypt-certs-tls
   namespace: openshift-ingress
 patchTemplate: |
   data:
     cert: {{ (index (index . 0).data "tls.crt") }}
     key: {{ (index (index . 0).data "tls.key") }}
 patchType: application/merge-patch+json

Notice that we are patching the secret referenced within the IngressController resource by looking up fields from the secret itself and applying the content to the required keys. Since the operator is constantly enforcing the patch, when the certificate is rotated, the newly patched keys will also be updated.

Service account pull secret

Often, when using an enterprise container registry, pull secrets need to be added to all the tenant namespaces so that they can properly retrieve content from it. While we could ask the tenant to specify the pull secret in every single manifest with a reference to this registry, a better alternative would be to bind the pull secret to the default Service Account such that it is available automatically. In order to accomplish this task, we need to patch the default service account in every tenant namespace. The default service account is generated by the Kubernetes control plane, so it is a resource that is not owned by the GitOps operator.

With the patch-operator, we can configure a patch that patches multiple objects at the same time. The above used case can be modeled with the following patch:

apiVersion: redhatcop.redhat.io/v1alpha1
kind: Patch
metadata:
name: puller-secret-service-account-patch
namespace: openshift-config
spec:
patch:
 targetObjectRef:
   apiVersion: v1
   kind: ServiceAccount
   name: default
 sourceObjectRefs:
 - apiVersion: v1
   kind: Namespace
   name: '{{ .metadata.namespace }}"
 # gives gch-puller to all default service accounts in namespaces with the app label.  
 patchTemplate: |
   imagePullSecrets:
     {{- if and (hasKey (index . 1).metadata.labels "app") (not (has (dict "name" "ghcr-puller") (index . 0).imagePullSecrets)) }}
   {{ append (index . 0).imagePullSecrets (dict "name" "ghcr-puller") | toYaml | indent 2 }}
   {{- else }}
   {{ (index . 0).imagePullSecrets | toYaml | indent 2 }}
   {{- end }}

This patch will be applied to all of the default service accounts from namespaces that have the label app present regardless of the value. By targeting a specific label, it provides a sort of marker signifying the fact that this namespace is a tenant namespace and should have the desired configuration injected.

This patch adds a secret called ghcr-puller to the list of the pull secrets automatically available to resources using this service account. As part of this scenario, we assume that the ghcr-puller-secret secret was provisioned previously to all the required namespaces. In addition, there is logic included in this patch to check whether the ghcr-puller element exists already in the array of pull secrets as it is challenging to patch arrays in JSON formatted documents.

The documentation has information on how to use patches that target multiple objects.

Conclusion

As stated at the onset, the primary reason why the patch-operator was built is to enhance the experience of using GitOps methodologies and GitOps operators to manage Kubernetes clusters. Several use cases in which the patch-operator has been useful in my workflows have been demonstrated within this article. It is the hope that you will find this operator useful as well.

Hébergeurs : la France prépare le retrait en une heure des contenus terroristes

Le Hollandais Volants -- Liens

1 heure… alors même que le temps de traitement de n’importe quel dossier par l’Administration est de l’ordre de l’année.

On sait très bien comment ça va terminer : un gus qui signale un tweet (alors qu’il sait que c’est un signalement abusif) et hop, le tweet est supprimé. Vous pensez réellement qu’ils vont risquer 4 % de leur chiffre d’affaire pour votre liberté d’expression ? Haha.

Samedi dernier, le compte parodique « @Dieu_off » s’est fait suspendre à cause d’un fanatique religieux qui se trouvait avoir eu un « compte vérifié », et à qui un simple signalement d’un autre compte peut le bloquer.

Tout ça, ça c’est exactement le genre le dérives vers lequel on va, et ça sera automatisé.
Le compte @Dieu_off avait 1,2 millions d’abonnés et a été restauré depuis. Nul doute que toi avec tes 1 000 followers, tu peux aller te gratter pour revoir ton compte si ça t’arrive.

Deuxième chose : à votre avis il faudra combien de temps pour que ceci soit étendu aux liens de partager de fichiers ? au porno ? puis à toutes les images ou mots qui peut choquer quelqu’un ?

La conclusion à tirer est simple : ayez un espace d’expression personnel. Une simplement document HTML, un petit moteur de blog, le tout chez un hébergeur à 2-3€/mois.
Au moins vous pourrez parler sans qu’un connard vous signale et vous bloque tout.
Au moins vous ne serez pas muselé parce qu’une plateforme vous aura jeté dehors par erreur (ou non).
Au moins vous ne serez pas soumis à un robot pseudo-IA complètement con qui filtrera plutôt trop que pas assez pour ne pas que la plateforme risque d’amende.

Bref, au lieu de jouer au Web3 à coup de blockchain et de NFT, jouez plutôt au Web 1.0 : un hébergement, un petit blog, un site bien au chaud à vous (voire chez vous) et incensurable.


— (permalink)
more
mark as read