Add marketplace annotation to generated example manifests

[ezgidemirel]

Signed-off-by: ezgidemirel [email protected]

Description of your changes

This PR adds meta.upbound.io/example-group annotation to generated example manifests in the same file with the value of the target resource's "shortgroup/version/kind". Using this annotation, we can display these manifests together in the marketplace.

Fixes #65

I have:

• Read and followed Crossplane's contribution process.
• Run make reviewable to ensure this PR is ready for review.

How has this code been tested

Consumed it in provider-aws and generated example manifests. An example file is below:

apiVersion: iam.aws.upbound.io/v1beta1
kind: AccessKey
metadata:
  annotations:
    meta.upbound.io/example-id: iam/v1beta1/accesskey
  labels:
    testing.upbound.io/example-name: lb
  name: lb
spec:
  forProvider:
    pgpKey: keybase:some_person_that_exists
    userSelector:
      matchLabels:
        testing.upbound.io/example-name: lb

---

apiVersion: iam.aws.upbound.io/v1beta1
kind: User
metadata:
  annotations:
    meta.upbound.io/example-id: iam/v1beta1/accesskey
  labels:
    testing.upbound.io/example-name: lb
  name: lb
spec:
  forProvider:
    path: /system/

[ulucinar]

Suggested change

	annotationExampleGroup = "meta.upbound.io/example-group"
	annotationExampleGroup = "meta.upbound.io/example-gvk"

As the value format for this key, my suggestion would be:

<group>/<version>.<kind>

, or

<group>/<version>/<kind>

[ezgidemirel]

I updated the PR as <shortgroup>/<version>/<kind>

[muvaf]

I don't have a strong opinion, but using the CRD name could be easier for figuring out the association on the marketplace side, i.e. <plural kind>.<group> like instances.ec2.aws.upbound.io. Version is probably irrelevant since we don't publish examples for each version.

Or maybe we can just re-use the label we use for label selectors. @hasheddan what's the best way for you folks to set up the association?

[hasheddan]

Hey folks! So I would suggest going with meta.upbound.io/example-id and then using whatever grouping value you like. The way the Marketplace is planning to handle this is to take all resources with the same meta.upbound.io/example-id, combine them into a single document to be stored, and then show them on the examples page for every resource type in the group. So, for example, if you put meta.upbound.io/example-id: super-cool-example on a VPC and 3 Subnets, those four types together would be shown as a single example on both the VPC and Subnet examples page.

Let me know if there is additional functionality that y'all feel like this does not accommodate!

[ulucinar]

Hi @hasheddan,
One concern that we currently have with this scheme (where we use the the short group name instead of a fully qualified group name, e.g., iam instead of iam.aws.upbound.io) is that if multiple providers possess groups with the same short name, would we still be able to correctly group example manifests for shared kind names?

Short group names are unique among a provider and is this enough to correctly group dependencies while showing examples? We would like to prevent a situation where an iam.Role dependency in GCP from appearing as a dependency to an AWS resource. Is the grouping done in the context of a single provider or across all providers available in the market place?

[hasheddan]

Is the grouping done in the context of a single provider or across all providers available in the market place?

@ulucinar the grouping is done in the context of a single provider package version -- so, for example, upbound/provider-aws:v0.9.0 is it's own "examples namespace" :)

[ulucinar]

Thanks @ezgidemirel, lgtm.