How to add custom StorageClasses in cloud provider extesions

[dergeberl]

How to categorize this issue? /area storage /kind discussion

Hi,

we had a discussion in the gardener-extension-provider-openstack (https://github.com/gardener/gardener-extension-provider-openstack/pull/408) about integrating additional StorageClasses in the Gardener.

In the PR mentioned @rgroemmer added this feature directly in the openstack provider. There are more possible options how to implement this topic. The main point is where to store the StorageClasses settings. In the provider part of the CloudProfile spec.providerConfig or directly in the CloudProfile to be able to use same setting for all CloudProviders

A second point was how to implement the current defaults?

• Currently the default is SC is always applied (via helm chart)
• If none SCs are defined in the CloudProfile, the behavior is the same as before, but SC get rendered in code and not with a helm chart.
• And if SCs are defined than the CloudProfile only these SCs are used, and the "old" default SCs are not deployed.

@kon-angelo please add/correct me if I forget something.

How should we proceed?

[gardener-ci-robot]

The Gardener project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close

/lifecycle stale

[gardener-ci-robot]

The Gardener project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close

/lifecycle rotten

[gardener-ci-robot]

The Gardener project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten

/close

[gardener-prow[bot]]

@gardener-ci-robot: Closing this issue.

In response to this:

The Gardener project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.