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: CONTRIBUTING.md
+3-5Lines changed: 3 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,13 +1,11 @@
1
1
# Contributing Guidelines
2
2
3
-
<br>
4
-
5
3
## Umbrella Project
6
4
7
-
OpenEBS is an "umbrella project". Every project, repository and file in the OpenEBS organization adopts and follows the policies found in the Community repo umbrella project files.
8
-
<br>
5
+
OpenEBS is an `Umbrella Project` whose governance and policies are defined in the [community](https://github.com/openebs/community/) repository.
6
+
These policies are applicable to every sub-project, repository and file existing within the [OpenEBS GitHub organization](https://github.com/openebs/).
9
7
10
-
This project follows the [OpenEBS Contributor Guidelines](https://github.com/openebs/community/blob/HEAD/CONTRIBUTING.md)
8
+
This project follows the [OpenEBS Contributor Guidelines](https://github.com/openebs/community/blob/HEAD/CONTRIBUTING.md).
11
9
12
10
## Contributing to OpenEBS Dynamic Local PV Provisioner
<strong>OpenEBS Dynamic Local PV provisioner</strong> can be used to dynamically provision
13
-
Kubernetes Local Volumes using different kinds of storage available on the Kubernetes nodes.
14
-
<br>
15
-
</p>
16
-
17
-
## Project Status: GA
18
-
19
-
Local Persistent Volumes are great for distributed cloud native data services that can handle resiliency and availability and expect low-latency access to the storage. Local Persistent Volumes can be provisioned using the hostpath, NVMe or PCIe based SSDs, Hard Disks or on top of other filesystems like ZFS, LVM.
20
-
21
-
Some of the targetted applications are:
22
-
23
-
- Distributed SQL Databases like PostgreSQL
24
-
- Distributed No-SQL Databases like MongoDB, Cassandra
25
-
- Distributed Object Storages like MinIO (distributed mode)
26
-
- Distributed Streaming services like Apache Kakfa,
27
-
- Distributed Logging and search services like ElasticSearch, Solr
Kubernetes Local persistent volumes allows users to access local storage through the
33
-
standard PVC interface in a simple and portable way. The PV contains node
34
-
affinity information that the system uses to schedule pods to the correct
35
-
nodes. Features:
36
-
37
-
- Supports using hostpath as well for provisioning a Local PV. In fact in some
38
-
cases, the Kubernetes nodes may have limited number of storage devices
39
-
attached to the node and hostpath based Local PVs offer efficient management
40
-
of the storage available on the node.
15
+
OpenEBS Dynamic LocalPV Provisioner is an open‐source Kubernetes component that automates the dynamic provisioning of local persistent volumes. It converts local storage available on Kubernetes nodes, such as hostPath directories into persistent volumes accessible via PVCs. The provisioner automatically assigns node affinity metadata, ensuring that pods run on the node hosting the storage. The tool simplifies local storage management by automating volume creation, binding, and cleanup processes for hostpaths. It overcomes challenges of static provisioning by dynamically allocating storage on demand. Overall, the provisioner offers a robust, scalable solution for managing local persistent hostpath volumes in Kubernetes.
16
+
17
+
## Why OpenEBS Dynamic LocalPV Provisioner?
18
+
19
+
- <b>Dynamic Provisioning</b>: Automatically creates persistent hostpath volumes on demand from local node storage, reducing manual configuration.
20
+
- <b>Seamless Kubernetes Integration</b>: Uses node affinity to ensure pods are scheduled on the node where the volume is located, maintaining data consistency.
21
+
- <b>Customizable Storage Behavior</b>: Offers flexible configuration through StorageClasses, supporting hostpath features like quota enforcement etc.
22
+
- <b>Optimized for High Performance</b>: Ideal for high-performance, low-latency, stateful applications like replicated databases which need local storage.
Please refer to our [Quickstart](https://github.com/openebs/dynamic-localpv-provisioner/blob/develop/docs/quickstart.md) and the [OpenEBS Documentation](http://openebs.io/docs/).
53
-
54
-
## Contributing
55
-
56
-
Head over to the [CONTRIBUTING.md](./CONTRIBUTING.md) page.
57
-
58
-
## Roadmap
59
-
60
-
Find the Dynamic Local PV roadmap items at the [OpenEBS Roadmap page](https://github.com/openebs/openebs/blob/HEAD/ROADMAP.md#dynamic-local-pvs).
61
-
62
-
## OpenEBS Adopters
63
-
64
-
Check out the list of organizations and users who have chosen OpenEBS to run their stateful workloads, over at the [OpenEBS Adopters page](https://github.com/openebs/openebs/blob/HEAD/ADOPTERS.md).
65
-
66
-
## Community, discussion, and support
67
-
68
-
Learn how to engage with the OpenEBS community on the [community page](https://github.com/openebs/openebs/tree/HEAD/community).
OpenEBS Dynamic Local PV Provisioner follows a monthly release cadence. The scope of the release is determined by contributor availability. The scope is published in the [Release Tracker Projects](https://github.com/orgs/openebs/projects).
3
+
Local PV Hostpath tries to follow semantic versioning principles as specified here https://semver.org. It follows a on quarterly release cadence for minor version releases. The scope of the release is determined by contributor availability. The scope is published in the [Release Tracker Projects](https://github.com/orgs/openebs/projects/78).
4
4
5
-
## Release Candidate Verification Checklist
5
+
## Pre-release Candidate Verification Checklist
6
6
7
-
Every release has release candidate builds that are created starting from the third week into the release. These release candidate builds help to freeze the scope and maintain the quality of the release. The release candidate builds will go through:
7
+
Every release has a pre-release version that gets created on branch creation, explained further below. This pre-release version is meant for all the below action items throughout the release process:
8
8
9
9
- Platform Verification
10
-
- Regression and Feature Verification Automated tests.
11
-
- Exploratory testing by QA engineers
12
-
- Strict security scanners on the container images
13
-
- Upgrade from previous releases
14
-
- Beta testing by users on issues that they are interested in.
15
-
- Dogfooding on OpenEBS workload and e2e infrastructure clusters.
10
+
- Automated Regression & Feature Testing
11
+
- Exploratory Testing by QA engineers
12
+
- Strict Security Scanning on container images
13
+
- Upgrade Testing from previous releases
14
+
- Beta Testing by users on relevant issues
16
15
17
-
If any issues are found during the above stages, they are fixed and a new release candidate builds are generated.
16
+
If any issues are found during the above stages, they are fixed and the prerelease version is overridden by the newer changes and are up for above action items again.
18
17
19
-
Once all the above tests are completed, a main release tagged image is published.
18
+
Once all the above tests are completed, a main release is created.
20
19
21
20
## Release Tagging
22
21
23
-
Dynamic Local PV Provisioner is released as a set of container images with a versioned tag.
22
+
Local PV Hostpath is released with container images and a respective helm chart as the only recommended way of installation.
24
23
25
-
Before creating a release, the repo owner needs to create a separate branch from the active branch, which is `develop`. Name of the branch should follow the naming convention of `v1.9.x` if the release is for v1.9.0.
24
+
Before creating a release, the repo owner needs to create a separate branch from the active branch, which is `develop`. Name of the branch should follow the naming convention of `release/2.7` if release is for `2.7.x`.
26
25
27
-
Once the release branch is created, changelog from `changelogs/unreleased` needs to be moved to release specific folder `changelogs/v1.9.x`, if release branch is `v1.10.x` then folder will be `changelogs/v1.10.x`.
26
+
Upon creation of a release branch ex. `release/2.7`, two automated PRs open up to change the chart versions of the charts in `release/2.7` branch to `2.7.0-prerelease` and `develop`to `2.8.0-develop`. Post merge of these two PRs, the `2.7.0-prerelease` and `2.8.0-develop` versions are pushed to respective docker registries and also the respective helm charts against these versions are published. The prerelease versions increment via automated PRs on every release creation. For example once `2.7.0` is published a `2.7.1-prerelease` image and chart would be published to allow testing of further patch releases and so on.
28
27
29
-
The format of the release tag is either "Release-Name-RC1" or "Release-Name" depending on whether the tag is a release candidate or a release. (Example: v1.9.0-RC1 is a GitHub release tag for the release build. v1.9.0 is the release tag that is created after the release criteria are satisfied by the release candidate builds.)
28
+
The format of the release tag follows semver versioning. The final release tag is of format `X.Y.Z` and the respective prerelease and develop versions are `X.Y.Z-prerelease` and `X.Y+1.0-develop`.
30
29
31
-
Once the release is triggered, Github Actions release workflow has to be monitored. Once the release workflow is passed images are pushed to docker hub and quay.io. Images can be verified by going through docker hub and quay.io. Also the images shouldn't have any high-level vulnerabilities.
30
+
Once the release is triggered, the unchanged code undergoes stages as such linting, unit-tests and bdd-tests and the code coverage is updated accordingly. Post the former jobs, the image build is triggered with the specified tag, the images are published and the chart is run though scripts that update the image tags at the relevant places and eventually helm charts are published.
32
31
33
-
Images for the different components are published at the following location:
32
+
The helm charts are hosted on github deployments for the corresponding releases.
- Once merged, the updated images and Helm charts are published for testing.
38
39
39
-
Once a release is created, update the release description with the changelog mentioned in `changelog/v1.9.x`. Once the changelogs are updated in the release, the repo owner needs to create a PR to `develop` with the following details:
40
+
3.**Final Release Creation:**
41
+
- When the release branch is ready, the repo owner **creates a release with tag `X.Y.Z`** (e.g., `2.7.0`).
42
+
- The release process includes:
43
+
- Linting, unit tests, and BDD tests
44
+
- Code coverage updates
45
+
- Image builds with the specific tag (e.g., `2.7.0`)
46
+
- Helm chart updates and publishing
40
47
41
-
1. update the changelog from `changelog/v1.9.x` to `CHANGELOG.md`
42
-
2. If a release is not an RC tag then PR should include the changes to remove `changelog/v1.9.x` folder.
43
-
3. If a release is an RC tag then PR should include the changes to remove the changelog from `changelog/v1.9.x` which are already mentioned in `CHANGELOG.md` as part of step number 1.
48
+
4.**Post-GA Version Increments:**
49
+
- After the release is GA (General Availability):
50
+
- The next **pre-release version** (`2.7.1-prerelease`) is published.
51
+
- The **develop branch** continues with `2.8.0-develop` for the next major/minor release cycle.
52
+
53
+
### Patch Release Process
54
+
55
+
1.**Branching & Changes:**
56
+
- Patch releases are made against the existing release branch (e.g., `release/2.7`).
57
+
- All merged changes are available for testing via the **prerelease version** (`2.7.1-prerelease`).
58
+
59
+
2.**Final Patch Release Creation:**
60
+
- When ready, the repo owner **creates a release with tag `X.Y.Z+1`** (e.g., `2.7.1`).
61
+
- The release process includes:
62
+
- Linting, unit tests, and BDD tests
63
+
- Code coverage updates
64
+
- Image builds with the specific tag (e.g., `2.7.1`)
65
+
- Helm chart updates and publishing
66
+
67
+
3.**Post-GA Version Increments:**
68
+
- Once the patch is GA:
69
+
- The next **pre-release version** (`2.7.2-prerelease`) is published.
70
+
- The **develop branch** continues with `2.8.0-develop` for the next major/minor release cycle.
71
+
72
+
## Release Artifacts
73
+
74
+
-**Container Images:** Published at [Docker Hub](https://hub.docker.com/r/openebs/provisioner-localpv/tags)
75
+
-**Helm Charts:** Hosted on [GitHub Deployments](https://github.com/openebs/dynamic-localpv-provisioner/tree/gh-pages)
76
+
77
+
Before finalizing a release or patch release, it is ensured that **all significant changes** are documented in `CHANGELOG.md`.
78
+
79
+
---
80
+
81
+
This document streamlines the release process it ensuring all necessary details remain intact.
0 commit comments