OpenAI/Codex: Verschieben kritischer Infrastruktur von Perl nach Python

Digitaler Wandel wird oft auch als digitale Störung bezeichnet. Es ist schwer, größere technologische Veränderungen zu lokalisieren, die sich im Laufe der Jahre ereignet haben und keinen Schaden verursacht haben. Aber wie können Sie Ihren Technologie-Stack weiterentwickeln, wenn dieser potenzielle Schaden auch missionskritische Services umfassen könnte?

Dies war die Herausforderung für BAERO, das interne DevOps/Test-Infrastrukturteam von NetApp, das Tools und Services für Entwickler bereitstellt, mit denen sie ihren Code schreiben und testen können, bevor sie ihn abschicken. BAERO unterstützt Entwickler dabei, schneller zu arbeiten, Qualitätsprobleme so früh wie möglich zu erkennen und NetApp Produkte vor Rückschritten zu schützen. Im Laufe der Jahre haben wir eine große Menge Software zur Unterstützung dieser Mission entwickelt. Wenn NetApp jedoch neue Produkte und Funktionen hinzufügt, muss sich diese Software weiterentwickeln, um diese neuen Umgebungen zu unterstützen.

NetApp ONTAP ist jetzt zum Beispiel Bestandteil von Amazon FSx, aber um diese Funktion bereitzustellen, müssen ONTAP Entwickler neue Funktionen in AWS ausführen, testen und debuggen können, bevor sie veröffentlicht werden. Zur Unterstützung dieser Anforderungen erweiterte BAERO Services und Infrastruktur für die Arbeit mit Amazon FSx Im Allgemeinen gilt: je schneller BAERO Unterstützung leisten kann, desto eher können NetApp Entwickler Rückschritte in ihrem Code automatisch erkennen.

BAERO steht vor einer schwierigen Balance: Wir müssen schnell vorankommen, aber gleichzeitig können wir die Infrastruktur, die die NetApp Entwicklungsteams rund um die Uhr nutzen, nicht unterbrechen. Heute ist Infrastrukturcode von BAERO eine Mischung aus relativ neuem Python und kampferprobtem Perl-Code und Bibliotheken, die vor Jahren geschrieben, aber nach Bedarf erweitert wurden. Leider kann der Perl-Code die Unterstützung der neuen Funktionen und Produkte von NetApp erschweren, da Perls Bibliotheken-Ökosystem nicht so umfangriech ist wie das von Python, zudem wollen weniger Entwickler mit Perl arbeiten.

Mit Python können die Teams schneller agieren und die nächste Generation von NetApp Produkten besser unterstützen. Aber können wir unsere Perl-basierte Codebasis in Python übersetzen, ohne missionskritische Services zu unterbrechen?

Mit der Veröffentlichung von OpenAI/Codex im August 2021 wurde die Möglichkeit eingeführt, Code zwischen Sprachen mit künstlicher Intelligenz und maschinellem Lernen zu übersetzen. BAERO könnte damit seine Perl-Codebasis in Python zu übersetzen. Aber nicht alle Produkte erfüllen die Erwartungen; wir mussten sie testen, um es zu glauben. Würde Codex in realen Situationen standhalten? Könnte es unsere Codebasis schneller und einfacher übersetzen als eine Gruppe von Entwicklern? Der einzige Weg, um dies herauszufinden, war durch (hoffentlich fehlerfreies) Ausprobieren.

Für den Test haben wir „run_utest.pl“ ausgewählt, ein Dienstprogramm, das für die Durchführung von Unit-Tests und die Interpretation und Ausgabe von Ergebnissen genutzt wird. Es ist auch ein Skript, das sich über den ursprünglichen Entwurf hinaus weiterentwickelt hat. Der ursprüngliche Code wurde nach Bedarf erweitert, um Core-Dump-Analyse, Fuzzing-Unterstützung, Code-Coverage-Unterstützung oder On-the-Spot-Diagnose hinzuzufügen, wenn bestimmte seltene Fehler aufgetreten sind. Dadurch wurde es zu einem großen, komplizierten Perl-Skript, hinter dem Jahre realer Laufzeit steckten. Wir haben deshalb gezögert, damit zu experimentieren. Jede Übersetzung in eine neue Sprache musste auf eine Weise erfolgen, die die Richtigkeit des Skripts nicht gefährdete, denn das Skript setzt Qualität durch Ausführen von Unit-Tests durch und wird intern von jedem Entwickler verwendet, Hunderte Male am Tag. 

Bei unserer ersten Verwendung der Codex-Übersetzung wurde deutlich, dass Codex seine Vor- und Nachteile hat: Es war bei einigen Übersetzungen großartig, aber bei anderen sehr schlecht. Bei der Verwendung musste ein Entwickler als Zwischenschritt die korrekten Übersetzungen überprüfen und eventuelle Fehler ändern. Das heißt, es ist einfacher, ein neues Python-Skript zu validieren, als es komplett neu zu schreiben, was für ein vielversprechendes Ergebnis sorgte.

Im Wesentlichen ist Codex ein sehr schneller, aber nicht fehlerfreier Übersetzer. Wir mussten herausfinden, wie es sicher eingesetzt werden kann, um unser Übersetzungsprojekt zu beschleunigen. Als wir fertig waren, musste der übersetzte Code von Anfang an perfekt (oder fast perfekt) funktionieren. Da „run_utest.pl“ in einem normalen Build so stark verwendet wird, war es einfach, die „normalen“ Situationen zu validieren. Die vielen Ausnahmen und Fehlerpfade, die die Perl-Version verarbeitet (und die beim Schreiben validiert wurden), sind jedoch viel schwieriger. Sie müssen in der Python-Übersetzung funktionieren, wenn wir sie einsetzen. Es gibt keinen Raum für Fehler. 

Wir konzentrierten uns darauf, das Risiko in der neuen Python-Übersetzung zu reduzieren oder zu beseitigen. Im Idealfall hätten wir eine Reihe von Tests gehabt, die sowohl die Fehlerpfade als auch die Normalfall-Szenarien auf die Probe stellten. Leider gab es keine Sicherungstests für den ursprünglichen Code, und die Stabilität wurde durch manuelle Tests des neuen Codes und anschließende Überwachung auf Probleme nach der Bereitstellung neuer Versionen durchgesetzt. 

Wir sind das Übersetzungsrisiko wie folgt Weise angegangen.

• Direkte Übersetzung des Codes ohne Refaktorierung. Das erleichtert es Prüfern, zu überprüfen, ob der Code in beiden Sprachen dasselbe tut. Es ermöglicht auch die parallele Funktions- und Leistungsprüfung (auf Funktionsbasis).
• Übersetzung und Test nacheinander Stück für Stück, Prüfung und Einreichen. Der kleinere Prüfungsumfang erleichtert es den Prüfern, Probleme zu erkennen, und Entwickler können den langsamen, aber stetigen Fortschritt sehen. 
• Test des alten und neuen Codes mit den gleichen Eingaben. Da sich der neue Code genauso verhalten sollte wie der alte Code, wurden etwaige Unterschiede in der Ausgabe untersucht.
• Zahlreiche Unit-Tests. Wir konzentrierten uns auf das Ausprobieren jeder einzelnen Zeile Code. Es kann schwer sein, jeden Fehlerpfad natürlich zu treffen, aber mit dem umfangreichen Testvorgang von pytest konnten wir in vielen Fällen jede Zeile Code testen.

Am Ende erreichte die neue Version viel bessere Testergebnisse als das Original, und mit den Einzeltests aller Codes wurden viele Fehlerpfad-Übersetzungsprobleme aufgedeckt, die sich nicht in Normalfall-Szenarien zeigen.

Ab heute verfügt der Port über alle Funktionen und kann den gesamten Unit-Test-Workflow ausführen. Es wird weiter daran gearbeitet, die Unit-Testabdeckung (>80 % gegenüber 0 % zuvor) zu erhöhen, bevor sie bereitgestellt wird. Eine Überraschung war ein Fehler in der ursprünglichen Perl-Implementierung; der Perl-Code schluckt bestimmte Arten von Exit-Code. Das Problem verbirgt sich in der AKTUELLEN Unit-Test-Infrastruktur; es ist ein Problem, das ziemlich selten, aber real ist. Ursprünglich sah es wie ein Übersetzungsproblem aus, aber bei der Untersuchung war die Python-Version stringenter als die Perl-Version. Allein die Feststellung dieses Problems ist wahrscheinlich ein ausreichender Grund für das Übersetzungsprojekt.

Mit einer hohen Unit-Test-Abdeckung, gründlichen Integrationstests (parallel validiert mit Perl-Ausgabe) und vielen Ausführungswiederholungen haben wir die Python-Version von Run_utest für ~5 % der Unit-Test-Ziele implementiert.

Wir werden diese Zahl langsam erhöhen und auf 100 % umsteigen, nachdem wir Unit-Tests mit den durch die ursprüngliche Perl-Version von Run_utest versteckten Fehlern repariert haben.

Nach einer sehr positiven Erfahrung mit OpenAI/Codex sind wir zu vollem Einsatz bereit. OpenAI/Codex hat buchstäblich verändert, was wir für das BAERO-Entwicklungsteam für möglich halten. In der Vergangenheit hätten wir neue Projekte in Python geschrieben und dabei die Perl-Infrastruktur beibehalten, bis ein bestimmtes Stück unhaltbar geworden wäre ...und hätten das dann in Python neu geschrieben. Mit OpenAI/Codex in unserer Entwicklungs-Toolbox haben wir nun eine lange Liste von Infrastruktursoftware, die wir proaktiv übersetzen werden, und ein Konzept für den Erfolg des Projekts.

Fazit:

OpenAI/Codex hilft BAERO, schneller zu agieren.
OpenAI/Codex hilft den Entwicklern von NetApp, neue Funktionen schneller zu testen.
OpenAI/Codex unterstützt NetApp dabei, qualitativ hochwertigere Software schneller an unsere Kunden zu liefern. 

Perl->Python ist erst der Anfang. OpenAI/Codex hat das Potenzial, neue NetApp-Funktionen, Skalierbarkeit und Performance in den NetApp-Produkten freizusetzen und zu beschleunigen.

Obwohl OpenAI/Codex noch in den Startlöchern steht, sollten Sie schon bald damit beginnen, es auszuprobieren, und zwar hier. Durch das Risikomanagement mit den richtigen Tests/Prozessen kann OpenAI/Codex bereits jetzt die Übersetzung von Legacy-Code in neue Sprachen beschleunigen.