Closed mxmxchere closed 4 months ago
chess-knight
commented
5 months ago IMHO apart from the appcred issue, we should allow the namespace override. E.g. by --set namespace=custom, and then appropriate handling of {{ .Values.namespace }} in the templates.
chess-knight
commented
5 months ago However if an application credential is used, the hardcoded value "cluster" is used for the new namespace.
If I see correctly, not a "cluster" but appcred-{{ substr 0 10 .Values.clouds.openstack.auth.application_credential_id }} is used.
mxmxchere
commented
5 months ago I think you are describing the state in the repo, i referred to the state in the release.
chess-knight
commented
4 months ago I think you are describing the state in the repo, i referred to the state in the release.
Ok thanks, I see it now https://github.com/SovereignCloudStack/cluster-stacks/blob/c35026219a9a4c89c99397cde2799e675ec3290d/providers/openstack/alpha/1-28/csp-helper-chart/templates/_helpers.tpl#L13-L26
I think using appcred_id as a namespace is fine, but I find that not only a combination of appcredID and secret works but also the combination of appcredName, secret, username and user_domain_name according to the docs, so it has to be considered as well and probably application_credential_name used instead then.
Also, I see auth.project_name and AFAIK the project_name doesn't need to be specified(at least my OpenStack cli works with only project_id). We should default to auth.project_id there.
Moreover, in both cases, user_domain_id can be used instead of user_domain_name.
The last combination for username/password auth that I tried(OpenStack cli) and works for me, is a combination of project_name + user_domain_name + project_domain_name. It also works with _id instead of _name.
So, IMO logic should be updated accordingly but this issue is probably not about that but only for namespace creation in case of application credentials. So I suggest the namespace override option in https://github.com/SovereignCloudStack/cluster-stacks/issues/46#issuecomment-2011738889 as well as using appcredID as the namespace. We can also think of a fallback to {{ .Release.Namespace }} if all other ways how to create a namespace will fail.
mxmxchere
commented
4 months ago Roman thanks a lot for writing together all the information about possible combinations with openstack credentials.
My original idea was to simplify the user experience, but as we can not count on having the project_name there all the time it will get quite complicated to write down all the combinations and even more complicated to understand what is happening in which case.
What do you think about but providing one (and only one) method of providing the namespace?
I currently favor the following approach:
Write the following in the quickstart guide:
helm upgrade -i <tenant>-creadentials -n <tenant> --create-namespace csp-helper-chart -f clouds.yaml
That way it is a simple approach and the user will know what to expect and the chart will do it accordingly. Also it covers all combinations of clouds.yaml that work. We should also document that this should be done once per tenant.
chess-knight
commented
4 months ago I like your idea of letting users create a namespace according to their preferences.
The csp-helper-chart can be used to create secrets, namespace and clusterresourceset for each tenant/namespace.
The assumption is that a CSP will have one openstack project per kaas-customer and one corresponding dedicated namespace in the management cluster for the customer/tenant. When a "normal" clouds.yaml is used, the helper-chart extracts the project_name from the clouds.yaml (which can be used directly as values.yaml for the helmchart). However if an application credential is used, the hardcoded value "cluster" is used for the new namespace.