Merge pull request #336 from Seagate/v0.9_branch

Merge v0.9.0 branch into main

.alexignore

@@ -0,0 +1 @@
+CODE_OF_CONDUCT.md

.alexrc

@@ -1,3 +1,3 @@
 {
-  "allow": ["execute", "host-hostess", "remains", "reject", "traps", "invalid", "period", "execution", "simple", "failure"]
+  "allow": ["execute", "host-hostess", "remains", "reject", "traps", "invalid", "period", "execution", "simple", "failure", "failures", "just"]
 }

.github/PULL_REQUEST_TEMPLATE.md

@@ -50,7 +50,7 @@ images, please list those images and link them to the public CORTX packages page
 - cortx-control images are published at https://github.com/Seagate/cortx/pkgs/container/cortx-control
 
 The referenced images are always defined in the images section of the solution.example.yaml file. If
-updated images are required, the example solution YAML file should be updated in this change.
+updated images are required, the example solution YAML file should be updated in this change. The Helm chart `appVersion` field must also be updated to match the version of the images.
 
 If the currently referenced CORTX container images support this change, you can delete this section
 or indicate that.
@@ -86,6 +86,11 @@ serves as a reminder for what the maintainers will be looking for when reviewing
 - [ ] New or changed settings in the solution YAML are documented clearly in the README.md file.
 - [ ] All commits are signed off and are in agreement with the [CORTX Community DCO and CLA policy](https://github.com/Seagate/cortx/blob/main/doc/dco_cla.md).
 
+If this change requires newer CORTX or third party image versions:
+
+- [ ] The `image` fields in [solution.example.yaml](../k8_cortx_cloud/solution.example.yaml) have been updated to use the required versions.
+- [ ] The `appVersion` field of the [Helm chart](../charts/cortx/Chart.yaml) has been updated to use the new CORTX version.
+
 If this change addresses a CORTX Jira issue:
 
 - [ ] The title of the PR starts with the issue ID (e.g. `CORTX-XXXXX:`)

.github/workflows/lint.yaml

@@ -44,11 +44,6 @@ jobs:
         shell: bash
         working-directory: ./k8_cortx_cloud
 
-      - name: Validate solution_stub.yaml
-        run: ./solution_validation_scripts/solution-validation.sh solution_stub.yaml
-        shell: bash
-        working-directory: ./k8_cortx_cloud
-
   # Reference: https://github.com/helm/chart-testing-action
   chart-lint-test:
     name: Lint and Test Helm Charts

.gitignore

@@ -4,3 +4,6 @@ logs-cortx-cloud-*.tar
 # Auto-generated deployment files
 k8_cortx_cloud/cortx-cloud-3rd-party-pkg/auto-gen-*
 k8_cortx_cloud/cortx-cloud-helm-pkg/cortx-configmap/auto-gen-*
+
+# Runtime-dependent Helm Charts
+charts/cortx/charts

GLOSSARY.md

@@ -0,0 +1,71 @@
+# Glossary for CORTX on Kubernetes
+
+This page will serve as a clearinghouse for all terms, definitions, and acronyms critical to both the understanding of and having success with [CORTX](https://github.com/Seagate/cortx). Please feel free to add terms as needed but place them in proper alphabetical order.
+
+## Glossary
+
+### Container
+
+Per [Red Hat](https://www.redhat.com/en/topics/containers/whats-a-linux-container), a container, or sometimes referred to as a Linux container, is "a set of 1 or more processes that are isolated from the rest of the system. All the files necessary to run them are provided from a distinct image, meaning Linux containers are portable and consistent as they move from development, to testing, and finally to production."
+
+### CORVAULT
+
+[CORVAULT](https://www.seagate.com/products/storage/data-storage-systems/corvault/) is the brand name for a specific Seagate storage hardware product. CORVAULT generally belongs to a category of storage referred to as RBOD (reliable bunch of disks). Physically, CORVAULT is a large 4U rack enclosure which holds up to 106 devices. By virtue of firmware running inside the enclosure, CORVAULT appears to the upper-layer host (CORTX in our case) as two very large individual disks. Internally, CORVAULT does declustered erasure such that the frequency of "disk" failures seen by the host is very low (albeit when they happen, they are a large failure).
+
+### CORTX Control Pods
+
+CORTX Control Pods contain the APIs which are exposed to the end-user in order to maintain the CORTX control plane and are most often used to interact with IAM settings.
+
+### CORTX Data Pods
+
+CORTX Data Pods contain the internal APIs which are used to manage the storage and protection of data at the lowest possible level inside of a CORTX cluster.
+
+### CORTX HA (High Availability) Pods
+
+CORTX HA Pods are responsible for monitoring the overall health of the CORTX cluster and notifying components of changes in system status.
+
+### CORTX Server Pods
+
+CORTX Server Pods contain the APIs which are exposed to the end-user in order to provide general S3 functionality - create buckets, copy objects, delete objects, delete buckets. This API layer is implemented using the Rados Gateway (RGW) interface.
+
+### CVG (Cylinder Volume Group)
+
+A Cylinder Volume Group, or CVG, is a collection of drives or block devices which CORTX utilizes as a unit of storage, all managed by a single Motr IO process.
+
+### Data Devices / Drives
+
+Block devices, HDDs, SDDs, or other types of storage devices addressable by `/dev/{device-name}` which CORTX uses to store user data.
+
+### JBOD
+
+JBOD stands for "Just a Bunch of Disks" and refers to a rack enclosure containing many disks which are each individually exposed to the host (CORTX in our case).
+
+### Metadata Devices / Drives
+
+Block devices, HDDs, SDDs, or other types of storage devices addressable by `/dev/{device-name}` which CORTX uses to store metadata about user data.
+
+### Motr
+
+Motr is the central storage capability inside of a CORTX cluster. It functions as a distributed object and key-value storage system targeting mass-capacity storage configurations.
+
+### Node
+
+This term is unfortunately overloaded in the context of CORTX on Kubernetes. It can either mean an underlying Kubernetes worker node (in general) or it can mean any single component working inside of the CORTX cluster (Data Pod, Server Pod, Control Pod, etc.). 
+
+Context is important and required to discern when which is which. Through the https://github.com/Seagate/cortx-k8s repository, care is used to refer to Kubernetes worker nodes as "Nodes" and CORTX nodes running on Kubernetes as "Pods".
+
+### Pod
+
+Per the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/workloads/pods/), "Pods are the smallest deployable units of computing that you can create and manage in Kubernetes." Inside of a CORTX cluster, all relevant containers that need to be contextually grouped together are deployed as a Pod. 
+
+### Rados Gateway (RGW)
+
+This is the component which provides all necessary S3 functionality in a CORTX cluster through a central gateway interface.
+
+### RBOD
+
+RBOD means "Reliable Bunch of Drives". Physically it is similar to JBOD but interally it uses erasure or RAID to add better data protection by distributing data across multiple disks and protecting it with parity. Logically, an RBOD will therefore export itself to the host (CORTX in our case) as a smaller number of drives which are much larger in capacity. For example, imagine an RBOD of 100 drives. For high availability reasons, most RBODs will use dual ported drives and will split themselves into two groups of disks. A pair of controllers in the RBOD will provide active-passive access to each pair such that the drives served by the active controller can be instead served by the passive controller in the case of a failure of the active controller. Further imagine, that the RBOD is configured for 8+2 parity within each group of drives. Therefore, to the upper level host, this RBOD will logically appear as just two large drives, each of which being the aggregate size of 40 drives (i.e. 8+2 on 50 drives will use 20% of capacity for parity thereby leaving 80% of capacity for host data).
+
+### Storage Set
+
+A Storage Set is the common unit of deployment and scalability for CORTX and its mapping to the underlying infrastructure. A given Kubernetes worker node can only belong to a single Solution Set for the lifetime of a CORTX cluster. A Storage Set is defined as a collection of Kubernetes worker nodes and CVGs.