size: xxxxXusers is not working when you want to scale

size: xxxxXusers is not working when you want to scale

[jwilander]

I like that solution 👍 Only point I'd make is to make sure we document that field as write-only so that it's clear to users of the spec

[gabrieljackson]

@Szymongib, after thinking about this for a bit I am pretty sure it's a great solution!

It meets all of the criteria that I would be looking for:

1. By looking at the spec, I could see definitive values for the resources whether I had overridden any or not
2. Setting a new size would update all the values
3. Values could be manually tweaked after an initial size value was chosen.

I think this could really work well. What do you think @jwilander?

[gabrieljackson]

Hello @Born2Bake,

Thanks for bringing this to our attention. You are correct that we do want the operator to scale mattermost installations up and down on demand.

I just tested this and your findings seem to be correct where sizeA -> sizeB does not properly update the underlying resource counts. We will look into this and correct it.

Keep in mind that the size values are always overridden by the specific resource and replica settings. i.e. if you change either of these the operator will scale up or down as requested.

https://github.com/mattermost/mattermost-operator/blob/master/pkg/apis/mattermost/v1alpha1/clusterinstallation_types.go#L30-L36

The same thing goes for the database and minio spec settings.

[Szymongib]

Hi @gabrieljackson,
I was thinking that the spec.Size field could be treated as a write-only field.

Setting the field would override Replicas and Resources to appropriate values no matter if they were set manually, but the field itself would not be preserved on the CR, therefore further overrides of Replicas or Resources would not be discarded and they would not be in conflict with the spec.Size field.

The Kubernetes leverages such behavior in for example Secrets, where stringData field is a write-only field that on write is merged with data and no longer present on the Secret object.

Let me know what do you think about such approach!