Bonjour à tous. Dur dur d’alimenter ce blog au quotidien en ce moment, je ne vous le cache pas. J’ai pas mal de billets en préparation, mais la morosité ambiante doublée d’un télétravail assez usant ont en général raison de ma motivation à avancer, le soir ou le week-end. Pour autant, un petit sursaut ce matin lors de la réception d’un nième échange avec l’engineering de VMware ont déclenché un mini Rognotudju … que je me propose de vous relater. Restons légers, prenons un peu de hauteur pour une fois et faisons ce que les Français adorent : plaignons-nous !

Un peu de contexte pour commencer. Je travaille beaucoup en ce moment avec VMware et Axians Cloud Builder, notre partenaire historique, sur notre feuille de route stratégique des 3 prochaines années (un billet est en préparation, dès que tout sera confirmé définitivement) sur les technologies de notre cher éditeur de solutions de virtualisation. Cette feuille de route nous amène à prévoir, notamment, d’étendre encore plus le périmètre production de la technologie NSX-T. Sauf que, parallèlement à cela, et ce, depuis quasi une année maintenant, on se traine un bug pénible sur la fonction DNAT (à lire ici). Pour ne rien arranger, ce problème a empiré depuis notre upgrade en 3.0.2 il y a quelques semaine. Précisons également qu’il était sensé être carrément corrigé sur cette version majeure …

Vous imaginez donc facilement la gymnastique intellectuelle que je dois faire en gardant la tête froide d’une part pour se projeter à 3 ans AVEC NSX-T comme un des fondamentaux stratégiques chez nous … et de l’autre, commencer à être vraiment en mode Rognotudju avec ce foutu bug qui nous empoisonnent la vie. Depuis la v3, le correctif appliqué pour contourner le sous (un changement de paramètre dynamique à placer sur chaque edge-node) ne tiens même plus dans la durée et saute en moyenne une fois par semaine ! Enfin, pour couronner le temps, ce bug est lié depuis le début à une “optimisation” que nous désactivons pour que tout rentre dans l’ordre … une petite boite à cocher suffirait sans doute à stabiliser au moins la situation sans forcément dégrader globalement les performances de routage de NSX et permettrait juste de cibler uniquement les clients qui sont contraints et forcés d’utiliser au prix d’une perte de performance très acceptable (pour notre cas, quasiment invisible).

Mais ROGNOTDJU quoi ! Qu’est-ce que je réponds ensuite à toutes les personnes extérieures qui me sollicitent sur un REX de notre choix NSX-T depuis désormais plus de 2 ans et demi ? Bon j’avoue, le bug en question n’est pas très critique pour le moment car n’impacte que certaines fonctions mineures de notre SI, mais tout de même, il pourrait être beaucoup plus handicapant dans un contexte prod différent !

Alors, messieurs de VMware, s’il vout plait, CORRIGEZ-MOI CE BUG ROGNOTUDJU !