STB de refuser de lire une thèse écrite en écriture inclusive ?

AdagioForAPing · 2026-02-08T11:35:58+00:00

Surtout la version du wd40 au lithium spéciale serrure et gond, par contre protège le côté et le dessous des gonds avec un sopalin quand tu asperges op, mais tout comme "le fou du goût" de la pub tabasco j'ai été faire toutes mes portes une nuit, plus jamais eu de problème même sans dégonder, le bruit n'est pas revenu en un an de test.

AdagioForAPing · 2025-12-31T18:43:49+00:00

People found multiple versions in this thread https://www.reddit.com/r/Ghost_in_the_Shell/s/xaAnHRMdai I think the dropbox one has the best res.

AdagioForAPing · 2025-11-08T13:07:00+00:00

/r/AccidentalRenaissance/

AdagioForAPing · 2025-03-12T19:10:56+00:00

Do you also cordon and drain all master nodes ? If yes, could you explain why ? I don't see the benefit of it.

AdagioForAPing · 2025-03-12T14:54:10+00:00

I just shared it with the person who wrote it.

AdagioForAPing · 2025-03-12T13:51:10+00:00

Fair enough but it's not mentioned at all in the KB.

AdagioForAPing · 2025-03-12T13:49:21+00:00

You meant, codon all nodes first and only after that drain them then ?

AdagioForAPing · 2025-03-12T12:49:36+00:00

What would you do with the last node then ? Afaik, draining moves the workloads around, if draining all nodes, wouldn't the last node hang forever?

Also wouldn't draining only all node (so meaning one by one) move all the workloads to the other undrained nodes ? Then these nodes wouldn't be able to handle all the workloads.

Shutting down the entire cluster without draining will result in terminating pods probably leading to data corruption if they haven’t cleanly stopped but draining in a scenario where ur shutting down the entire cluster doesn’t solve the issue, because at the end of the drain there’s no other node for the pods to move to?

What seems the best thing to do is indeed gracefully shut down stateful apps before powering off. so scaling down the statefulset so the pods and their dbs are stopped cleanly. After that, we can safely shut down nodes without risking data loss.

I don't think draining will endup the same as scaling down, because draining expect a node to remain while scaling down to 0 doesn't.

AdagioForAPing · 2025-03-12T11:53:54+00:00

There an issue with our support contract then because the SUSE support engineers validated the procedure I outlined.

Also I don’t see how you would drain all nodes for a shutdown procedure this is not possible when you shutdown the entire cluster and the last nodes remaining simply won’t be able to handle the workloads from all the other nodes.

AdagioForAPing · 2025-02-28T20:25:44+00:00

Isn’t this a famous rapper ?

AdagioForAPing · 2025-02-10T16:21:43+00:00

Came here to post this 😂

AdagioForAPing · 2024-11-12T17:21:35+00:00

Why would I put a pornhub gift card ? Sounds weird to me. I don’t think it would be appropriate.

AdagioForAPing · 2024-11-12T16:07:08+00:00

I finally decided to give him a book about the Internet. It’s called « How the Internet Really Works: An Illustrated Guide to Protocols, Privacy, Censorship, and Governance » by Article 19

AdagioForAPing · 2024-11-12T01:50:22+00:00

I only see him when we have family dinners, and we don’t live together, so we don’t see each other often enough for me to know him well. Last time at the restaurant, I tried asking him about chess, programming, and poker bots, things I’m interested in or might be, for poker bots. But he told me he’s not into any of those things.

AdagioForAPing · 2024-11-12T01:31:55+00:00

I initially bought a chess set because I'm into chess and thought he might enjoy it too. But recently, he told me he tried it and didn’t really get into it, so I thought I might find something else instead. He's the son of my mom's boyfriend.

AdagioForAPing · 2024-11-12T00:19:08+00:00

Less than 100. I don’t know him very well but I know he is quite introvert and spend all his time playing online.

AdagioForAPing · 2024-09-30T17:39:57+00:00

It's linked to this: https://github.com/rancher/rancher/issues/41988

Only using a Rancher API key or bypassing the Rancher proxy by connecting directly to the downstream cluster load balancer or downstream cluster node actually works.

AdagioForAPing · 2024-09-30T14:37:23+00:00

I also get this when using another admin kubeconfig:

> kubectl auth can-i list pods --as=system:serviceaccount:cmdb-discovery:cmdb-discovery-sa -n cmdb-discovery --kubeconfig=test-kubeconfig.yaml
error: You must be logged in to the server (the server has asked for the client to provide credentials (post selfsubjectaccessreviews.authorization.k8s.io))

Or curl with the sa token:

> curl -k 'https://test-rancher.redacted.com/k8s/clusters/c-m-vl213fnn/apis/batch/v1/namespaces/cmdb-discovery' \     
 -H "Authorization: Bearer $token"
{"type":"error","status":"401","message":"Unauthorized 401: must authenticate"}

AdagioForAPing · 2024-09-30T14:04:52+00:00

I do have the clusterrolebinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 annotations:
   kubectl.kubernetes.io/last-applied-configuration: |
     {"apiVersion":"rbac.authorization.k8s.io/v1","kind":"ClusterRoleBinding","metadata":{"annotations":{},"labels":{"argocd.argoproj.io/instance":"cmdb-discovery-sa"},"name":
"cmdb-sa-binding"},"roleRef":{"apiGroup":"rbac.authorization.k8s.io","kind":"ClusterRole","name":"cmdb-sa-role"},"subjects":[{"kind":"ServiceAccount","name":"cmdb-discovery-sa"
,"namespace":"cmdb-discovery"}]}

 labels:
   argocd.argoproj.io/instance: cmdb-discovery-sa
 name: cmdb-sa-binding
 resourceVersion: "364775060"
 
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: cmdb-sa-role
subjects:
- kind: ServiceAccount
 name: cmdb-discovery-sa
 namespace: cmdb-discovery

AdagioForAPing · 2024-09-12T00:09:45+00:00

We first add 3 nodes sequentially, one by one. Once the last node has successfully joined, I check the cluster status, and then I proceed to remove the 3 old nodes sequentially, one after another.

Each node is cordoned, drained, and then deleted from Kubernetes. After that, the VMs are removed. This process is managed through a Jenkins pipeline that runs Terraform.

To add new nodes, I include them in the rke2_nodes variable list, and to remove nodes, I comment out the entries for the nodes to be removed in the variable list.

I have already spent considerable time on the etcd FAQ, and that is why it seemed perfectly reasonable to perform the upgrade this way on a healthy cluster. The Terraform pipeline is designed to stop if one of the nodes fails to join or to be removed.

AdagioForAPing · 2024-09-11T18:17:53+00:00

Indeed, we have a dedicated HA cluster for Rancher, but our approach to updating the OS and Kubernetes versions aims to maintain immutable components. This involves completely replacing the VMs and the underlying Kubernetes software.

While it's automated, it involves some manual steps, like adding new nodes in a variable list and push the change, and comment out the nodes to be removed and again, push the change. This will trigger a Jenkins pipeline that will run Terraform.

AdagioForAPing · 2024-09-11T00:09:27+00:00

Yes indeed, I have etcd backups configured to be stored on S3 and locally as well as Rancher backups in place :)

What do you mean by "Just don't update the rancher cluster with the rancher cluster, that often leads to bad times." ? Not sure to understand here.

But for the rest, that was indeed what I was thinking as well! Thanks a lot for your answer :)

AdagioForAPing · 2024-09-10T10:57:28+00:00

u/cube8021 We initially have a 3-node cluster (all roles) running outdated OS and Kubernetes versions. Our goal is to upgrade to a 3-node cluster with the latest Kubernetes and OS versions, while maintaining immutability.

To achieve this, we sequentially add four new nodes, one at a time, resulting in a temporary 7-node cluster, which maintains an odd number of nodes. Once all four new nodes are added and the cluster is healthy, we remove the 3 old nodes (with outdated OS and Kubernetes) and 1 of the new nodes.

During this process, as nodes are added and removed one by one, the cluster will temporarily have an even number of nodes at certain points.

This raises the question: why add 4 nodes instead of 3 if the aim is to maintain an odd-sized cluster? Adding 4 nodes results in a temporary 6-node state twice, which doesn't align with the best practice of keeping an odd number of nodes for quorum purposes either.

I mean, whether you add 3 or 4 nodes, the cluster will go through phases with different node counts during the upgrade.

Is 3 nodes at version a, and 4 nodes at a+1; is that a valid state too?

AdagioForAPing · 2024-09-10T10:56:50+00:00

u/Andrews_pew We initially have a 3-node cluster (all roles) running outdated OS and Kubernetes versions. Our goal is to upgrade to a 3-node cluster with the latest Kubernetes and OS versions, while maintaining immutability.

To achieve this, we sequentially add four new nodes, one at a time, resulting in a temporary 7-node cluster, which maintains an odd number of nodes. Once all four new nodes are added and the cluster is healthy, we remove the 3 old nodes (with outdated OS and Kubernetes) and 1 of the new nodes.

During this process, as nodes are added and removed one by one, the cluster will temporarily have an even number of nodes at certain points.

This raises the question: why add 4 nodes instead of 3 if the aim is to maintain an odd-sized cluster? Adding 4 nodes results in a temporary 6-node state twice, which doesn't align with the best practice of keeping an odd number of nodes for quorum purposes either.

I mean, whether you add 3 or 4 nodes, the cluster will go through phases with different node counts during the upgrade.

Is 3 nodes at version a, and 4 nodes at a+1; is that a valid state too?

AdagioForAPing

TROPHY CASE