Connect to functions not manged by Crossplane about crossplane

[haarchri]

think we have this topic for future improvements for runtime-config https://github.com/crossplane/crossplane/blob/master/design/one-pager-package-runtime-config.md#future-improvements

[negz]

We would like to have Crossplane use functions that are managed or deployed by it.

@MisterMX I just noticed - should this say "aren't managed or deployed"?

[negz]

think we have this topic for future improvements for runtime-config

To be explicit, we have no intention to support for alternative package deployment in core at this time.

As part of the runtime config work @haarchri linked, we added a --package-runtime flag to Crossplane. You can run Crossplane with --package-runtime=External. When you do:

• The package manager will produce (e.g.) a FunctionRevision when you install a Function.
• The package manager won't reconcile the FunctionRevision to actually install the function.

As outlined in the linked doc, the idea is that:

• The Crossplane package manager is opinionated about how packages are installed.
• If you don't like those opinions, you can disable the package manager and supply your own alternative.

So I believe today you could use --package-runtime=External and provide your own controller that populated status.endpoint to point to a remote function installed by some other system.

[negz]

Perhaps a bit meta, but I could imagine using a middleware function for this. i.e. You could deploy a function that proxied requests to some other function (or function-like service) running elsewhere.

[MisterMX]

We would like to debug functions built with https://github.com/crossplane/function-sdk-go in a real-life scenario which includes the usage of environments and especially providers. Now, we do have interdependencies between our MRs where we have to wait for one MR to be ready before creating another MR.

crossplane beta render does not work for us here because it is a one-time invocation that basically just mocks a Crossplane function call and prints the results to stdout. We are unable to simulate production environment with it because we cannot provide an e2e environment. We need Crossplane to call our function that is running in debug mode on a devs local machine and apply the rendered resources to K8s to have them picked up by providers and be reconciled.

Basically, the idea we have come up with after some thoughts is

1. Have the function run in local debug mode to be able to set breakpoints etc.
2. Have Crossplane run next to it on the same machine
3. Create claims and composites that are reconciled by Crossplane and trigger a function invocation
4. Have the rendered resources applied on the cluster and picked up by real providers

If --package-runtime=External already works (I did not have the time to try it yet) we only need #5454 to make fully qualified local dev setup.

I cannot say if a proxy works or not but it feels extremely complicated because you need multiple components working together: Crossplane, a proxy, a local stub that connects to the proxy (since my machine is not reachable from within the cluster) and the function itself. I would really prefer #5454 to that if possible ...

[negz]

@MisterMX Thanks for the context.

I feel okay adding an --insecure flag to disable TLS. Per #5454 (comment) though, I don't think it should apply only to functions.