Proposal: add debug-level file captures for rendered gotemplates

[gberche-orange]

Is your feature request related to a problem? Please describe.

As a service author

• in order to quickly identify invalid gotemplate outputs
• I need a debug mode which provides the recent rendered gotemplates by resources

Describe the solution you'd like

A debug flag which enables saving in a temporary directory (say /tmp/sf-rendered-templates) the recently rendered templates, for instance with scheme

• sf-service-instance-<service-instance-guid>-<value>.out
• sf-service-instance-<service-instance-guid>-<template>.out
• sf-service-binding-<service-binding-guid>-<value>.out
• sf-service-binding-<service-binding-guid>-<template>.out

with template being one of: sources, status, provision, unprovision, bind, unbind

The files would be overriden by each reconciliation loop. This enables a service author to use a watch cat sf-service-instance-<service-instance-guid>-<template>.out to see the rendered changes following a gotemplate change

A periodic job could remove files older than a threshold, so that transient service instances (typically provisionned and unprovisionned by automated tests) would not fill up the file system.

Describe alternatives you've considered

• using the gotemplate-test tool mentionned in https://github.com/cloudfoundry-incubator/service-fabrik-broker/blob/master/docs/Interoperator-templates.md#debugging
  • this still requires a fair amount of setup for each instance
• plain debug traces with rendered templates: given the pace of reconciliation loops, this would be too chatty and would prevent use of logs
• kubectl based script to continuously inspect and dump interooperator CRs:
  • SFServiceInstance status with state and resource (content of the sources template)
  • SFServiceBinding status with state and secretRef (content of the bind template)

Additional context
Add any other context or screenshots about the feature request here.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/180636109

The labels on this github issue will be updated when the story is started.

[gberche-orange]

I was desperately trying to debug why some resources specified in the sources template don't seem to be detected/watched by the binding controller and thus fail to be used in the status binding section.

As a workaround for the lack of capture of rendered templates, I introduced faults in the status template to basically dump the watched resources.

In the traces, I see the following but this did not help.

provisioner-847f9b87c5-hwvr5 2021-12-17T17:07:12.359Z    INFO    controller    Starting EventSource    {"reconcilerGroup": "osb.servicefabrik.io", "reconcilerKind": "SFServiceBinding", "controller": "bind
ing", "source": "kind source: /v1, Kind=Secret"}

I finally end up on https://github.com/cloudfoundry-incubator/service-fabrik-broker/blob/master/docs/Interoperator-templates.md#sources precising

Similarly the binding controller of interoperator watches on a resource only if the resource is created/updated by interoperator during binding and the resource is specified in the sources template.

In my use-case, I need to lookup a resource created as a side effect of the resource provisionned by interoperator, but not directly listed in the bind template.

This is similar to the postgresql example at https://github.com/cloudfoundry-incubator/service-fabrik-broker/blob/master/docs/Interoperator.md#sfplan where the secret seems created as a side effect of the postgresql resource being created, but is not listed in the provision or bind template.

@anoopjb @vinaybheri would you confirm that a resource not listed in the provision or bind template would be not watched (even if specified in the sources template, and available on the K8S cluster), and as a result would not being available as a variable in the status template ?

[gberche-orange]

A Secret resource (created as a side effect of a fluxcd2 Kustomization resource provisionned by the bind template) was not available in the status template when provisionned in a different namespace than the one where the SFServiceBinding is. After provisionning this Secret resource in the same namespace as the SFServiceBinding, the secret is now properly available in the status template.

[Pooja-08]

@anoopjb @vinaybheri would you confirm that a resource not listed in the provision or bind template would be not watched (even if specified in the sources template, and available on the K8S cluster), and as a result would not being available as a variable in the status template ?
Hi @gberche-orange , yes as mentioned in the interoperator document, only the resources created as part of provision/bind operation and specified in the sources template, will be watched.

[gberche-orange]

@Pooja-08 thanks for the follow up. I indeed observe that a secret created as a side effect of a resource created by interoperator (say apiVersion: acid.zalan.do/v1 and kind: postgresql) is indeed available in the status template if it was provisionned in the same namespace as the SFServiceBinding

[anoopjb]

Thank you for the proposal @gberche-orange 👍
We agree that at least a trace log of CR is required to ease the sfplan template development. Unfortunately we cannot tackle this soon. We are open for contributions.