search

SovereignCloudStack / issues

This repository is used for issues that are cross-repository or not bound to a specific repository.
https://github.com/orgs/SovereignCloudStack/projects/6
2 stars 1 forks source link

Standardize additional storage classes #214

Open garloff opened 1 year ago

garloff commented 1 year ago

As a SCS container user, I want to have the ability to claim persistent volume from storage with specific requirements:

Todo: Research what is needed and standardize requirements, names, ....

Definition of Ready:

Definition of Done:

garloff commented 1 year ago

Block storage performance: standard, high, veryhigh (How many tiers do we need?) (Independently of this, larger volumes tend to have higher bandwidth ...)

Team is wondering about the benefit, as users will look this up and test and also have to check pricing.

This could be just a naming convention, not prescribing that providers need to provide all classes mandatorily.

garloff commented 1 year ago

Encryption:

=> Ask IaaS team to investigate and standardize this.

garloff commented 1 year ago

Local storage is wanted. (Databases, other apps that replicate data themselves.)

Nice to have, so we could standardize it ... Not mandatory, but we standardize naming and properties. Not available on e.g. Azure AWS: Instance-storage ... Local storage is attached to node - not "persistent" Local path provisioner (and pinning of pods to nodes) for application cluster -> local throwaway storage

batistein commented 1 year ago

@garloff In the past few weeks, we've often seen the demand for ReadWriteMany support. More and more new cloud-native software relies directly on volumes. Without ReadWriteMany support it is often not possible to scale beyond 1 replica.

A good example of this is owncloud ocis, which no longer requires a database. It relies heavily on volumes. See: https://github.com/owncloud/ocis-charts/blob/master/charts/ocis/values.yaml#L434-L436

garloff commented 1 year ago

Solution options for RWX:

  1. Shared network filesystem (like NFS, CIFS, cephfs)
    • OpenStack could provide this via the Manila Service (currently not enabled by default in SCS)
  2. ClusterFS with Multi-Attach
batistein commented 1 year ago

more projects where RWX is needed:

garloff commented 1 year ago

Options to investigate for implementation (we don't know yet if they achieve production quality): 1a) manila and csi-manila 1b) rook (possibly with size=1 when using ceph storage from IaaS -- need to ensure that the volume can be attached to VMs in all AZs)

garloff commented 1 year ago

Ad 1a: Preliminary results from investigating the manila option (with cephfs) @matfechner:

garloff commented 1 year ago

Ad 1b: Full ceph cluster in the user's k8s cluster, significant infra needed, performance not great.

garloff commented 1 year ago

Ad 1b: Alternative might be using a different k8s storage, e.g. Longhorn instead ceph with rook.

horazont commented 1 year ago

https://goharbor.io/docs/2.1.0/install-config/harbor-ha-helm/

To quote from that page:

If you have no PVCs that can be shared across nodes, you can use external object storage to store images and charts and store the job logs in database. Set the persistence.imageChartStorage.type to the value you want to use and fill the corresponding section and set jobservice.jobLogger to database.

So RWX does not seem to be strictly required.

NotTheEvilOne commented 1 year ago

As for type "encrypted". Even thought OpenStack supports encryption using "barbican" and "cinder" the CSI implementation does not as for today. See cloud-provider-openstack@1881

This is the case for other CSI implementations as well. So I think it would not be helpful to add this to a list of required storage classes.

akafazov commented 10 months ago

I have also encountered several times need for RWX, link here: https://github.com/Daiteap/daiteap-platform/blob/master/helm/platform-api/templates/deployment.yaml#L230-L231

Use case: