Improve rootless container Function debugging

[negz]

What problem are you facing?

We've heard from a few folks that it's hard to determine what's going wrong when their Composition Functions don't work. This is an open-ended issue to capture ideas to improve the situation.

How could Crossplane help solve your problem?

Some things to start with:

• Document how to use xfn run and/or docker run to debug a Composition Function in isolation.
• Have Crossplane or xfn print the FunctionIO objects it sees to debug logs.
• Improve the error message returned when the OCI runtime can't run the function binary for some reason (e.g. wrong architecture)

[AtzeDeVries]

Already a note here. I test stdin with an example FuctionIO via

cat tests/input3.yaml | docker run -i  --rm  xfn

[blut]

Another interesting output to have available would be e.g. debug output of the function run.
Say my function is successful with most requests but fails on a specific resource in production, I'd want to enable debug output, but where would this be logged?
In case my function fails gracefully, I can add the error to the status field, but in case of a crash, where would this information be added? I would expect it to be logged in at least in the crossplane-xfn container.

[jaylevin]

Already a note here. I test stdin with an example FuctionIO via

cat tests/input3.yaml | docker run -i  --rm  xfn

This is a good way to debug locally, but I think ideally, with --debug flag set, the crossplane-xfn sidecar container should log the input and output FunctionIO objects before and after the function runs.

[muvaf]

I think if the --debug flag is set, the runner should print the Stderr no matter whether the container ran successfully or not. Right now it never prints stderr, so it's quite hard to get to see an actual FunctionIO file passed in by Crossplane.

[dalton-hill-0]

In the mean-time, you can debug by adding entries in FunctionIO.results.

For example, you can marshal the entire FunctionIO object and add it as a string in FunctionIO.results[x].message

With debugging on, this will appear in the crossplane-system/crossplane pod logs for the container crossplane.

[jbw976]

cool idea @dalton-hill-0, thanks for sharing! are you already doing this in your XFN's? feel free to drop a code snippet here for others to reference 😎

[dalton-hill-0]

@jbw976
Thanks Jared.
"are you already doing this in your XFN's" -> Yes, but I'm only beginning to learn Crossplane, so it is just a test environment.

Here is a code snippet for GoLang that adds the FunctionIO object to itself in a result.

// (import for cpv1a1)
// cpv1a1 "github.com/crossplane/crossplane/apis/apiextensions/fn/io/v1alpha1"

// SaveStateToResult saves marshalled FunctionIO object to FunctionIO.results[n+1].message
func SaveStateToResult(fio *cpv1a1.FunctionIO) error {
	bs, err := json.Marshal(fio)
	if err != nil {
		return err
	}
	r := cpv1a1.Result{
		Severity: cpv1a1.SeverityNormal,
		Message:  string(bs),
	}
	fio.Results = append(fio.Results, r)
	return nil
}

Note: To read the contents of the FunctionIO.result[x].message easier (when looking at stdout), you can copy the string and pass it to jq with the following args.
<clipboard paste> | jq '. | fromjson'

[jbw976]

That will likely be helpful to other folks using XFNs in their current state, thanks for taking the time to share that snippet @dalton-hill-0! 💪

[github-actions]

Crossplane does not currently have enough maintainers to address every issue and pull request. This issue has been automatically marked as stale because it has had no activity in the last 90 days. It will be closed in 14 days if no further activity occurs. Leaving a comment starting with /fresh will mark this issue as not stale.

[ytsarev]

/fresh still relevant

[negz]

I've moved this to https://github.com/crossplane/function-runtime-oci because I think a lot of it is coupled with the rootless container implementation. Under the new design, functions are just pods and can emit logs like any other pod to help with debugging.