Update resources proto with GetSecretNames and CreateSecret. #3914
Conversation
| "SECRET_TYPE_OPAQUE_UNSPECIFIED", | ||
| "SECRET_TYPE_SERVICE_ACCOUNT_TOKEN", | ||
| "SECRET_TYPE_DOCKER_CONFIG", | ||
| "SECRET_TYPE_DOCKER_CONFIG_JSON", | ||
| "SECRET_TYPE_BASIC_AUTH", | ||
| "SECRET_TYPE_SSH_AUTH", | ||
| "SECRET_TYPE_TLS", | ||
| "SECRET_TYPE_BOOTSTRAP_TOKEN" |
There was a problem hiding this comment.
Adding SECRET_TYPE_ as a prefix here produces code with redundant names like SecretType_SECRET_TYPE_OPAQUE_UNSPECIFIED (in cmd/kubeapps-apis/gen/plugins/resources/v1alpha1/resources.pb.gobelow).
Not a big problem at all, mainly readability. Couldn't we avoid it? Maybe it is a requirement for the API?
There was a problem hiding this comment.
Yeah, I know it feels it (and I did originally do it without the prefix), but then buf lint fails as this is one of their lint rules. They explain why here: https://docs.buf.build/lint/rules#enum_value_prefix
absoludity
force-pushed
the
3896-namespaces-via-plugin-3
branch
from
ca92864
to
f12f974
Compare
absoludity
force-pushed
the
3896-secrets-backend
branch
from
bc5ea31
to
848138a
Compare
Signed-off-by: Michael Nelson <minelson@vmware.com>
Signed-off-by: Michael Nelson <minelson@vmware.com>
Signed-off-by: Michael Nelson <minelson@vmware.com>
absoludity
force-pushed
the
3896-secrets-backend
branch
from
848138a
to
12cf536
Compare
| // Context | ||
| // | ||
| // The context for which the secret names are being fetched. | ||
| kubeappsapis.core.packages.v1alpha1.Context context = 1; |
There was a problem hiding this comment.
I used the same for the SA method... but I'm wondering now whether we should keep a resources-plugin-specific Context message to decouple it from the packages API.
There was a problem hiding this comment.
The resources plugin is coupled because of it's main purpose: to get the resources for an installed package. So even if we add a separate context, the module is still coupled by design for that one method?
Signed-off-by: Michael Nelson minelson@vmware.com
Description of the change
Adds the proto messages and rpc's for both GetSecretNames and CreateSecret.
The current dashboard code using
shared/Secretis just the add/update AppRepository form. It currently pulls the actual secret to re-use in the form, which I'm going to change when updating the dashboard, so that we don't need to pull the actual secret data. This allows the resources API to restrict itself to getting the secret names (with types), and creating a secret. The user will still be able to update a value, but not by editing the existing value (which is in a password input type anyway).Implementation of these methods to follow.
Benefits
Possible drawbacks
Applicable issues
Additional information