(feat) Bundles v2: Implement Bundle Interface Document

[schristoff]

What does this change

When setting a sharing mode is turned on for installations we need a way to share param/outputs/creds between them so we can wire them together.

The way we are doing this without updating the cnab spec is by converting everything into a document (type interface). This document type is something CNAB already implements - so once we get to translating porter yaml -> cnab json we get a smiley face.

Problem:
I remember talking to Carolyn about issues with using the existing bundle.Parameters and bundle.Credentials and I recall it being about the required types needed passed into them (for example, path being required for parameters) but I don't remember where we left off with that.
I guess we'll see what happens when we get there.

#2548

Checklist

• [x ] Did you write tests?
• Did you write documentation?
• Did you change porter.yaml or a storage document record? Update the corresponding schema file.
• If this is your first pull request, please add your name to the bottom of our Contributors list. Thank you for making Porter better! 🙇‍♀️

Reviewer Checklist

• Comment with /azp run test-porter-release if a magefile or build script was modified
• Comment with /azp run porter-integration if it's a non-trivial PR

[schristoff]

/azp run porter-integration

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[schristoff]

Keeping Carolyn as a co-author on this for obvious reasons. Even months later, you're still the driving force behind this project @carolynvs ❤️

[schristoff]

/azp run porter-integration

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[schristoff]

oh i already did that

[devigned]

This isn't necessarily about this PR, but you may want to consider starting spans for more functions. For example, creating a logger is nice, but the span is still the same span as from the parent (I believe from looking at the implementation of LoggerFromContext), so the attributed log entries on the span will not have the localization to the function as one might expect.

I don't have enough depth to give a functional review. However, there are a couple superficial things that might be good to update, and one more widespread thing to consider, granularity of spans.

[devigned]

Suggested change

	defName := c.addDefinition(sourceParam.Name, kind, sourceParam.Schema, defs)
	p.Definition = c.addDefinition(sourceParam.Name, kind, sourceParam.Schema, defs)

[schristoff]

Right now I believe most of our stuff goes to stdOut, I would love to implement a structured logger so we could follow the span throughout multiple functions, appending more data, and being able to see exactly what func errors.
I believe right now because we abstract away our logging that implementing a structured logger wouldn't be a huge undertaking.

[schristoff]

Oh hey, this is new https://go.dev/blog/slog

[devigned]

Structured log is good, but tracing is better. Tracing is structured logs + causality through call hierarchy. This is probably going to be more apparent in the operator as stuff will be less going to stdout and more to some telemetry ingestion pipeline.