-
Notifications
You must be signed in to change notification settings - Fork 183
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow tag values containing commas and equal sign #2323
Comments
this should be fixed by #2246 in v1.30.1, v1.29.5, what is your csi driver version? @dominiquehunziker |
nvm, that looks like k8s yaml config parsing issue |
what about this solution? if |
I'm not sure I follow. In your example the tags parameter now does not represent a key/value mapping (or it now only contains 2 keys without a value)? The problem is not the encoding of the tags parameter (plain text vs. base64), but how the value is parsed. To my understanding if you first base64 decode the tags parameter you would then still apply the same old parsing logic, which would lead to the same result, no? Or did I misunderstand something? The base64 I just picked up as an example where one might have a |
I think we could add a new parameter, e.g. |
From my perspective the function which would have to be modified (if the existing field is used) is ConvertTagsToMap. What I'm looking for would translate into the testcase in TestConvertTagsToMap {
desc: "new testcase",
tags: "???", // what needs to be the input?
expectedOutput: map[string]string{
"tag-1": "aGVsbG8=",
"tag-2": "value-2, value-3",
},
expectedError: false,
}, Naturally, a new parameter can be introduced in which case a new function with equivalent semantic (convert string to map) would be required. This could be the proposed parameter My proposal was to either enhance ConvertTagsToMap to allow escaping Alternatively, a new parameter with a different parsing logic or a parameter which can be used to configure the parsing logic of the existing func NewConvertTagsToMap(tags, tagFormat string) (map[string]string, error) {
switch tagFormat {
case "Yaml":
return ConvertYamlTagsToMap(tags)
default:
return ConvertTagsToMap(tags) // default to old parsing logic
}
}
func ConvertYamlTagsToMap(tags string) (map[string]string, error) {
m := make(map[string]string)
err := yaml.Unmarshal([]byte(tags), m)
return m, err
} |
@dominiquehunziker what about adding a new parameter apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: managed-premium-retain
provisioner: disk.csi.azure.com
parameters:
skuName: Premium_ZRS
tags: 'tag-1="aGVsbG8=";tag-2="value-2, value-3"'
tagValueDelimiter: ";" |
That sounds like a good idea and should address my need for comma separated tag values. Regarding for _, tag := range s {
kv := strings.SplitN(tag, TagKeyValueDelimiter, 2)
if len(kv) != 2 {
return nil, fmt.Errorf("Tags '%s' are invalid, the format should like: 'key1=value1,key2=value2'", tags)
}
... Or would you leave the logic as is? For my use-case I don't currently require |
I think adding a new parameter |
/kind feature |
Currently, it is not possible to create tags with a value that contains
,
or=
as this breaks the parsing logic for thetags
parameter.It would be great, if support for values with
,
and=
can be added. For the previous (non functioning example) the desired result would bewhere
tag-1
could be a base64 encoded value with=
padding ortag-2
could be a comma separated list.I'm uncertain what would be possible solutions as changing the parsing logic might change existing behavior. Possible options I can imagine are:
=
the logic could be relaxed to only split on the first=
and treat everything afterwards as the value. Similar to how query strings are parsed in URIs.,
and=
, i.e.,tags: 'tag-1=aGVsbG8\=,tag-2=value-2\, value-3'
,
or=
, i.e.,tags: 'tag-1="aGVsbG8=",tag-2="value-2, value-3"'
. Similar to how data with commas in CSV is handled.tags
parameter, such that a JSON or YAML string could be passed. For exampleThe text was updated successfully, but these errors were encountered: