Replace Config CRD

[unguiculus]

I'm trying to help get the PR for a Ark Helm chart merged.

helm/charts#3795

Over at the chats repo we have a CI that lints and install charts. I figured this is not possible with Ark. I'll have to wrap the deployment into an if statement that makes sure it is not created by the CI job because Ark won't come up if it doesn't have a cloud provider and credentials set.

Now, since Ark has its config separate in the Config CRD, I find that kind of strange. Actually, this mean the config is spread over two places. I understand that this separation is probably necessary because the secret needs to be mounted. But then why separate it at all instead of having a bunch of CLI args and everything in the deployment?

On the other hand, I like the separate Config resource. I wonder if there is a way to also reference secrets in there. I guess the initial Ark deployment would then have to be turned into a little daemon whose sole purpose is to boostrap real Ark server deployments based on the complete config mounting the configured secret. In theory this would allow boostrapping multiple Ark servers with different configs. I think, this is when a separate config really would make sense. Has such a setup been discussed? Would that make sense?

[bhack]

Any other specific requirement for the imminent 0.9 release?

[ncdc]

@unguiculus thanks for your feedback! We are eventually going to remove the Config resource and replace it with multiple types that we'll use to configure backup storage and volume storage. Anything that's left over will become command line flags. This is planned for our v0.10.0 release, which is a couple of months away.

@bhack we'll be releasing v0.9.0.alpha.1 this week and we'll have more information available once it's out.

[rosskukulinski]

Related to #103 and the Backup/SnapShot Target APIs.

[skriss]

@carlisia:

Our Config CRD has a bunch of fields that we want to either move into other CRDs or switch to server flags, so we can get rid of the Config type.

PersistentVolumeProvider and BackupStorageProvider will be replaced with the backup locations work.

BackupSyncPeriod, GCSyncPeriod, ScheduleSyncPeriod, PodVolumeOperationTimeout are all polling intervals/timeouts. I think the first and last probably need to become server flags, while the middle two (gcSyncPeriod and scheduleSyncPeriod) should be converted to constants where they're used and not exposed as configurable values.

ResourcePriorities should remain configurable - I think this can be a server flag (but let me know before you start on this, want to think about it a little bit).

RestoreOnlyMode will eventually be replaced by the accessMode field on backup locations. We need to decide what to do with it in the interim. I think moving it to a server flag in the short-term would be fine, but let me think on it too.

[carlisia]

In talking to @skriss , we are going to make ResourcePriorities take a value that is a comma-separated list, and RestoreOnlyMode will be a server flag for now (it’ll be temporary).

[ncdc]

I think we'll need to have separate resource priorities for backups and restores. #586

[skriss]

sure, so let's just add the --restore-resource-priorities for now since that's what we currently offer, and then we can do the other one later.

[carlisia]

Copy that 👍.