Concept for Deployment and Rollout

---

General

Udo's General Thoughts

Auszug aus Udos Email vom 12.04.2016, 16:29 Uhr:

"Meine große Sorge in diesem Zusammenhang sind die Instantiierungs-Dateien.

Darin sind viele Dinge abgelegt, die beim bestehenden Kontrollsystem fest verdrahtet sind (wie Event-EQM Zuordnung) oder irgendwelche Default-Werte.

Für jeden Rechner (genauer: Jede Deploy-Unit) gibt es ein File, und darin sind viele Werte auch noch pro Device abgelegt (auch, wenn sie für alle Devices gleich sind). Wenn man die Software ändert, passiert es schnell, dass man alle Instantiierungs-Dateien anfassen muss, und wenn es dumm läuft, muss man (in jeder der vielen Dateien) für jedes Gerät einzeln eine Änderung machen.

Wenn ich mich richtig erinnere, muss man. auch, wenn man sonst nichts ändert, beim Upgrade auf eine neue FESA-Version zumindest die Versionsnummer im Instantiierungs-File ändern.

Schon für den CRYRING ist das kaum noch handhabbar: Bei den Netzgeräten sind es etwa 80 Devices in 17 SCUs (17 Instantiierungs-Dateien), mit 23 configuration-Einträgen sowie einigen weiteren Einträgen pro Device. Plus nochmal soviele Mock-Geraete (immerhin in nur einer Instantiierungs-Datei). Ich versuche mir vorzustellen, wie das bei tausend Netzgeräten wäre…

Vielleicht hat ja irgendwo irgendjemand irgendwann irgendeine Idee, wie man das vereinfachen könnte."

Deployment System Requirements

• Information
  • Was läuft wo in welcher Version?
• Automatisierung
  • Weitestgehende Automatisierung und Vereinfachung von sich wiederholenden Operationen
• Information: konkrete Operationen
  • DB Pflege
    • Einfügen von FESA Designs
    • Aktualisierung von FESA Designs
  • DB Nutzung
    • Abfrage von Daten aus der Datenbank
• Automatisierung: konkrete Operationen
  • FECs:
    • Anlegen von FEC Verzeichnisstruktur
    • Einrichten von relevanten NFS Initialisierungsskripten
  • Instanziierung von FESA Gerätesoftware:
    • Konfiguratonsmanagement
    • Aktualisieren von bestehenden FESA Instanziierungsdateien
    • Erzeugung von neuen FESA Instanziierungsdateien
  • Update von FESA Designs (Klasse, Deploy-Unit, Instanziierungsdatei)
    • FESA FWK Version
    • FESA Design Versionen
  • Release / Deployment / Rollout
    • Ausrollen von FESA Gerätesoftware fuer FECs (inkl. aller benötigten Konfigurationsdateien) für Test- und Produktionszwecke

Use Cases for Deployment and Configuration Management

Use Case for the FESA Class PowerSupply

Spezialfall, dieser gilt im Prinzip aber auch für andere FESA-Klassen.

Die FESA-Klasse PowerSupply ist besonders interessant:

• sie benutzt subsets (derzeit 7 subsets),
• sie läuft auf vielen SCUs (im CRYRING auf 19 Front-Ends plus einem für die Mocks) und
• es sind viele Geräte zu parametrisieren (im CRYRING etwa 80, plus 80 Mocks)

Da diese FESA-Klasse im CRYRING schon in einer umfangreichen Installation im Einsatz ist, kann man die Handhabbarkeit von Werkzeugen in der praktischen Anwendung gut beurteilen.

Typical Use Cases

1. Update auf neue FESA Version
   Die ganze Kette, von Anpassen des Klassendesigns (neue Versionsnummer, 'Update FESA Version') bis zum Deployment auf alle Front-Ends (inclusive Mocks)
2. Erweiterung Klassendesign (weiterer Parameter)
   Beispiel: In einer Property wird ein weiterer value-item definiert, der von einem configuration-Parameter im Instance-File versorgt wird wieder die ganze Kette, von der Erweiterung des Klassendesigns bis zu Erweiterung der Instance-Files (Mocks nicht vergessen) und dem Deployment auf die Front-Ends
3. Weiteren Front-End Rechner hinzufügen
   Beispiel: Im CRYRING ist eine weitere SCU für eine zusätzliches Netzgerät zu unterstützen (bekommen wir für die neue elektrostatische Linse hinter der RFQ) Die Kette von Definition des zusätzlichen Front-Ends ('Add FEC) und dem Einrichten auf dem Front-End selber, also SAFT-Lib Links etc, über Ausfüllen des Instance-Files bis zum Deployment auf die SCU, sowie Einrichten eines entsprechenden weiteren Mocks

Ich stelle mir dazu jeweils eine Liste der Aktionen vor, die durchgeführt werden müssen. Derzeit muss leider noch jeder Schritt einzeln explizit vom Entwickler durchgeführt werden.

Frage an die Experten: Habe ich in der folgenden Liste etwas falsch aufgelistet, insbesondere zuviel oder zu wenig?

Use Case 1, Update to new FESA Version for FESA Class PowerSupply

1. Aktualisieren des Designs:
1.1 Code der FESA-Klasse auschecken/aktualisieren
1.2 Versionsnummer im Design-File erhöhen
1.3 An neue FESA-Version anpassen 
    (Knopf 'Update FESA Version' drücken, Version auswählen)
1.4 Subset-Design erzeugen 
    (Knopf 'Create Subsets of original Class Design')
1.5 Für alle Subsets (jedes Subset einzeln) Design-File in Datenbank 
    exportieren:*
  1.5.1 erstes Subset Design-File in Datenbank exportieren 
        (Knopf 'Export FESA class or deploy-unit to the database ')*
  1.5.2 zweites Subset Design-File in Datenbank exportieren 
        (Knopf 'Export FESA class or deploy-unit to the database ')*
  1.5.3 drittes Subset Design-File in Datenbank exportieren 
        (Knopf 'Export FESA class or deploy-unit to the database ')*
    . . .
  1.5.7 siebtes (letztes) Subset Design-File in Datenbank exportieren 
        (Knopf 'Export FESA class or deploy-unit to the database ')*
1.6 Code synchronisieren (Knopf 'Synchronize Source Code')
1.7 Code übersetzen (make aufrufen)

2. Aktualisierung der Deploy-Unit:
2.1 Code der Deploy-Unit auschecken/aktualisieren
2.2 Versionsnummer im XML-File der Deploy-Unit erhöhen
2.3 An neue FESA-Version anpassen 
    (Knopf 'Update FESA Version' drücken, Version auswählen)
2.4 Subsets erzeugen 
    (Knopf 'Create Subsets of original Deploy-Unit Design')*
2.5 erzeugtes Subset Deploy-Unit Design in Datenbank exportieren 
    (Knopf 'Export FESA class or deploy-unit to the database ')
2.6 Code synchronisieren (Knopf 'Synchronize Source Code')
2.7 Binary bauen (make aufrufen)

3. Front-Ends aktualisieren (inclusive Mockup Instanziierungsdateiden)
3.1. ersten Front-End aktualisieren
  3.1.1 Instance File aktualisieren
    3.1.1.1 Versionsnummern anpassen
    3.1.1.2 Subsets erzeugen 
            (Knopf 'Create Subsets of original Class Design')*
    3.1.1.3 erzeugtes Subset Instance-File in Datenbank ablegen 
            (Knopf 'Export FESA instance to the database')*
  3.1.2 Release Binary (auf Front-End installieren, Knopf 'Release')
  3.1.3 Prüfen, ob Binary läuft
3.2. zweiten Front-End aktualisieren
  3.2.1 Instance File aktualisieren
    3.2.1.1 Versionsnummern anpassen
    3.2.1.2 Subsets erzeugen 
            (Knopf 'Create Subsets of original Class Design')*
    3.2.1.3 erzeugtes Subset Instance-File in Datenbank ablegen 
            (Knopf 'Export FESA instance to the database')*
  3.2.2 Release Binary (auf Front-End installieren, 
        Knopf 'Release')
  3.2.3 Prüfen, ob Binary läuft
   . . .
3.19. letzten Front-End aktualisieren
  3.19.1 Instance File aktualisieren
    3.19.1.1 Versionsnummern anpassen
    3.19.1.2 Subsets erzeugen 
             (Knopf 'Create Subsets of original Class Design')*
    3.19.1.3 erzeugtes Subset Instance-File in Datenbank ablegen 
             (Knopf 'Export FESA instance to the database')*
  3.19.2 Release Binary (auf Front-End installieren, Knopf 'Release')
  3.19.3 Prüfen, ob Binary läuft

4. Code wieder in svn sichern (wenn die Front-Ends laufen)
4.1 Projekt FESA-Klasse einchecken
4.2 Projekt Deploy-Unit einchecken

* Schritt entfällt für FESA Software ohne Subsets. Stattdessen wird das jeweilige Design der FESA Klasse / Deploy-Unit / Instanziierungsdatei in die Datenbank eingefügt.

Weitere Spezialfälle:

• FESA Class Composition
• FESA Class Association

Bei den beiden genannten Spezialfällen müssen beim Updaten / Code Synchronisieren / DB pflegen / Erstellen die Abhängigkeiten zwischen den FESA Klassen beachtet werden.

Zu beachten: die jeweilige Treibersoftware wie FESL sollte beim Erstellen der Software mit berücksichtigt werden.

Use Case 2, Extension of a Class Design

Weitgehend wie Use Case 1, lediglich:

Änderung:
  1.3 An neue FESA-Version anpassen -> Designfile ändern
      entfällt:
  2.3 An neue FESA-Version anpassen neu dazu:
    3.1.1.1.a Einträge im ersten Instance-File anpassen
              Knopf 'Promote Instances'
    . . .
    3.19.1.1.a Einträge im letzten Instance-File anpassen
               Knopf 'Promote Instances'

Use Case 3, Add another Frontend Controller

• asl cluster: benötigte NFS-Verzeichnisse und Initialisierungsskripte anlegen, z.B. mit Skript 'prepfesaenv'
• FESA
  • neuen FEC anlegen
  • deploy-unit Code Synchronisierung
  • neue Instanziierungsdatei anlegen und editieren
  • ggfs. mockup Instanziierungsdatei erzeugen
  • FESA Software ausrollen für den neuen FEC
• FEC
  • als 'root' anmelden und
  • FEC Neustart ausführen oder
  • NFS Initialisierungsskript erneut ausführen

Open Items / to be clarified

• Sinnvolle Verknüpfung von Informationen in DB mit Automatisierungsskripten für Update / Build / Deployment?
• Sammlung von FESA Software an zentraler Stelle zum Ausrollen von dort? (Backup inklusive)
• Datenbankpflege? Wie wird sicher gestellt dass DB aktuellste Informationen enthält? --> FESA Workflow!
• Falls eine Datenbank als Grundlage für die Konfiguration von FECs verwendet wird wird Extraktion von FESA Instanziierungsdateien interessant - diese können dann aber auch ausschliesslich vom Deployment System beim Aufsetzen der FECs verteilt werden!?
• ...

Feature Wishlist

• Automatisches Backup von ausgerollter Software
• Rollback: Wiederherstellung von früheren Softwareständen (auf FEC / in DB)
• ...

Ideas for Release of FESA deploy-units

Use Cases for Gathering and Displaying Information

General

• Soll man Scripts bevorzugen gegenüber GUIs? Scripts sind jedenfalls schneller zu implementieren und einfacher anzupassen.
  Trotzdem die Frage: Was gibt es schon (beim CERN), das das eine oder andere Script überflüssig machen könnte?
• Es sind einige Beispiele aus dem altem System angeführt, um ein Gefühl zu bekommen, was so an Info zurückkommen und dargestellt werden könnte. Weil es einfacher ist, habe ich die alten Scriptnamen auch für das neue System benutzt.
• Wichtig! Es müssen aktuelle Informationen dargestellt werden. Infos aus Datenbanken oder sonst woher, die nicht der Realität "im FEC" entsprechen, führen nur zur Verwirrung.
  • Datenbanken können dann OK sein, wenn bei Änderungen an den Front-Ends zuverlässig auch die Datenbank-Einträge aktualisiert werden.

Use Case 1 - FESA Class Infos

Zeige mir alle Rechner, auf denen die FESA-Klasse PowerSupply läuft.

Als Eingabe wird der Name einer FESA-Klasse erwartet.

Hier, wie sowas im alten System für das Gerätemodell MX aussieht:

  asl733$ eqp-software MX
  ...looking for 370 PPC-GuPs, uIOCs, and SEs
  K1XCG03     G       |DMAN10.26.06|DeviceAccess|MX  10.00.05|
  K1XCS031    F  (R3) |10.05  Mar16|CMIL10.26   |MX  10.00.05|Pm HSI Quad |
  K1XCS034    F  (R2) |10.05  Mar16|CMIL10.26   |MX  10.00.05|Pm UNI Post |
  ...
  KG1CG01     G       |DMAN10.26.06|DeviceAccess|MX  10.00.05|
  KG1CS017    G  (R9) |10.05  Mar16|CMIL10.26   |MX  10.00.05|Prm HTM E 24|
  KG1CS018    G  (R9) |10.05  Mar16|CMIL10.26   |MX  10.00.05|Perm SIS Deg|
  KG1CS019    G  (R9) |10.05  Mar16|CMIL10.26   |MX  10.00.05|Spillabbruch|
  ...

Man sieht GuPs und SEs, pro Zeile ein Rechner. Im neuen System gibt es nur noch FECs (SCU, MEN, asl33x, ...), womit alle Rechner gemeint sind, auf denen FESA-Klassen laufen (können).

MX könnte z.B. in Zukunft die FESA-Klasse PowerSupply sein. Welche Informationen könnten ausgegeben werden?

• Name des FECs
• Typ des FECs (SCU, MEN, ...)
• Version FESA Core
• Name der FESA-Klasse
• Name des Subsets der FESA-Klasse (falls vorhanden)
• Version der FESA-Klasse
• Version der SAFT-Lib
• Name eines Treibers (falls vorhanden) (1)
• Version dieses Treibers (falls vorhanden) (1)
• Name eines weiteren Treibers (falls vorhanden) (1)
• Version dieses Treibers (falls vorhanden) (1)
• ... (was noch?)

(1) Nur Treiber, die zusätzlich für diese FESA-Klasse benötigt werden.

Im alten System kann man für das Gerätemodell auch '*' angeben. Dann bekommt man eine lange Liste aller Rechner mit jeweils allen darauf laufenden Gerätemodellen.

Informationen, die z.Zt. (05/2016) nicht in der FESA-DB stehen:

• Version der verwendeten timing Bibliothek, z.Zt. SAFTlib
• Typ des FECs, OS Version des FECs, OS Name des FECs
• Name/Version des verwendeten Treibers, z.B. FESL
• Ob es sich um ein Subset handelt

Skript: fesa-class-info <FESA Klassenname*> bzw. class-info.py <FESA Klassenname*>

Use Case 1b) - FESA Deploy-Unit Infos

Analog Use Case 1, jedoch fuer FESA Deploy-Units.

Skript: fesa-deploy-unit-info <FESA Deploy-Unit Name*> bzw. deploy-unit-info.py <FESA Deploy-Unit Name*>

Use Case 2 - Specific FESA Class Infos

Zeige mir alle Rechner, auf denen FESA-Klassen laufen, die mit der FESA-Core-Version 47.11 gelinkt sind.

Das könnte man mit 'eqp-software' (siehe Use Case 1) erschlagen, etwa so:

  eqp-software --core-version=47.11 "*"

Auch jede andere Info, die 'eqp-software' ausgibt, könnte man im Prinzip so herausfiltern.

Skript: fesa-class-info <FESA Klassenname*> <FESA Version> / class-info.py <FESA Klassenname*> <FESA Version>

Use Case 2b) - Specific FESA Deploy-Unit Infos

Analog Use Case 2, jedoch fuer FESA Deploy-Units.

Skript: fesa-deploy-unit-info <FESA Deploy-Unit Name*> <FESA Version> bzw. deploy-unit-info.py <FESA Deploy-Unit Name*> <FESA Version>

Use Case 3 - Device Infos

Zeige mir Geräte-Informationen des Gerätes mit der Nomenklatur ABC, oder der Geräte deren Nomenklatur dem Muster ?XY*Z entsprechen.

Als Eingabe wird der Name eines Gerätes erwartet, wobei Wildcards im Namen erlaubt sind.

Das sieht im alten System z.B. so aus:

  asl733$ devdesc GTK5QT5*

              Dev.  Equip.-Model
  Nomen       Addr  Name     Num  DevMan    EC        Host
  ----------  ----  -------  ---  --------  --------  -------------------
  GTK5QT51      81    MX_22   19  KUECG02   KUECS027  kuecg02.acc.gsi.de
  GTK5QT52      82    MX_22   19  KUECG02   KUECS027  kuecg02.acc.gsi.de
  GTK5QT53      83    MX_22   19  KUECG02   KUECS024  kuecg02.acc.gsi.de

Hier werden keine Versionen angezeigt. Im neuen System könnte man z.B. noch den Namen des Subsets der FESA-Klasse anzeigen.

Device Info (FESA Software)

Mindestens angezeigt werden koennen:

• device name
• FEC name (host)
• FESA deploy-unit name / version
• FESA class name
• FESA class version
• FESA FWK version (release)
• multiplexed
• timing domain
• accelerator
• accelerator zone
• description

Skript: fesa-device-info <FESA device name*> / device-info.py <FESA device name*>

Use Case 4 - FEC Software Infos

Zeige mir die Software (FESA-Core, -Klassen, Treiber, ...) und deren Versionen, die auf dem Rechner ABC laufen.

Als Eingabe wird der Name eines FECs erwartet.

Im alten System ist das ein eigenständiges Skript (vme-software). Man verwendet nicht das obige 'eqp-software'.

Im neuen System könnte man sich überlegen, ob ein Script beide Aufgaben übernimmt. Der Output ist im Wesentlichen ja der gleiche.

Oder aber 'eqp-software' liefert eher einen Überblick, also nur die wichtigsten Infos, 'vme-software' dagegen ausführliche Infos, z.B. auch die Linux-Version des FECs und solche Sachen.

Zu bedenken ist auch, dass auf einem FEC mehr als eine FESA-Klasse laufen kann. Die müssen alle ausgegeben werden. Das legt wohl eher ein eigenständiges Script für diesen Use Case nahe.

Im alten System ist hier keine Wildcard '*' möglich.

FEC Info (FESA Software)

Mindestens angezeigt werden koennen:

• FEC name
• device names
• FESA class name / version
• deploy-unit name /version
• Multiplexing
• Timing Zone
• Accelerator / Accelerator Zone
• description
• FEC status (Netzwerk ping)

Informationen, die z.Zt. (05/2016) nicht in der FESA-DB stehen:

• Version der verwendeten timing Bibliothek, z.Zt. SAFTlib
• Typ des FECs, OS Version des FECs, OS Name des FECs
• Name/Version des verwendeten Treibers, z.B. FESL

Skript: fesa-fec-info <FEC Name*> / fec-info.py <FEC Name*>

Use Case 5 - FEC Device Infos

Zeige mir alle Geräte, die auf dem FEC 'scu123' laufen.

Als Eingabe wird der Name eines FECs erwartet. Wildcards sind hier nicht erlaubt.

Das sieht im alten System z.B. so aus:

  asl733$ ecconfig KUECS024

  ...

  Log  IFB                   Support  Active             Therapy   Master      Slave       Therapy
  Dev  Address   Device      Status   State   Workmode   Lock      Error Cnt   Error Cnt   Mem.Offset
  ---  --------  ----------  -------  ------  ---------  --------  ----------  ----------  ----------
    0   98/0x62  GTK5QT62    online   0xFFFF  normal     unlocked           0           0  0x00000000
    1   99/0x63  GTK5QT63    online   0xFFFF  normal     unlocked           0           0  0x00000000
    2  113/0x71  GTK5QT71    online   0xFFFF  normal     unlocked           0           0  0x00000000
    3  114/0x72  GTK5QT72    online   0xFFFF  normal     unlocked           0           0  0x00000000
    4   97/0x61  GTK5QT61    online   0xFFFF  normal     unlocked           0           0  0x00000000
    5   83/0x53  GTK5QT53    online   0xFFFF  normal     unlocked           0           0  0x00000000

Output sind bzw. sollten sein allgemeine Informationen zu den Geräten wie

• Name
• Geräteadresse,
• online/offline/... -> diese Information kann nur bei Geraet selbst abgefragt werden, z.B. durch Aufruf einer lesenden Property
• ...???

Skript: fesa-fec-device-info.py <FEC Name> / fec-device-info.py <FEC Name>

FEC Device Info (FESA Software)

Mindestens angezeigt werden koennen:

• device name
• FEC name (host)
• FESA deploy-unit name
• FESA class name
• FESA class version
• FESA FWK version (release)
• multiplexed
• timing domain
• accelerator
• description
• accelerator zone

Skript: fesa-fec-device-info.py <FEC Name> / fec-device-info.py <FEC Name>

FEC Nomenclatures

Anforderung: Der Name der SCU sollte den Einbauort reflektieren.

Siehe dazu Kapitel "5.4 Computer" in System for Nomenclatures of Accelerator Devices at FAIR & GSI.

Wie nennen wir einen FEC genau? Wie heisst z.B. die SCU, die im Netzgerät von YRT1MH1 steckt?

  YRT1MH1 -> YRT1CUS01
  YRT1MV1 -> YRT1CUS02
  YRT1MH2 -> YRT1CUS03
  YRT1MV2 -> YRT1CUS04

  YRT2MH1 -> YRT2CUS01

xxxxCUSnn ist eine SCU. Die SCUs werden innerhalb der "ersten vier Buchstaben" der Nomenklatur durchnummeriert.

Am Namen eines FECs kann man also nur dessen Standort erkennen, aber nicht, in welchem NG (Netzgerät) oder allgemein in welcher Elektronik er steckt.

Eine Idee wäre, die Durchnummerierung entlang der Beamline zu machen, also

erstes Gerät in der Section	xxxxSCU01
zweites Gerät in der Section	xxxxSCU02
n-tes Gerät in der Section	xxxxSCUnn

Das bedeutet aber eine Umsortierung der FEC-Nomenklaturen, wenn ein neues Gerät mit SCU mitten in der Section dazu kommt. Das Gerät xxxxQD71, das in der Section nach dem neuen Gerät kommt, hätte dann plötzlich nicht mehr die SCU xxxxSCU13 sondern die SCU xxxxSCU14. Ist sicher nicht so schön!

---

Presentations

19.04.2016: ErsteIdeen_.pdf

26.04.2016: AnsatzBuild+Deployment.pdf

23.05.2017: Deployment-Release-FESAsoftware.pdf