Apache CMS Rétrospective
Joe SchaeferLe CMS Apache — inventé en octobre 2010 par certains membres de l’équipe d’infrastructure Apache (Paul Querna (VP), Daniel Shahaf, Ph.D. (SVN dev), et moi-même, officiellement déconseillé en juin 2015et enfin mis hors service en janvier 2022 — Il était toujours en avance sur son temps. À son apogée, plus de 100 projets de premier niveau Apache et plus de 4K utilisateurs s’y sont fiés, mais pas plus qu’Apache OpenOffice. Jamais sa technologie de performance prémonitoire n’a été plus clairement mise en évidence que dans sa fonctionnalité de gestion de la dépendance au contenu au cours des premières années du don d’Oracle de OpenOffice à Apache en juin 2011.
Pour être clair : lorsque d’autres parlent de la gestion des dépendances, ils sont principalement concernés par les dépendances logicielles, pas dépendances de contenu. Tout se résume à un contenu bien réglementé “inclut” dans le système templating+build, ce qui n’est pas du tout la même chose que les services logiciels.
Cette fonctionnalité était absolument essentielle pour soutenir l’énorme https://OpenOffice.org (OOo) site Web. Le CMS Sun du SGBDR fourni à l’origine à OOo tomberait et disparaîtrait même si vous vouliez simplement corriger une faute de frappe. En revanche, The Apache CMS a couru sur une prison de FreeBSD sur baldr.apache.org : un moyennement provisionné, Boîte Dell 1950 fonctionnant avec 8 CPU et 24 Go de RAM avec une paire de disques durs en miroir de 96 Go à travers plusieurs prisons, et a parcouru le flux de travail avec une relative facilité.
Sans un service de type CMS collant qui peut amener un contributeur à une session d’édition pour la page qu’il souhaite réparer EN UN CLIQUETTE UNIQUE, l’énergie cognitive est beaucoup trop grande pour corriger une faute de frappe sur une page web aujourd’hui :
- aller pêcher cette page d’un repo github,
- fourche le repo,
- modifier la page,
- valider la modification,
- le pousser,
- créer un PR,
- attendez qu’un validateur approuve et fusionne le PR,
- attendre 10 à 15 minutes pour que le build intermédiaire se termine pendant qu’il broie tous les 40K+ de ressources pouvant être créées (taille totale de ~4 Go),
- attendez qu’un validateur trouve et vérifie le contenu modifié publié quelque part sur site intermédiaire,
- attendez que ce validateur promeuve le site entier en production,
- attendre 5 à 10 minutes supplémentaires avant la fin du build de publication,
- attendez que gitpubsub transfère le nouveau contenu vers les serveurs Web périphériques d’Apache.
Avec l’Apache CMS (webgui), partagez un committable “patch/diff” over email était une opération en un clic pour toute personne sur Terre, ainsi qu’une opération en un clic pour commit+build+publish pour un committer à appliquer sur le projet. Le tout tournait autour du partage d’URL de capacité dans le contexte d’un éditeur Markdown en direct avec des aperçus HTML instantanés à double volet. Ils ont permis à un commissionnaire Apache sur le projet de “clonage” le système de fichiers zfs hébergé par baldr-jail du paiement (non validé) dʼun contributeur ; puis inspecter, modifier et valider ce paiement cloné par le validateur Apache lui-même en tant que validateur et non contributeur. Une fois cette validation effectuée, le CMS l’a non seulement créée en secondes (puisqu’il ne construit que les fichiers modifiés et leur poignée de fichiers dépendants), mais il a également fourni des liens au build et au rendu en direct du contenu sur le site intermédiaire pour révision avant la promotion à la production.
L’ensemble du brevet Amazon en un clic était essentiel à la satisfaction du client pour eux. Même chose ici, mais le CMS Apache était tout seul dans cet espace.
Le CMS Apache (webgui) était ce tableau de coordination essentiel entre toute cette énergie bénévole qui a malheureusement laissé l’organisation derrière elle.
Il y a plusieurs excuses faites par Apache pour expliquer pourquoi il a été abandonné :
un facteur bus de 1 (me),
suppression progressive de FreeBSD (OpenZFS fonctionne sur Ubuntu),
buggy (clones zfs peu fiables d’une minuscule prison de FreeBSD),
laide (merci, riche !),
C’est mieux (merci Greg !)
Mais le véritable motif était spite. Entre le moment où il a été abandonné en mars 2015 et le moment où il a finalement été mis hors service en janvier 2022, il fonctionnait en pilote automatique dans une prison FreeBSD sur baldr.apache.org depuis près de 7 ans. La seule maintenance requise était (trimestriellement ?) la réinitialisation de l’hôte en raison de l’article 4 ci-dessus et le renouvellement annuel du certificat SSL. C’est ça l’informatique.
À la fin de 2021, j’ai proposé à Dave Fisher d’héberger le site Web OpenOffice sur Orion à un rabais élevé. Au début, Dave a demandé au conseil d’administration et ils ont approuvé la dépense. Dave a proposé à l’ASF de renoncer aux frais de recherche que j’ai accepté de lui payer et m’a dit de mettre cet argent aux frais d’hébergement.
Ce qui s’est passé ensuite a été vraiment remarquable : l’équipe d’infrastructure d’Apache, immédiatement et de manière persistante sur une période de semaines, a mis Dave dans la position peu enviable de déclarer ses loyautés maintenant exclusives, selon eux : pour moi et par extension la communauté de bénévoles du projet, ou à The ASF.
Dave était le principal innovateur et collaborateur derrière les succès de l’évolutivité de la technologie de construction incrémentielle d’Apache CMS. Il n’a pas inventé les solutions ; mais il a travaillé de manière productive avec moi sur la façon dont j’ai ajouté les fonctionnalités d’évolutivité dont il avait besoin pour assurer des builds de haute performance à partir du CMS Apache tel qu’appliqué au site Web OpenOffice - qui à l’époque livrait au nord des demandes 25M par jour ! Ensemble, nous avons découvert une application profonde de SSI dans ses efforts, qui, je crois, sont toujours poursuivis dans le système de tentation JBake utilisé aujourd’hui.
Malheureusement, si vous regardez l’édition de contenu en cours avec le site Web d’OpenOffice sur GitHub récemment, vous pouvez clairement voir une baisse massive de l’activité lorsque l’équipe d’infrastructure d’Apache a forcé Dave à les déplacer hors du CMS d’Apache, et par conséquent canalisé toutes les activités de contribution via GitHub seul.
Je ne blâme pas Dave pour le choix laid qu’il a été forcé de faire, ni pour le résultat prédéterminé, mais nous ne sommes évidemment plus en termes de discours depuis ce jour-là.
Ce qui est choquant dans toute l’affaire, c’est la belligérance absolue de l’équipe d’infrastructure d’Apache sur tout l’effort. J’ai personnellement tenu la main de chaque projet que nous avons embarqué à la CMS d’Apache ; voir toute la bonne volonté qui a créé brûlé au sol par décret autocratique était tout simplement insondable pour moi en tant que membre de longue date de l’organisation.
Tout ce qu’ils ont fait, c’est donner aux projets Apache échoués des ultimatums impitoyables, et jamais une seule heure d’effort dédiée à leur départ personnel pour tout le reste. Ce n’était pas différent avec OOo ; ils ont simplement abusé, brouillé et contraint Dave à faire leurs enchères. Et il l’a fait.
Je démissionnais en 2018. Je n’ai pas pu continuer à le voir. Ce que j’ai fait à la place en 2020 a été construit Orion des cendres. Mais même cette avenue a été exclue pour les projets Apache par l’équipe d’infrastructure Apache.
Tout pour spite.
Triste.
Mais pas vaincu. J’ai versé toute cette énergie dans la construction Orion dans une solution incomparable, axée sur la sécurité et conçue pour le monde entier KMS. Vérifiez-le si vous en avez assez d’avoir vos secrets d’entreprise volés par script-kiddies ; vous allez adorer !