Versionierung des Baukasten

[stefanschoeberl-scch]

No description provided.

[stefanschoeberl-scch]

Umsetzung mit kubevela

Revisionen von Definitions können gepinnt werden (siehe https://kubevela.io/docs/platform-engineers/x-def-version#specifing-a-specific-definition-revision-in-an-application), jedoch werden im Fall, wie in der Doku beschrieben wird, die Revisionsnummern von kubevela einfach raufgezählt (geschieht bei vela def apply <definition>.cue).

Es kann der Revisionsname explizit in der Komponente angegeben werden, zB:

<definition>: {
	...
	annotations: {
		"definitionrevision.oam.dev/name": "1.0"
	}
	...
}
...

Auf diesen kann in der Application referenziert werden: type: <definition>@v1.0

Allgemein wird in der Application nach folgendem Schema darauf referenziert: <definition>@v<definitionName>

Anmerkung: Der Revisionsname darf ein beliebiger String sein, er muss nicht gemäß Semver oder einem anderen Schema aufgebaut sein.

Interessante Beobachtungen

"Überschreiben" von Revisionen führt zu einem Fehler

Ausgangssituation: Zwei Komponenten mit demselben Namen und gleichem Revisionsnamen, aber mit unterschiedlichem Template, liegen als cue-Files (definition.cue, definition-modified.cue) vor.

1. vela def apply definition.cue => funktioniert
2. vela def apply definition-modified.cue => Fehler: Error: failed to update existing definition in kubernetes: admission webhook "validating.core.oam-dev.v1beta1.componentdefinitions" denied the request: the definition's spec is different with existing definitionRevision's spec

Erkennnisse

• Verhalten ist nachvollziehbar und sinnvoll, um Fehler und unbeabsichtigte Änderungen auf "gepinnte" Komponenten zu verhindern
• Nicht während der aktiven Entwicklung von Komponenten zu gebrauchen, da manuelles Raufzählen des Revisionsnamen lästig ist
• Sinnvoller Anwendungsbereich: "Zum (zukünftigen) Zeitpunkt X sind die Komponenten des Baukasten ausgereift genug, dann macht es sinn, die Versionen zu pinnen und in den Cluster einzuspielen"

Zurückkehren zum automatischen Inkrementieren der Revisionsnummern scheint nicht möglich zu sein

Ausgangssituation: Im Cluster liegen mehrere Revisionen einer Definition (darunter auch benannte).

1. cue-File der Definition anpassen: Annotation für Revisionsname entfernen und eine Änderung im Template-Bereich vornehmen
2. vela def apply comp.cue => Fehler: Error: failed to update existing definition in kubernetes: admission webhook "validating.core.oam-dev.v1beta1.componentdefinitions" denied the request: the definition's spec is different with existing definitionRevision's spec

Aufräummechanismus von kubevela

kubevela hat einen Mechanismus zum Aufräumen alter Revisionen, nur die neusten X Revisionen werden im Cluster behalten (bei lokalen Tests waren das etwa 20)

Ausgangssituation:

1. Definition (basicapp) mit benanntem Revisionennamen (1.0) erstellen + vela def apply
2. Application erstellen, die diese Revision referenziert (basicapp@v1.0) + kubectl apply
3. Wiederholtes Ändern des Revisionsnamen + vela def apply, bis die in Schritt 1 erstellte Revision durch kubevela aufgeräumt wird und nicht mehr im Cluster ist (bei lokalen Tests waren das etwa 20 Wiederholungen)
4. Auch wenn die Definition im Cluster nicht mehr vorhanden ist, läuft die Applikation weiter
5. Ändert man jedoch etwas in der Applikation + kubectl apply, bekommt man einen Fehler, da kubevela die Definition nicht im Cluster finden kann:

Error from server: error when applying patch:
{"metadata":{"annotations":{"kubectl.kubernetes.io/last-applied-configuration":"{\"apiVersion\":\"core.oam.dev/v1beta1\",\"kind\":\"Application\",\"metadata\":{\"annotations\":{},\"name\":\"whoami\",\"namespace\":\"default\"},\"spec\":{\"components\":[{\"name\":\"whoami\",\"properties\":{\"image\":\"containous/whoami\",\"replicas\":2},\"type\":\"basicapp@v1.0\"}]}}\n"}},"spec":{"components":[{"name":"whoami","properties":{"image":"containous/whoami","replicas":2},"type":"basicapp@v1.0"}]}}
to:
Resource: "core.oam.dev/v1beta1, Resource=applications", GroupVersionKind: "core.oam.dev/v1beta1, Kind=Application"
Name: "whoami", Namespace: "default"
for: ".\\apps\\whoami-v1.yml": error when patching ".\\apps\\whoami-v1.yml": admission webhook "validating.core.oam.dev.v1beta1.applications" denied the request: field "spec": Invalid value error encountered, fetch component/policy type of whoami: load template from component definition [basicapp@v1.0] : WorkloadDefinition.core.oam.dev "basicapp@v1.0" not found.

Links zu diesem Thema

• definitions support specify the revision name kubevela/kubevela#2044
• Changelog https://github.com/kubevela/kubevela/blob/master/CHANGELOG/CHANGELOG-1.1.md#v110-rc2 => 4.