[13:59:14] <elukey>	 brouberol: o/ 
[13:59:26] <elukey>	 do you have a min for a brainbounce about https://gerrit.wikimedia.org/r/c/operations/deployment-charts/+/1076711 ?
[14:00:35] <elukey>	 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] <elukey>	 for example, in _config.yaml I have
[14:01:15] <elukey>	       mwapi_req:
[14:01:16] <elukey>	         body: {{ "'{{" }} default(request.query, {}) {{ "}}'" }}
[14:01:51] <elukey>	 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] <elukey>	 and when I run helm template I see parse error at (kartotherian/templates/deployment.yaml:63): unexpected "(" in operand
[14:03:21] <elukey>	 the "(" is the one after default
[14:04:05] <elukey>	 there are other similar issues, it seems as if those are interpreted as commands for some reason
[14:06:31] <elukey>	 and base.helper.resourcesDataChecksum explicitly invokes tpl(etc..) but I am not 100% clear why it causes errors
[14:08:33] <elukey>	 "error calling include: template: kartotherian/templates/vendor/base/helper_1.1.3.tpl:72:27: executing "base.helper.resourcesDataChecksum" at <tpl (include (print .Root.Template.BasePath .resourceFilePath) .Root) .Root>: error calling tpl: error during tpl function execution for ""
[14:15:34] <brouberol>	 hello hello!
[14:15:40] <brouberol>	 let me have a look
[14:16:26] <brouberol>	 can you point me to you changes?
[14:16:29] <brouberol>	 *your
[14:20:27] <brouberol>	 actually, let me try to render things locally with `body: "{{ and }}"`
[14:22:03] <elukey>	 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] <elukey>	 I haven't filed my changes yet, working locally
[14:23:26] <elukey>	 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] <brouberol>	 ok, I can reproduce the issue with a test configmap with
[14:23:26] <brouberol>	 data:
[14:23:26] <brouberol>	   config.yaml: |
[14:23:26] <brouberol>	     body: {{ "'{{" }} default(request.query, {}) {{ "}}'" }}
[14:23:41] <elukey>	 exactly yes
[14:23:45] <brouberol>	 `template: gotpl:1525: unexpected "(" in operand`
[14:24:39] <elukey>	 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] <elukey>	 this is a borderline case, but we have a lot of nodejs/service-runner things :D
[14:25:12] <brouberol>	 thanks, I really had no idea
[14:26:28] <brouberol>	 💡would you be able to render the actual content of `body` with a template?
[14:26:38] <elukey>	 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] <elukey>	 so the goal is to have 
[14:27:37] <elukey>	 body: {{ default(request.query, {}) }} in the final config.yaml on the container
[14:28:17] <elukey>	 verbatim, because it is interpreted by service-runner itself
[14:28:44] <elukey>	 there is basically some overlapping between tpl that renders the file and what the service inteprets from the config-file
[14:31:18] <brouberol>	 that's my understanding as well
[14:31:29] <elukey>	 what's your idea about the template?
[14:32:21] <brouberol>	 nah, forget it, I wouldn't even call it an idea
[14:33:38] <brouberol>	 what we could try to do, is basically 2 nested layers of  {{ "'{{" }} 
[14:33:59] <brouberol>	 and which point I'm reconsidering my career as an engineer and am seriously looking at becoming a pole dancer
[14:34:29] <elukey>	 I'd follow you yes, not sure how much success we'll have though
[14:37:18] <brouberol>	 there's only way to find out
[14:37:51] <brouberol>	 so, `body: {{ "{{ \"{{\" }}" }} default(request.query, {}) {{ "{{ \"}}\" }}" }}` currently renders to
[14:37:51] <brouberol>	     body: {{ "{{" }} default(request.query, {}) {{ "}}" }}
[14:37:51] <brouberol>	 after having passed through all the rendering 
[14:41:36] <elukey>	 I tried it, and with helm  template etc.. I get body: {{ "{{" }} default(request.query, {}) {{ "}}" }}
[14:42:21] <brouberol>	 yep, I', getting the same,. which then got me on the path of sprinkling some `tpl` in there
[14:42:27] <brouberol>	 it's not going great
[14:43:03] <elukey>	 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] <elukey>	 seems to be a little mess, don't want to derail your afternoon
[14:46:32] <brouberol>	 nah don't worry
[14:46:40] <brouberol>	 I'll keep playing with it for a bit
[14:57:22] <elukey>	 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] <brouberol>	 because tpl tries to render `{{ default(request.query, {}) }}`, and `default` is a valid gotpl function name, I guess? 
[15:02:28] <brouberol>	 but used here in a context it does not understand
[15:06:21] <brouberol>	 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] <elukey>	 (back sorry I was in a meeting)
[15:10:08] <elukey>	 so tpl() already sees the rendered version of the config-map, right
[15:11:06] <elukey>	 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] <brouberol>	 it.. depends. For example, in airflow, we have values referencing other values, so `tpl` renders all values into their "final" form
[15:11:50] <brouberol>	 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] <brouberol>	 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] <elukey>	 definitely yes, thanks a lot!
[15:14:41] <brouberol>	 np!
[15:40:58] <elukey>	 ok I may have something
[15:41:26] <elukey>	 in helper.tpl we have
[15:41:27] <elukey>	 {{- $renderedResources :=  tpl (include (print .Root.Template.BasePath .resourceFilePath) .Root) .Root }}
[15:42:28] <elukey>	 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] <elukey>	 if I change it to
[15:43:53] <elukey>	 {{- $renderedResources :=  tpl (print .Root.Template.BasePath .resourceFilePath)  .Root }}
[15:44:25] <elukey>	 then it works, because tpl gets to render the real template, not what comes after include
[15:44:49] <elukey>	 but probably the chain tpl -> include means something, maybe in the airflow context?
[16:01:53] <elukey>	 all right, leaving to pick up the toddler, I'll read later!
[19:07:40] <brouberol>	 I'll experiment on my side next week, thanks!