You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: modules/ROOT/pages/getting-started.adoc
+1Lines changed: 1 addition & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,5 @@
1
1
= Getting Started
2
+
:page-aliases: getting_started.adoc
2
3
3
4
One of the best ways of getting started with a new platform is to try it out. Any big data platform has a lot of moving parts and getting some hands on keyboard time with it helps reinforce learning.
Copy file name to clipboardExpand all lines: modules/ROOT/pages/policies.adoc
+22-21Lines changed: 22 additions & 21 deletions
Original file line number
Diff line number
Diff line change
@@ -1,12 +1,11 @@
1
-
= Lifecycle Policies
1
+
= Lifecycle policies
2
2
3
-
This page details our current lifecycle policies around various parts of our product - the Stackable Data Platform (SDP).
3
+
This page details our lifecycle policies around various parts of our product - the Stackable Data Platform (SDP).
4
4
5
-
We define multiple lifecycle policies for different parts of our platform, but all these policies follow some common goals:
5
+
We define multiple lifecycle policies for different parts of our platform, but all policies follow some common goals:
6
6
7
7
* It should always be possible to upgrade to a new version of SDP without also changing any of your Kubernetes resources as long as you are not currently using anything that has already been marked as deprecated
8
8
** This means you can upgrade the control plane independently of the user-facing products
9
-
10
9
* All deprecations follow a predictable lifecycle that allows planning of upgrades ahead of time
11
10
12
11
The guarantees we give are on multiple levels as detailed below:
@@ -20,21 +19,20 @@ All these policies may evolve as we learn what works best for our customers and
20
19
21
20
These policies are from *July 2023*.
22
21
23
-
24
-
== Stackable Data Platform Lifecycle Policy
22
+
== Stackable Data Platform lifecycle policy
25
23
26
24
NOTE: This policy concerns releases of our platform as a whole and how long and to which extent we support each version.
27
25
28
26
We do releases of our Stackable Data Platform.
29
27
These releases get a name based on the year and month they have been released in (e.g. `23.4`, `23.7`, also called https://calver.org/[CalVer]). This name does not follow Semantic Versioning (https://semver.org/[SemVer]). We may release patches for a release, which then follow the PATCH naming semantics of SemVer (e.g. `23.4.1`) or the _Micro_ name from CalVer. See below for our policy on patches for the SDP.
30
28
31
-
We do support an SDP release for a specific time after its release.
29
+
We support an SDP release for a specific amount of time after its initial release.
32
30
33
31
An SDP release contains our operators and other code developed at Stackable as well as the product docker images.
34
32
35
33
TIP: Our policy is inspired by the https://kubernetes.io/releases/patch-releases/[Kubernetes] and the https://access.redhat.com/support/policy/updates/openshift#ocp4[OpenShift] policies.
36
34
37
-
=== Full Support Phase
35
+
=== Full support phase
38
36
39
37
This phase begins once a new non-patch SDP version is released and ends after a 6-month period OR 3 months after the general availability of the superseding non-patch release, whichever is later.
40
38
@@ -47,26 +45,26 @@ image:full_support_scenario_2.png[Full Support Scenario 2]
47
45
We _will_ release new patch releases of a SDP release (e.g. `23.4.1`) for any issues we deem Critical or High (see definition below) once fixes become available.
48
46
We _may_ release new patch releases for other reasons.
49
47
50
-
=== Maintenance Phase
48
+
=== Maintenance phase
51
49
52
50
This phase commences after the _Full Support_ phase for the respective SDP version and ends 12 months after general availability of the SDP release.
53
51
54
52
We _may_ release new patch releases of a SDP release (e.g. `23.4.1`) for any issues we deem Critical or High (see definition below) once fixes become available.
53
+
We may release patches for other reasons.
55
54
56
55
image:maintenance_phase.png[Maintenance Phase]
57
56
58
-
=== General
59
-
60
-
We may release patches for other reasons.
57
+
== Upgrade policy
61
58
62
59
Customers are expected to upgrade their SDP environment to the most current supported patch/micro (`23.4.z`) version.
63
-
Make sure to follow our release notes to learn of valid upgrade paths, some intermediate updates might be necessary.
60
+
Skipping SDP releases while upgrading is currently not supported.
61
+
The only upgrade path we support is from one version to the next.
64
62
65
-
== CRD Versioning Lifecycle Policy
63
+
== CRD Versioning lifecycle policy
66
64
67
65
IMPORTANT: As of June 2023 all our CRDs are versioned as `alpha1`. We will start introducing other versions later in 2023.
68
66
69
-
``CustomResourceDefinition``s at Stackable are versioned.
67
+
CustomResourceDefinitions at Stackable are versioned.
70
68
71
69
Our policies around CRD versioning are inspired by the https://kubernetes.io/docs/reference/using-api/deprecation-policy/[Kubernetes Deprecation Policy].
72
70
@@ -90,7 +88,7 @@ Similar to the Exception noted by the Kubernetes project itself, we will also ev
90
88
NOTE: According to these rules it is legal to _add_ fields to a CRD without increasing the version as long as there is a default for this field.
91
89
92
90
93
-
== Product Lifecycle Policy
91
+
== Product lifecycle policy
94
92
95
93
SDP ships with a lot of different downstream products (e.g. Apache HBase, Apache Superset).
Every product version that gets removed will be deprecated for at least 1 SDP release before removal.
117
-
This guarantees that users can update the operators (e.g. from 23.1 to 23.4) without the need to simultaneously update the product version as well. The flow is to first update the control plane (the operators) and afterward the product versions if desired (e.g. when the currently used version is now deprecated).
115
+
This guarantees that users can update the operators (e.g. from 23.1 to 23.4) without the need to simultaneously update the product version as well.
116
+
The flow is to first update the control plane (the operators) and afterward the product versions if desired (e.g. when the currently used version is now deprecated).
118
117
119
-
=== Definition of "support"
118
+
=== Definition of support
120
119
121
120
We will ship new versions of the LTS release line in our currently supported SDP releases (see above) for any issues we deem Critical or High in severity when they become available.
122
121
@@ -127,17 +126,19 @@ It is our explicit goal to limit the amount of times we have to ship a version o
127
126
We may ship new versions for existing SDP releases for other issues as well.
128
127
129
128
130
-
== OpenShift & Kubernetes Support Policy
129
+
== OpenShift & Kubernetes support policy
131
130
132
131
For every SDP release we will publish a list of supported Kubernetes versions.
133
132
134
133
We are aiming to support the last three Kubernetes versions but will make case-by-case decisions by taking into account the currently supported Kubernetes versions.
135
134
We will also take into account currently supported OpenShift versions as published by RedHat. It is our goal to support all versions that are in Full or Maintenance support. As the releases may be overlapping we might not always support the latest Kubernetes or OpenShift versions when we release a SDP version.
136
135
137
136
138
-
== Support Policy (Security & Bugs)
137
+
== Support policy (security & bugs)
139
138
140
-
Stackable will analyze published security vulnerabilities (e.g. CVEs but other sources may apply as well) for all the products we support as well components developed by us and their dependencies. We take various sources into account when assigning a criticality. Among those sources is the NVD database, but we place higher value on the self-assessments by the projects themselves, and we will additionally evaluate vulnerabilities in the context of how they are used in the Stackable Data Platform.
139
+
Stackable will analyze published security vulnerabilities (e.g. CVEs but other sources may apply as well) for all the products we support as well components developed by us and their dependencies.
140
+
We take various sources into account when assigning a criticality.
141
+
Among those sources is the NVD database, but we place higher value on the self-assessments by the projects themselves, and we will additionally evaluate vulnerabilities in the context of how they are used in the Stackable Data Platform.
141
142
142
143
We will then assign a criticality to each vulnerability according to similar rating categories that https://access.redhat.com/security/updates/classification[RedHat has established]:
0 commit comments