This repository is currently being migrated. It's locked while the migration is in progress.
-
Notifications
You must be signed in to change notification settings - Fork 4
Open
Description
What do we want to build?
When the "init" container attempts to load the required kernel modules, if these are missing, the "init" container will deploy the appropriate system package then load them.
Why do we want to build it?
The current behavior is to exit with en error when the kernel modules are not available. To reduce the installation friction, the "init" container could deploy the relevant system package with the extra kernel modules to continue the deployment.
How do we want to design it?
MVP stage:
- fork the repo with as
init-ubuntu - modify the script to include the installation of the system package "linux-modules-extra" for the relevant deployed kernel version
- push the build on dockerhub with a version for and with tag ubuntu1804 and ubuntu2004 to cover to use cases
- when needed, the Ops team can use the Operator parameter "images.initContainer" translate as
initContainer: storageos/init:ubuntu:1804within the StorageOSCluster definition:
---
apiVersion: storageos.com/v1
kind: StorageOSCluster
metadata:
name: ${STOS_CLUSTERNAME}
namespace: ${STOS_NAMESPACE}
spec:
secretRefName: "storageos-api"
secretRefNamespace: "storageos-operator"
k8sDistro: "upstream" # Set the Kubernetes distribution for your cluster (upstream, eks, aks, gke, rancher, dockeree, openshift)
images:
# for testing only with intrepidsquirrel
initContainer: storageos/init:ubuntu:1804
nodeContainer: "storageos/node:${STOS_VERSION}" # StorageOS version
# storageClassName: fast # The storage class creates by the StorageOS operator is configurable
kvBackend:
address: "storageos-etcd-client.${ETCD_NAMESPACE}.svc:2379"
Metadata
Metadata
Assignees
Labels
No labels