UCS Versionierung/Kompatibilität

[mss]

Moin,

ich arbeite gerade an der Paketierung von Zimbra für UCS. Die ursprüngliche monolithischen Pakete werde in der nächsten Version 8.7 in kleinere Pakete aufgeteilt und von einem eigenen Build-System für die unterstützten Betriebssysteme gebaut. So weit so gut.

Das Build-System vergibt für jede unterstützte OS-Versionskombination ein sog. Platform Tag. Z. B. UBUNTU14, UBUNTU12, RHEL7, etc. UCS wird jetzt als UCS4 erkannt. Hier stellt sich mir aber die Frage: Wie genau sieht die Versionierung von UCS aus, d. h. würde es evtl. mehr Sinn machen die Platform UCS41 (und UCS42, …) separat zu erkennen?

Zum Hintergrund wozu dieses Platform Tag u. A. verwendet wird:

[ul]
[li] Zum Generieren der Paketversionen damit sie im Pool eindeutig sind; ähnlich wie bei Ubuntu’s PPAs gibt es dann z. B. für Ubuntu 14.04 ein Paket zimbra-openjdk mit der Version 8u77b03.14.04; für UCS gäbe es die Version 8u77b03.ucs4 oder 8u77b03.14.04.ucs4.1[/li]
[li] Zum Generieren der richtigen Paketabhängigkeiten. Das beste Beispiel ist hier libperl für welches es kein Meta-Paket gibt und daher in Ubuntu 14.04 eine Abhängigkeit nach libperl5.18 benötigt wird während Ubuntu 16.04 mit libperl5.22 kommt. Und UCS 4.1 hat noch libperl5.14.[/li][/ul]

Kann ich also garantieren, dass ein Paket welches für UCS 4.x gebaut wird auf jeder Minor-Version installiert werden kann oder könnte es sein, dass das Paket libperl5.14 unter UCS 4.2 nicht mehr verfügbar ist? Wie ist hier das Kompatibilitätsversprechen?

In dem Zusammenhang auch die Frage: Das Build-System erkennt die Version bei Debian-Derivaten anhand der Ausgabe von lsb_release -s -c. Das ist bei UCS 4.1 der Wert Vahr. Kann ich mich darauf verlassen oder könnte 4.2 z. B. plötzlich Findorff heißen? Und andersrum: Wird ein potentielles UCS 5 definitiv nicht Vahr heißen?

Und zu guter letzt: Von welchem Debian ist UCS 4 eigentlich abgeleitet? Ich ging eigentlich von jessie aus aber libperl5.14 sieht mir eher nach wheezy aus.

Danke,
Malte Stretz

[gulden]

Moin Malte,

bei der Versionierung in UCS sollte bis auf Minor-Ebene unterschieden werden, also UCS 4.0, UCS 4.1 und UCS 4.2. Jedes Minor-Release hat seinen eigenen “Codename”, also z.B. “Vahr” und zu UCS 4.2 wird es ein neuer Codename sein. Es würde daher mehr Sinn machen für Zimbra die einzelnen Minor-Versionen zu unterscheiden.

Zur Debian Basis: UCS 4.0 und UCS 4.1 basieren auf Debian Wheezy. Die nächste UCS Version 4.2 wird auf Debian Jessie basieren. Damit sollte auch der Teil zum Hintergrund beantwortet sein, wie Zimbra die Tags verwendet.

Wie willst du Zimbra ins App Center bringen?

Seit UCS 4.1 integrieren wir Docker in das App Center. Der empfohlene Weg ist hierbei, die Software weiterhin als Debian Packages anzulieferen. Bei der Installation der App nimmt das App Center ein Docker Image, dass auf einem “abgespeckten” UCS in der Rolle des Memberservers basiert. Aus dem Image wird ein Docker-Container gestartet und anschließend wie Paketverwaltung die Pakete der App installiert. Das Vorgehen dazu ist auch im App Tutorial Kapitel 7 beschrieben.

Soweit ich deine Ausführungen interpretiere, geht es in die Richtung.

Weitere Szenarien wäre die Nutzung des UCS Basis Images für Docker und die Bereitstellung der Software via Dockerfile-Beschreibung oder aber auch die Anlieferung eines eigenen Docker-Images. Die App Jenkins ist beispielsweise das offizielle Image direkt von Docker-Hub.

Gruß, Nico.

[mss]

Hallo Nico,

bei der Versionierung in UCS sollte bis auf Minor-Ebene unterschieden werden, also UCS 4.0, UCS 4.1 und UCS 4.2. Jedes Minor-Release hat seinen eigenen “Codename”, also z.B. “Vahr” und zu UCS 4.2 wird es ein neuer Codename sein. Es würde daher mehr Sinn machen für Zimbra die einzelnen Minor-Versionen zu unterscheiden.

Ok, dann passe ich das entsprechend an.

Wie willst du Zimbra ins App Center bringen?

Seit UCS 4.1 integrieren wir Docker in das App Center. Der empfohlene Weg ist hierbei, die Software weiterhin als Debian Packages anzulieferen. Bei der Installation der App nimmt das App Center ein Docker Image, dass auf einem “abgespeckten” UCS in der Rolle des Memberservers basiert. Aus dem Image wird ein Docker-Container gestartet und anschließend wie Paketverwaltung die Pakete der App installiert. Das Vorgehen dazu ist auch im App Tutorial Kapitel 7 beschrieben.

Soweit ich deine Ausführungen interpretiere, geht es in die Richtung.

Ja, das war der Plan. Zumindest nachdem ich das besagte Tutorial gelesen hatte.

Weitere Szenarien wäre die Nutzung des UCS Basis Images für Docker und die Bereitstellung der Software via Dockerfile-Beschreibung oder aber auch die Anlieferung eines eigenen Docker-Images. Die App Jenkins ist beispielsweise das offizielle Image direkt von Docker-Hub.

Ok, wenn auch Nicht-UCS-Basissysteme möglich sind dann wäre evtl. einen Ubuntu-Container mit init als Basis eine Alternative da es dafür bereits sowohl offizielle Pakete gibt. Wobei das weder bezüglich des Supports seitens Ubuntu optimal wäre (das ubuntu-upstart Image ist deprecated) noch seitens Zimbra wirklich einen Unterschied zu UCS als Basis machen würde (Container werden derzeit nicht als Laufzeitumgebung unterstützt).

Ich werde erst mal dafür sorgen dass die Pakete unter UCS bauen, dann kann ich weiter sehen. Es fehlt prinzipiell nicht viel, am Aufwändigsten ist es die UCS-VM zu pflegen da es keine UCS Vagrant-Boxen gibt