[13:59:14] brouberol: o/ [13:59:26] do you have a min for a brainbounce about https://gerrit.wikimedia.org/r/c/operations/deployment-charts/+/1076711 ? [14:00:35] I am creating a chart for kartotherian, a service-runner/nodejs based service, and this change causes some settings in config.yaml to fail rendering [14:01:14] for example, in _config.yaml I have [14:01:15] mwapi_req: [14:01:16] body: {{ "'{{" }} default(request.query, {}) {{ "}}'" }} [14:01:51] the part after body is an horror needed to render {{ and }} without being interpreted, we use the same in other configs (rec-api, push-notifications, etc..) [14:03:09] and when I run helm template I see parse error at (kartotherian/templates/deployment.yaml:63): unexpected "(" in operand [14:03:21] the "(" is the one after default [14:04:05] there are other similar issues, it seems as if those are interpreted as commands for some reason [14:06:31] and base.helper.resourcesDataChecksum explicitly invokes tpl(etc..) but I am not 100% clear why it causes errors [14:08:33] "error calling include: template: kartotherian/templates/vendor/base/helper_1.1.3.tpl:72:27: executing "base.helper.resourcesDataChecksum" at : error calling tpl: error during tpl function execution for "" [14:15:34] hello hello! [14:15:40] let me have a look [14:16:26] can you point me to you changes? [14:16:29] *your [14:20:27] actually, let me try to render things locally with `body: "{{ and }}"` [14:22:03] brouberol: sorry I had the wrong change, it should be https://gerrit.wikimedia.org/r/c/operations/deployment-charts/+/1074099/6/modules/base/helper_1.1.3.tpl [14:22:23] I haven't filed my changes yet, working locally [14:23:26] so {{- $renderedResources := tpl (include (print .Root.Template.BasePath .resourceFilePath) .Root) .Root }} causes config-maps with "default" "request" etc.. keywords to be interpreted, rather than considered as string [14:23:26] ok, I can reproduce the issue with a test configmap with [14:23:26] data: [14:23:26] config.yaml: | [14:23:26] body: {{ "'{{" }} default(request.query, {}) {{ "}}'" }} [14:23:41] exactly yes [14:23:45] `template: gotpl:1525: unexpected "(" in operand` [14:24:39] I am trying a variety of quoting but without much success, if we find a solution I'll apply it to all nodejs services so if/when they'll upgrade base:helper it will not break [14:25:01] this is a borderline case, but we have a lot of nodejs/service-runner things :D [14:25:12] thanks, I really had no idea [14:26:28] 💡would you be able to render the actual content of `body` with a template? [14:26:38] when adding new useful things it happens, I was puzzled at first since I didn't get what was failing from the very clear tpl failures that are printed [14:27:20] so the goal is to have [14:27:37] body: {{ default(request.query, {}) }} in the final config.yaml on the container [14:28:17] verbatim, because it is interpreted by service-runner itself [14:28:44] there is basically some overlapping between tpl that renders the file and what the service inteprets from the config-file [14:31:18] that's my understanding as well [14:31:29] what's your idea about the template? [14:32:21] nah, forget it, I wouldn't even call it an idea [14:33:38] what we could try to do, is basically 2 nested layers of {{ "'{{" }} [14:33:59] and which point I'm reconsidering my career as an engineer and am seriously looking at becoming a pole dancer [14:34:29] I'd follow you yes, not sure how much success we'll have though [14:37:18] there's only way to find out [14:37:51] so, `body: {{ "{{ \"{{\" }}" }} default(request.query, {}) {{ "{{ \"}}\" }}" }}` currently renders to [14:37:51] body: {{ "{{" }} default(request.query, {}) {{ "}}" }} [14:37:51] after having passed through all the rendering [14:41:36] I tried it, and with helm template etc.. I get body: {{ "{{" }} default(request.query, {}) {{ "}}" }} [14:42:21] yep, I', getting the same,. which then got me on the path of sprinkling some `tpl` in there [14:42:27] it's not going great [14:43:03] I can open the task, don't worry, I just wanted to know if you had any ideas to solve it quickly [14:43:13] seems to be a little mess, don't want to derail your afternoon [14:46:32] nah don't worry [14:46:40] I'll keep playing with it for a bit [14:57:22] the thing that I am trying to understand is why invoking it with tpl() fails, meanwhile a regular helm template render does not [15:02:18] because tpl tries to render `{{ default(request.query, {}) }}`, and `default` is a valid gotpl function name, I guess? [15:02:28] but used here in a context it does not understand [15:06:21] I'm not 100% sure, but I have a hunch it's not going to work. The tooling runs `tpl` to render the configmap and bse64 the "final" form, but it contains something that looks lkike gotpl with syntax errors [15:09:32] (back sorry I was in a meeting) [15:10:08] so tpl() already sees the rendered version of the config-map, right [15:11:06] but then it doesn't make much sense to me, I thought it would have taken _config.yaml or whatever file hosts the config-map and re-render it as helm does [15:11:14] it.. depends. For example, in airflow, we have values referencing other values, so `tpl` renders all values into their "final" form [15:11:50] but the `airflow` chart does enough black magic that I'd focus on making the vendored templates work for the majority of cases, and airflow would be doing its down thing [15:13:05] I'll be afk for a while, but I suggest 2 things. a) try to see whether you can make things work without the `tpl` in the `base.helper.resourcesDataChecksum` helper, and b) let's pair on it on monday? [15:14:36] definitely yes, thanks a lot! [15:14:41] np! [15:40:58] ok I may have something [15:41:26] in helper.tpl we have [15:41:27] {{- $renderedResources := tpl (include (print .Root.Template.BasePath .resourceFilePath) .Root) .Root }} [15:42:28] IIUC tpl gets what include provides, namely an already rendered config. Then it tries to interpret what's left, and in weird corner cases like service-runner's config we get failures [15:43:52] if I change it to [15:43:53] {{- $renderedResources := tpl (print .Root.Template.BasePath .resourceFilePath) .Root }} [15:44:25] then it works, because tpl gets to render the real template, not what comes after include [15:44:49] but probably the chain tpl -> include means something, maybe in the airflow context? [16:01:53] all right, leaving to pick up the toddler, I'll read later! [19:07:40] I'll experiment on my side next week, thanks!