Redpanda allows multiple cloud stores to be configured, allows empty strings for URLs

[joejulian]

Version & Environment

Redpanda version: (use rpk version): v23.1.2

What went wrong?

A user configured the gcp cloud store but also had empty strings (see PR 9591) for their azure config. The azure config overrode their gcp config.

What should have happened instead?

I would have expected Redpanda to fail with an error stating that multiple cloud stores were configured. This would have made it clearer what was wrong.

How to reproduce the issue?

1. 2. 3.

Additional information

Please attach any relevant logs, backtraces, or metric charts.

JIRA Link: CORE-1223

[jcsp]

So, config_multi_property_validation is a place we can do things like requiring two properties are mutually exclusive, although that only applies to API PUTs -- if bad configs are loaded via a bootstrap file, they're less rigorously validated.

On bootstrap, if we see an invalid property in .bootstrap.yaml we log a warning and ignore it, to make life more flexible for installers. We could do the same thing for multi-property validations if we applied them there. Or, we could make this stricter and refuse to start up if there is something invalid in .bootstrap.yaml - this would put the onus on installers to ensure that if they e.g. write a config that only makes sense in Redpanda v23.1, that they omit this config if installer Redpanda v22.3, to avoid hitting a validation error that prevents a cluster starting up.

We should also introduce a NonEmptyString validating class for properties like this, where folks might set "" thinking it means "unset", rather than meaning "set and empty".

[jcsp]

Thoughts on adjusting the overall config loading to be more strict against inputs that try and configure multiple backends:

• Adjust cloud_storage::configuration::get_config to use a stricter set of checks than whether the Azure storage account is set. It should probably check the new backend setting first, and then validate that the properties required to use that backend are set. If no backend is selected, it should infer the backend the same way that remote does it.
• Remove the behavior that empty URI == AWS in all cases. Now that we have a backend setting, we can also tolerate an empty URI for GCS (automatically set storage.googleapis.com) in this case.
• Adjust cloud_storage_clients::infer_backend_from_configuration to detect and reject ambiguous cases, and then use that in admin_server's config_multi_property_validation to reject configuration changes that would put us into an ambiguous state. Setting multiple cloud's backend properties is acceptable if they have also explicitly selected a backend, but if they have not selected a backend then they must only set one backend's configurations.

[github-actions[bot]]

This issue hasn't seen activity in 3 months. If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in two weeks.

[github-actions[bot]]

This issue was closed due to lack of activity. Feel free to reopen if it's still relevant.