Pages

Monday, June 23, 2025

Behind the scene: La keynote de clôture de DevLille 2025 sponsorisée par Le Cht'i Jug

Salut les amis,

Comme tu le sais (ou pas), je fais partie de l'organisation du Ch'ti JUG depuis pas mal de temps. Nous sommes tous bénévoles dans cette association. Je fais d'ailleurs un gros bisous aux autres copains membres de l'association, Thomas Recloux, Gautier Dhordain, Julien Jakubowski et Guillaume Wallet avec qui nous essayons de proposer une fois par mois une session avec un sujet de qualité suivi d'un un coup à boire sympa dans un lieu qui change à chaque session et le tout gratuitement. Un grand merci d'ailleurs à nos sponsors pour permettent tout cela!

Je vais te raconter comment le Ch'ti JUG s'est retrouvé embarqué à sponsoriser la dernière session de DevLille animée par l'excellent Ludovic Borie pour une keynote de fermeture "debrief à chaud".

Installe-toi confortablement, prends un café et c'est parti:

Comment ça commence?

Un soir, un Mardi 6 Mai 20h57, tu reçois un mail de Fanny Demey, avec ce titre:

Je te passe les détails du mail beaucoup trop TOP SECRET, bon ok, en substance, Fanny nous propose de sponsoriser la keynote de fermeture animé par Ludovic en offrant une bière ou un soft aux participants dans une "petite" salle de 400 personnes pour un budget probable de 300€.

Voici la réaction de l'équipe sur notre slack:

N'oublions pas que le slogan du Jug est "In java an Beer we trust", ca nous parait bien matcher 😀

On est tous super emballés, on a un peu de trésorerie, "lezzzzzz go" comme disent les djeuns. 

On s'organise comment?

11 Mai 2025, création du channel slack #devlille-2025

On commence à se demander comment on va gérer la chose. Le point clé c'est d'avoir le jour J à l'heure H et devant la salle, un gros paquet de bières et de soft.

Allez, je m'auto balance, je voulais initialement tout déléguer aux organisateurs de DevLille 😂


Comme mon message n'était pas clair, Thomas se dit que c'était une bonne idée qu'on gère la chose nous même 😎. 

Acheter 400 bières et soft

Allez c'est parti, il faut qu'on trouve comment avoir beaucoup de bières et de soft, fraiches, en plein centre de Lille Grand Palais un vendredi en fin d'après midi:

Même pas peur. Fanny nous donne le contact du prestataire qui gère déjà les boissons sur la conférence que nous contactons. On demande un premier devis pour 300 bières et 150 limonades pour se donner une idée plus concrète. Le devis arrive................. Plus de 1 300€

Ludovic, speaker de la keynote, qui est dans les échanges de mail, a aussi un coup de chaud.

C'est un budget que dans l'absolu l'association pourrait supporter mais qui n'est pas en cohérence avec nos dépenses évènementielles. Il nous faut trouver une solution pour que cela coûte moins cher. Mon idée à ce moment là c'est qu'on ait tous la même vision, je tente de résumer la situation et on est d'accord:

En changeant de type de bière, en revoyant les quantités à la baisse (une salle comble est peu probable pour la dernière session de la journée. Mode optimisation activé. On dégaine un Google spreadsheet et à base de calcul savant... 

On tombe finalement d'accord pour quasiment 200 bières et 50 limonades pour un devis d'à peu près 600€. deal (Spoiler alert: c'était encore beaucoup trop 😂).

La veille de la conférence

Un moment de convivialité est organisé par les organisateurs avec les speakers la veille de la conférence. Je croise Emmanuel et Ludovic, on parle de cette fameuse session de clôture, on sent que ça peut être vraiment chouette et en même temps on se pose plein de questions:

  • Y aura t-il du monde?
  • Est-ce que ca sera convivial?
  • Est-ce qu'on arrivera à faire un truc assez interactif
  • Est-ce que les bières seront fraiches 😀
  • Wait and see...

C'est parti, DevLille commence!

On est tous plus ou moins la tête sous l'eau parmi les organisateurs du Ch'ti JUG. Certains ne peuvent pas être là, d'autres ont un stand professionnel pour leur boite dans la conférence à gérer, moi j'ai la chance d'être MC le vendredi après midi

La bonne nouvelle c'est que Thomas nous informe que les boissons sont déjà sur place:


Tout est sous contrôle. 

Vendredi, dernière session

Thomas s'était assuré en amont avec le prestataire de boisson qu'elles seraient bien fraîches et livrées juste devant la salle avant le début de la session. C'est chose faite. Elles sont là.

On voit Ludovic arriver avec un parasol et une table à carreau rouge, ça promet!

Dans un bordel organisé, les gens arrivent et on leur propose au choix une bière ou une limonade et on leur offre un décapsuleur du Ch'ti JUG.

Pendant que les gens continuent d'arriver, Ludovic lance le début de la session, on trinque tous ensemble!



Au vu des gens présents et qui arrivent encore, on se dit que sur les quantités, on est bon. même très large ;-)

On découvre le contenu réel de la session en même temps que tout le monde, Ludovic a prévu pas mal de sondage live et de donner la parole à l'assemblée. L'ambiance est décontractée, c'est convivial, ça rigole, les gens ont envie de prendre la parole. 

Il n'est pas beau ce petit setup?!


On avait 4 micros mains à disposition, l'équipe du Ch'ti JUG se met au service. On passe dans tous l'amphi avec les micros et comme il reste pas mal de boissons, on propose d'apporter une 2e boissons à ceux qui ont très soif. 

Je me suis retrouvé à un moment avec deux bières dans la main gauche et 2 micros dans la main droite et je me suis trompé, au lieu de donner un micro, j'ai donné une bière. La personne n'a pas dit non 😂


Le temps passe très vite, c'est déjà la fin.

Tout le monde ramène gentiment sa consigne à la fin, la salle est propre.

Epilogue

"Et les gars, ils nous restent pleins de boissons, on fait quoi????"


Le prestataire reprend les boissons non consommées dans une certaine proportion mais on n'y est pas du tout. On se retrouve à dire que ca serait bien de récupérer. Je suis garé au parking souterrain de Lille Grand Palais, Thomas me dit que je peux venir avec ma voiture avec tous les prestataires pour récupérer les restes.



Je sors du parking, je vais à l'entrée fournisseur, la barrière est ouverte, je ne vois personne, je rentre tranquillement littéralement dans Lille Grand Palais où je retrouve les prestataires qui terminent aussi de ranger. Le gars de la sécurité qui avait laisser la barrière ouverte me rattrape et me sermonne comme un bandit récidiviste. drôle.

6 caisses dans une petite Fiat 500. Ca passe. Large.




Tuesday, June 17, 2025

Être MC à DevLille 2025

 Salut les amis,

J'ai été MC à DevLille 2025, installe-toi confortablement, prends un café et je te raconte tout ça:

DevLille c'est quoi?



Historiquement appelé DevFest Lille et très simplement renommé DevLille cette année, DevLille est l'une des plus grosses conférences Tech Lilloise. Celle-ci se déroule sur 2 jours. Le petit truc en plus, au delà de proposer des contenus Tech de qualité, c'est de proposer une conférence à dimension humaine et environnementale. Je ne l'invente pas, cela fait partie du pitch du site de DevLille, en revanche, cela se ressent lors de la conférence et c'est chouette.

Autre point à souligner, le prix de la place. Une place pour une journée, c'est 40€. Juste incroyable quand on voit tout ce qui est mis en oeuvre. 

MC c'est quoi?




Si je ne me trompe pas les organisateurs ont introduit ce rôle l'année dernière et j'avais trouvé ça cool. MC, c'est Master of Ceremony, Maitre de cérémonie, bref Monsieur Loyal quoi. Le rôle consiste globalement à accueillir le speaker juste avant sa présentation, l'aider à se préparer s'il a besoin et lancer le début de la présentation avec une petite introduction pour qu'il puisse ensuite la dérouler tranquillement. 

Les organisateurs m'ont contacté pour me proposer d'être MC cette année sur 1/2 journée dans une des salles.  Voici "la fiche de poste" que tu reçois quand on te propose de l'être:
"Le rôle est simple : vous serez assigné·e à une salle pendant une demi-journée pour introduire le ou les intervenant·e·s. Vous êtes libre d’introduire les talks comme vous le souhaitez, mais on vous encourage vivement à discuter en amont avec les speakers pour mieux les présenter."

J'image que le fait que de faire partie de l'organisation Ch'ti Jug et de faire des lancements de sessions assez fréquemment ont joué en ma faveur. 

Pourquoi c'est cool d'avoir des MCs

Je trouve que d'avoir des MCs dans une conférence est super cool car cela permet permet d'éviter des moments de flottements en début de présentation et en fin de présentation et surtout d'accompagner les speakers qui sont pour la plupart un peu stressés avant de faire leur présentation.

Mon expérience MC à DevLille 2025

Loin de moi la prétention de rivaliser avec Laurent Laffite en Maitre de Cérémonie lors du Festival de Canne 2025, je me suis positionné en facilitateur discret pour faire que tout roule. J'ai eu la chance de pouvoir jouer ce rôle l'après midi du 2e jour dans le grand amphithéâtre .

Pour chaque présentation: 
- J'accueillais le speaker
- Je me présentais
- Je lui demandais comment ça allait
- je lui expliquais comment allait ce dérouler la chose
- J'essayais de trouver une petite idée que j'allais pouvoir utilisé lors du lancement en discutant avec lui
- 5' avant, je proposais au speaker et moi même de se mettre sur le côté pour pouvoir faire proprement "une entrée de star"
- au top, je rentrais sur scène, je salue l'audience, petite blague ou pas, je répète le titre de la présentation pour rassurer les spectateurs sur le fait qu'ils sont dans la bonne salle (ou pas justement) et je propose au spectateur d'accueillir chaleureusement le speaker. Je trouve très chouette que les speakers arrivent sur scène sous les applaudissements, c'est plus chaleureux
- au dernier slide du speaker, en général, c'est applaudissement. Je prenais un micro. c'était le moment de gérer les questions et la fin de session
- je courrais dans l'amphi apporter le micro
- une fois le temps de session écoulé, j'invitais les spectateurs à venir voir le speaker à côté de la salle s'ils ont d'autres questions
- Je proposais aux spectateurs d'applaudir une dernière fois le speaker ce qui terminait proprement la session
- petite pause et c'était reparti pour la prochaine présentation!
- Lezzzzzzz go again

J'ai trouvé ça très sympa à faire. Merci aux organisateurs de m'avoir fait confiance pour jouer ce rôle.

Et vous vous trouvez ça comment d'avoir des MCs à DevLille?

Tuesday, October 8, 2019

Cassandra : What to do when you run out of disk space?

Hi folks

In the first place, running out of disk space with a Cassandra cluster is not something you really want to experiment, trust me...
Caused by: java.io.IOException: No space left on device
I guess that if you're reading this post, you don't mind about this advice because it's too late though.

Why Cassandra need (so much) free space?

Under the hood, Cassandra works with internal processes which needs temporary disk space (up to the size it's already using...) such as : 
  • Running Compactions: As SSTables are immutable, Compactions are the processes which reorganize SSTables by recreating new SSTables and to do so, use space on disk.
  • Keeping Snapshots: a snapshot corresponds to a copy of SSTables at a certain point of time. Cassandra uses hard link to create the snapshots. Basically, taking a snapshot is not something that will increase the disk but over the time, keeping snapshots will increase the disk (because the snapshot files are not deleted).

What can you do?

First question is : Is it only one node or your entire cluster which is running out of disk space?

If it's only one node, you can follow the proposals below but sometimes it's easier to trash the node and to replace it with a fresh new node... Thanks to Cassandra and the way it distributes the data across a cluster, you should not end up with one node with (a lot) more data than the others.

If it's your entire cluster which is running out of disk space... Well... It's where the fun begins... I can't promise that you will not loose data...
Most of the actions that you can run on a node to reclaim spaces will start to increase a bit the disk usage...

Quick wins

  • Stop writing data into the cluster
It sounds a bit weird but yes, first of all let's stop the bleeding...
  • Clear Snapshots 
run on each node:
nodetool cfstats
nodetool listsnapshots
Theses commands will show you if you have any snapshots. If so they are good candidates to reclaim spaces and then to delete them: 
nodetool clearsnapshot
  • Increase the disk size of the nodes 
If you can temporary increase the disk size of your nodes, it's worth to do it to get back on a less critical state first. A state, where you can think of adding nodes and so on. If you're running your cluster on the cloud, most of the cloud provider provide ways to extend the disk. In most of cases you'll have to stop and start the VMs hosting your nodes.
  • Remove data (if you can...)
It can be a bit extreme as well but depending on your context and your use case it's perhaps possible...

You can drop or truncate tables. This solution is quite efficient because no tombstones are written. Cassandra just create a snapshot of the table when you run the command. The disk space is released when you clear the snapshot.

Not so quick win

  • Add nodes
This is the usual procedure... If your cluster needs more space, add more nodes...
Adding nodes means that the ownership data is changing between nodes. Cassandra does not automatically release the data which has been moved to other nodes. Do not forget to run a cleanup on each nodes:
nodetool cleanup
If you're still very limited in terms of available disk space, be careful because running a cleanup temporary increase the disk space. You can limit this increase by running the cleanup table per table :
nodetool cleanup yourkeyspace yourtable
  • Remove data (if you can...)
The other way to delete data by inserting tombstones in your cluster. To avoid to wait the gc_grace_seconds parameter before the tombstones will be evicted (by default it's 10 days), you can change the value by using the ALTER cql command. Before doing that check, check that old nodes are Up :
ALTER TABLE keyspace.yourtable WITH gc_grace_seconds = 3600

Best advice

If you survived to the issue, I'm pretty sure that you don't want to face it one more time. I would warmly recommend to monitor the disk usage of the nodes in your cluster. 

If you're using the SizeTieredCompactionStrategy (which is the worst regarding the needed free space) a good practice is to keep your disk usage below 50 to 60% and to add nodes before reaching the 70% threshold.

There's a currently an opened ticket to tackle this type of problem: 

Enjoy!

Friday, October 4, 2019

Cassandra Lan Party How-to

Hi Cassandra folks,

I would like to share with you my experience regarding the organization of a Cassandra Lan party.

<;-)>

It looks like I'm still the record holder of the biggest Cassandra Lan party organized with a 36 nodes cluster. I would be so happy if someone can beat this record!
</;-)>

I've already organized a bunch of Cassandra Lan party during conferences or meetups. If you want to have it done the right way and to avoid to loose time or just to fail, it's a bit of work and preparation...

Here's my How-to regarding the preparation and the run of a Cassandra Lan party. Feel free to use it or to just take a part of it! I know that this How-to works because i did it several times. It does not mean that you can't do it in another ways though.

Special thanks to friends who were already part of Cassandra Lan party organizations with me: 

The goal

The basic goal of a Cassandra Lan Party is: 
  • to create a network with the attendees' laptop
  • to create a Cassandra cluster on top of it. One node per attendee
  • to let attendees manipulate data of the cluster all together
  • to play with the cluster (like "oh s..., we lost one data center" and so on)
The ideal situation is also to be able to: 
  • setup a multi data center Cassandra cluster. 3DCs with a replication factor of 3 per DC
  • be isolated in terms of network

1. Preparation 

You need a Team:
  • 1 driver who displays slides
  • 1 team member per DC who:
    • knows the procedure
    • will be responsible of doing the network setup of the data center
    • will be a seed node with his own machine
    • will help the other attendees who are part of the data center

So basically, a team of 4 peoples if you want to simulate a 3 data centers clusters is an ideal setup.

You need network equipments :
  • 1 small switch (at least 4 ports)
  • 3 big switches (the bigger they are the more attendees you can get)
  • 3 RJ45 network cables at least 3 ou 5 meters long to connect switches togethers
  • as many as RJ45 network cables as you can for the attendees (a mix of 1m, 2m and 3m is perfect) 

You need additional equipments:
  • a luggage to carry everything in
  • flashy t-shirts, so attendees can identify the Cassandra Lan Party team easily
  • USB keys
  • few power strips
  • a scotch roller
  • sticky notes
  • few felt pens
I know that it's the most tricky part is to find the network equipments part. In my case, what I did was to ask some companies around me if they would lend me the network equipments by giving them a bit of visibility during the Lan Party and it worked fine... 

Also, regarding USB Keys, the goal is to load them with: 
  • JDK8 for all OS platforms
  • Python for windows
  • The Cassandra binary
If you don't have any USB Keys, you also have the option to distribute the archives thanks to the Cassandra Lan Party Configurator that the driver will run from his laptop once the network setup id done during the Cassandra Lan party (more details below).

In addition to that, You need: 
And that's it!


I would advice, if you can, to test the network equipment before the Cassandra Lan party D Day. You can also organize a repetition just with the team or with few close friends.  It enables to feel more relax for the D day.

If you can contact the attendees before the event, you can ask them :
  • to come with a laptop
  • install a JDK 8
  • yo come with a RJ45 adaptor for the laptop (like for the recent Mac for instance...)

2. Room preparation

To better picture the DCs physically, group tables to create 3 areas which will define your 3 DCs. One big switch per DC.

You can also spread sticky notes and pens on the tables.

Here is an example of a room setup i did for a repetition: 
Each table is a DC + the table at the back with the driver laptop which also display slides and the smaller switch.

3. Welcome attendees

Just few things about that : 
  • try to guide them to spread them across all the DCs. the Ideal situation is to have the same number of attendees per DC (or close to). You need to have at least 2 attendees per DC + the team member of the DC (the setup is using a RF of 3 per DC).
  • display a slide to kindly ask people to not touch anything. Regarding my experience, Attendees are sometimes quite excited to participate and want to go too fast. The idea is to go slow at the beginning to not fail the Cassandra Lan Party. 
  • distribute USB Keys
  • start the Cassandra lan Party with slides

4. Network Setup

The first thing is to ask attendees to switch off WIFI.

The goal is to create this network setup :

The small switch (WORLD) is connecting the 3 DCs (LILLE, SAN FRANCISCO and SINGAPORE) all together. The driver laptop is connected to the small switch and all the other attendees and team members are connected to a DC switch.

The Ip allocation is done manually to be able to control it.
As we will use the RackInferringSnitch of Cassandra to distribute the node across the DCs. IPs of Attendees have to look like: 
10.X.1.Y
where:
  • X corresponds to the number of the DC (in our case "1" for Lille, "2", for SF, ...)
  • Y is an incremental number given by the DC team member. "1" will be used for each DC team member
  • 10.1.1.0 will be for the driver laptop
For example for the Lille DC: 
  • 10.1.1.1 : DC team member
  • 10.1.1.2 : 1st DC attendee
  • 10.1.1.3 : 2nd DC attendee
  • ...
To avoid any issue and a big network mess, I would advice to use sticky notes to write each IP with the name of the attendee on the closest wall to the DC and also to control the plugging into the switch.


Once connected you can ask attendees to do the network configuration : 
  • IP : the one from the sticky note
  • network mask : 255.0.0.0
  • no proxy
  • no gateway
And then to ask them to ping: 
  • 10.1.1.0
  • 10.1.1.1
  • 10.2.1.1
  • 10.3.1.1

5. A bit of Cassandra theory

Usually, once the network setup is done or if there's one or two laptops causing issues, I would recommend to do a bit of Cassandra theory with few slides. How deep you need to go depends a bit on the experience of the attendees. Up to you to decide how far you want to go. The good thing is that it let a bit of time to try to solve network issues in the background.

6. Cassandra Setup 

Again, the first gentle reminder that you have ask to attendees is to not start Cassandra before the green light of the DC team member.

How to do the distributed setup : There's an app for that. 

The Cassandra Lan Party Configurator is a web application that will help attendees to do the setup of Cassandra on their machine. The goal is to let attendees to do the setup themselves but guided thanks to the application. The application is OSS and Apache licensed.
Main features are : 
  • attendees configuration helper
  • archives provider
  • cluster status









I would recommend to run the application from the driver laptop.

7. Cassandra cluster start

Once all attendees are done with the Cassandra setup, you can start nodes.

As we set the auto_bootstrap properties to false, it enables to accelerate the creation of the cluster. The drawback is that if an attendee is joining after the creation of the keyspace, he will have to remove the auto_bootstrap properties to join the cluster and to receive data.

First, start the seeds nodes which should correspond to each of the DC team member. Then, once the seeds nodes are there, you can let each of the DC team member adding nodes one after each other asking attendee to start his node.

8. Play with the Cassandra cluster

Once everyone is there, create a keyspace and one table so all attendees will be able to play with.
The important thing is to create the keyspace with the good strategy and using a RF of 3 per DC.

CREATE KEYSPACE "lanparty" WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', '1' : 3, '2' : 3, '3' : 3};
use lanparty;
CREATE TABLE attendee (
  email text primary key,  first_name text,  last_name text);


Then you can ask every attendees to play with CQLSH to insert and read data...

and The cool thing is that you can simulate DC connections issue by just unplugging the network cable of one DC Switch from the small switch.

I let your imagination do the rest...

Conclusion

I hope this How-to can help and I'm looking forward for feedback of new Cassandra Lan party!

As you have seen the network setup with switches and network cables is the biggest part of the Cassandra Lan Party. It's also a funny part because attendees really like this part of the setup.

I think that it could be possible to replace the 3 big switches and the network cables by 3 WIFI points.

Don't hesitate to contact me if you have any questions!

Jérémy

Monday, September 30, 2019

Cassandra : Compaction, compaction and compaction

Hi Folks,

The word "compaction" is heavily used in the Cassandra world. You can see it everywhere while reading documentation, blog post, mailing list and so on.

Sometimes the use of compaction in combination of another word can be a bit misleading. Let's try to take a step back and to sump up a bit all the different concepts where the word compaction is used:

Machine makes cars compact, Fig. 1

[Compaction]

Let's say the default one when you talk about Cassandra compaction. Cassandra has a write path which is very efficient. The concept is like "let's put as fast as possible the data into a file and in memory". In a second step, the data will be flushed on the disk as is. Ok but then, to enable Cassandra to also have an efficient read path, especially when you have to read a file from the disk, you need to tidy up and rearrange all the files. This process is called the compaction. A bit more technically : SSTTable are immutable and compaction is the action of generating new SSTable by merging and purging the old ones (duplicate, deleted data with expired ttl and tombstone).

Minor [Compaction]

We are still talking about the default compaction. The minor compaction is not really something which is minor.... The minor compaction is the compaction handled automatically by Cassandra as a background process and according to the chosen compaction strategy (see below).

Major [Compaction]

We are still talking about the default compaction mechanism in Cassandra. Contrary to the minor compaction, the major compaction is triggered by a manual action on a node (using nodetool compact). The major compaction can behave differently depending on the compaction strategy (see below). The other main difference between major and minor compaction and that explain the naming difference is that a major compaction has a bigger impact in terms of I/O.

[Compaction] Strategy

As already said, Compaction will merge into SSTables into new ones. Depending on you use case, Cassandra propose different strategies to compact the data new SSTables.  There is a default strategy applied if you do not specify it but you can choose the one you want per table. There are 3 main compaction strategies.

Size Tiered [Compaction] Strategy

This is the default compaction strategy. It fits for the write heavy and general workload. More documentation here:
http://cassandra.apache.org/doc/latest/operating/compaction.html#size-tiered-compaction-strategy

Leveled [Compaction] Strategy

This compaction strategy fits perfectly for read heavy workloads. This strategy involves a bit more I/O than the Size Tiered Compaction. It can be a good idea to combine that with SSDs. More documentation here:
http://cassandra.apache.org/doc/latest/operating/compaction.html#leveled-compaction-strategy

Time Window [Compaction] Strategy

This compaction strategy fits perfectly for time series. Basically the data is compacted regarding the timeMore documentation here:
http://cassandra.apache.org/doc/latest/operating/compaction.html#timewindowcompactionstrategy-operational-concerns

A good blog blog post which deep dive into it:
https://thelastpickle.com/blog/2016/12/08/TWCS-part1.html

Validation [Compaction]

This one is a fake friend from my point of view. It's considered as a compaction but is not really about compaction. The validation compaction is the process of building Merkle tree on nodes during a repair. It's anyway called validation compaction because this action is anyway controlled by the  

Anti[Compaction]

The anti compaction occurs during incremental repair. The goal is to split into two SSTables the repaired data from the unrepaired data. The 2 sets of data can no longer be compacted together and it's why it's called anticompaction.

Conclusion

Hopefully you get now a better vision of what means compaction regarding the context it's used into the Cassandra world.