List view
Collections of issues, ideas, proposals that we want to include in a Operator v2.0 To start developing on piraeus operator v2, make a clean break and upgrade to the latest operator-sdk. The implementation will focus on improving the issues encountered with v1. The main goals are: - A default installation should just work, without user intervention. For example: DRBD injection should select the right image automatically. - Common customizations should be easy to apply. For example: Using a different registry. - The user should be able to customize almost any managed resource. For example: To include additional configuration or secrets. - The default installation should make a robust and secure setup. For example: TLS should be configured between all components. Operator v2 only has a single cluster-scoped resource to control the LINSTOR cluster. This will set up Controller, Satellites and CSI Driver. The resource can be applied with an empty spec, which will lead to a default cluster with automatically selected image versions. Configuration of satellites happens using a secondary resource (not implemented). This will allow configuration to apply only to a subset of nodes. Further customization of components is possible by user-provided "patches" to existing resources. This is done by using "kustomize" internally, where the user patches are integrated into the normal kustomize process.
No due date•9/10 issues closedCommon milestone for all 1.X changes. These generally include: * Bug fixes * New features (that do not break backward compatibility) Any feature/fix breaking backward compatibility will need to wait for a 2.0 release
No due date•3/3 issues closedFirst stable release of piraeus-operator
No due date•6/6 issues closed