Use Case für Snapshot in Jenkins Umgebung

[ReedyTT]

Hallo,

beim Hochziehen einer neuen Jenkins Umgebung habe ich das VSphere Cloud Plug-In im Einsatz welches zuverlässig läuft.
Der aktuelle use case sieht aus wie folgt:

- Jenkins Slave VM baut Quellcode
- checkt die Ergebnisse ins SVN ein
- VM wird auf letzten Snapshot zurückgesetzt
- und von vorn....
- ca. 30x pro Nacht

Soweit so gut, nur flogen mir früher regelmäßig Snapshots die älter als ein Monat sind um die Ohren Sodas ich die VMs clonen musste.
In meinem oben angezeigten Workflow werden die VMs immer auf denselben Snapshot zurückgesetzt. Also würde mich dann das Problem der zu alten Snapshots wieder einholen.
Trift das Problem hier nicht zu, weil ja regelmäßig auf den Snapshot zurückgesetzt wird? Oder muss ich mir was anderes einfallen lassen?

viele Grüße

[Dayworker]

Welchen Sinn hat das dauernde Zurücksetzen auf einen bestimmten Snapshot in deinem Workflow?

[rprengel]

Welchen Sinn hat das dauernde Zurücksetzen auf einen bestimmten Snapshot in deinem Workflow?

Wir machen ähnliches zum Softwaretesting allerdings ohne Snapshots. Sinn ist es immer einen definierten Ausgangszustand zu haben um vergleichbare Resultate zu bekommen.

Gruss

[ReedyTT]

Guten Morgen,

rprengel hat es schon gut beantwortet.

In einer Build Umgebung (BuildBot oder Jenkins..) ist dies der Standard Anwendungsfall.
Installer bauen > Installer testen > Ergebnisse einchecken und reset.

Die Frage wie halte ich meine Snapshots konsistent bleibt. Jedes Mal einen Clone erzeugen dauert zu viel zu lang, und auf EQL Ebene mit Smartcopys arbeiten, dafür habe ich noch kein Plug-In für Jenkins gefunden. Am Ende muss ich noch auf die CLI zurückgreifen -,-

[Dayworker]

Wenn du das Ergebnis eh in SVN eincheckst, kannst du doch völlig problemlos zwischen verschiedenen Versionsständen wechseln und spätestens wenn du 'svn update' laufen läßt, sind die letzten Änderungen auch wieder lokal vorhanden. Du kannst in SVN auch Trunks erstellen und diese dann ggf in den Master übernehmen.


Unabhängig davon können Snapshots aus mehreren Gründen Probleme verursachen. Jeder Snapshot kann je nach sich veränderter, geschriebener Datenmenge immer bis auf die Grösse der Basis-VMDK anwachsen und eine Snapshotkette muß immer vollständig intakt sein, da sonst Daten verloren gehen und die VM sich auch nicht mehr problemlos starten läßt.


Habt ihr euren Master-Snapshot eigentlich bei abgeschalteter VM erstellt oder lief diese?
In letzterem Fall wäre es in meinen Augen möglich, daß das Rückschreiben des RAM-Inhaltes je nach vRAM-Grösse und Storage-Performance länger dauert und ihr im Grunde zu früh die Arbeit in der VM wieder aufnehmt. Wie äussert sich denn euer Snapshot-Problem bzw mit welcher genauen Fehlermeldung wirst du bedacht? Den vSphere-/Web-Client auf die englische Oberfläche umzustellen, hilft dir bei der Fehleranalyse wesentlich weiter, da VMware immer noch auf eine 1:1-Übersetzung setzt und sich damit dann keine Suchmaschine sinnvoll befragen läßt.

[ReedyTT]

Wenn du das Ergebnis eh in SVN eincheckst, kannst du doch völlig problemlos zwischen verschiedenen Versionsständen wechseln und spätestens wenn du 'svn update' laufen läßt, sind die letzten Änderungen auch wieder lokal vorhanden. Du kannst in SVN auch Trunks erstellen und diese dann ggf in den Master übernehmen

Das siehst du komplett richtig. es ist hier ein wenig komplex da es extrem viele Anwendungsfälle bei uns gibt. zB. Entwickler Team A arbeitet mit einem Trunk und entwickelt an diesem weiter, Team B schaut "nur" wie die Ergebnisse aussehen usw.

Unabhängig davon können Snapshots aus mehreren Gründen Probleme verursachen. Jeder Snapshot kann je nach sich veränderter, geschriebener Datenmenge immer bis auf die Grösse der Basis-VMDK anwachsen und eine Snapshotkette muß immer vollständig intakt sein, da sonst Daten verloren gehen und die VM sich auch nicht mehr problemlos starten läßt.

Das beschriebene Problem dürfte bei uns nicht vorkommen, da es nicht wirklich viele Änderungen auf einer "Reset VM" gibt, bevor diese zurückgesetzt wird.
Auf der alten VirtualBox Umgebung von der wir umgezogen sind liefen über 600 Tests pro Monat. Die Snapshot Files, waren nie besonders groß.
Aktuelles Beispiel:
ResetVM2 auf der alten Umgebung hat heute bisher vier Tests durchgeführt, der fünfte läuft gerade.
*.vdi Größe 21 GB, Snapshot Größe 4,4. GB Test ist gleich durch. > Reset und von vorn.

Habt ihr euren Master-Snapshot eigentlich bei abgeschalteter VM erstellt oder lief diese?
In letzterem Fall wäre es in meinen Augen möglich, dass das Rückschreiben des RAM-Inhaltes je nach vRAM-Grösse und Storage-Performance länger dauert und ihr im Grunde zu früh die Arbeit in der VM wieder aufnehmt. Wie äussert sich denn euer Snapshot-Problem bzw mit welcher genauen Fehlermeldung wirst du bedacht? Den vSphere-/Web-Client auf die englische Oberfläche umzustellen, hilft dir bei der Fehleranalyse wesentlich weiter, da VMware immer noch auf eine 1:1-Übersetzung setzt und sich damit dann keine Suchmaschine sinnvoll befragen läßt.

Aktuell haben wir pro VM immer nur einen Snapshot (Master), den ich im ausgeschalteten Zustand erstellt habe. Das Zurücksetzten findet auch ausschließlich im ausgeschalteten Zustand statt. Sobald die Ergebnisse eingechekt sind, wird die VM abgeschossen und zurückgesetzt.

Das Grundproblem hatte ich bisher bei 2 Storage VMs(Samba), und einer ToolhostVM.
Bei den Storages bin ich mir sicher dass die Snapshot.vmdks durch viele Änderungen die maximale mögliche Größe erreicht hatten. Daraufhin hatte ich die Snapshots gelöscht. Hinterher bekam ich die Meldung bekommen "Datastores müssen konsolidiert werden" so das nur noch die Möglichkeit bestand VMs zu clonen...
irix war da eine gute Hilfe
Bei der ToolhostVM, bekam ich auch nach dem löschen einen Snapshots die Meldung "Datastores müssen konsolidiert werden", obwohl dieser nicht mal eine Woche alt war und kaum Änderungen vorhanden waren.

Das ist natürlich ein komplett anderer Sachverhalt nur habe ich ein schlechtes Bauchgefühl, nicht das mir nach dem 100sten zurücksetzten auf den Snapshot die ResetVMs um die Ohren fliegen.

Grüße

[Dayworker]

Snapshots werden ja immer im Thin-Format angelegt. In welchem Format wurde die Basis-VMDK angelegt?
Wenn die Basis-VMDK auch Thin angelegt wurde und bei der Erstellung nur wenig freier Platz auf dem Datastore war, könnte die VMDK auch einfach start fragmentiert sein.