add minio server's api call to set user's password

[wejdross]

it's important feature as we had a bug where password was lost/broken for some reason and caused operational issues in our cluster.

Summary

• Short summary of what's included in the PR
• Give special note to breaking changes

Checklist

• Categorize the PR by setting a good title and adding one of the labels:
  bug, enhancement, documentation, change, breaking, dependency
  as they show up in the changelog
• Update tests.
• Link this PR to related issues.

[zugao]

Will this work with a new provisioning of Minio instance? When the secret is still not there?
Also what happens if someone updates the secret in the cluster? Do we set an empty user and password all the time?

[wejdross]

> Will this work with a new provisioning of Minio instance? When the secret is still not there? Also what happens if someone updates the secret in the cluster? Do we set an empty user and password all the time?

When we create a minio user we receive secret from minio server and set it into writeConnectionSecret Secret. Sometimes minio has some weird, unexplained hickup and lose this pasword somewhere (or maybe someone reset that manually) - we don't know. This PR simply takes whatever is in the already present secret and set is as a user's password.

It's also in if clause checking for deletion timestamp to prevent situations when user is set to be deleted and secret is gone, but there is still one last reconciliation of observe func.

[zugao]

When we create a minio user we receive secret from minio server and set it into writeConnectionSecret Secret. Sometimes minio has some weird, unexplained hickup and lose this pasword somewhere (or maybe someone reset that manually) - we don't know. This PR simply takes whatever is in the already present secret and set is as a user's password.

I understood how the code works. My concern was if a new instance will work with this approach? Have you tried it?

Also for my second concern:

Also what happens if someone updates the secret in the cluster? Do we set an empty user and password all the time?

Instead of getting the user and password from the claim namespace wouldn't it be better to get it from the instance namespace where the customer does not have access to? In that case the credentials will not be altered by the end user. @Kidswiss don't we save a copy of the secret in syn-crossplane or in instance namespace?

[Kidswiss]

Instead of getting the user and password from the claim namespace wouldn't it be better to get it from the instance namespace where the customer does not have access to? In that case the credentials will not be altered by the end user. @Kidswiss don't we save a copy of the secret in syn-crossplane or in instance namespace?

The provider can only get that value from the WriteConnectionSecretToReference field, so this is correct. Whether this is set to the claim namespace or not is handled in the composition and not in the provider's scope. See here: https://github.com/vshn/appcat/blob/master/pkg/comp-functions/functions/miniobucket/miniobucket.go#L95

EDIT: linked the wrong resource.

[Kidswiss]

I see that you just apply the credentials unconditionally. Which is fine, but I would move it to the update function. The observe function should determine the state of the external object (e.g. a check if the passwords match or not) and then the update function should handle the actual change. Otherwise, we mix things up.

Also, Gabriel's concern should also be solved with that, as the Update function is only called after the creation.

[Kidswiss]

LGTM