-
Notifications
You must be signed in to change notification settings - Fork 147
Add guide for XR connection details in v2 #1034
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Signed-off-by: Jared Watts <[email protected]>
✅ Deploy Preview for crossplane ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
| if "accesskey-0" in req.observed.resources: | ||
| accesskey0_conn = req.observed.resources["accesskey-0"].connection_details | ||
| if "username" in accesskey0_conn: | ||
| secret_data["user-0"] = base64.b64encode(accesskey0_conn["username"]).decode("utf-8") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
feel free to offer better ways to do this in python - i'm not a python person and i landed on this solution because it was the only one i could get to work 😇
is there a better approach we could take here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
using stringData instead of data so you don't need the base64
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i had tried that for awhile and couldn't get it to work either, but I'll definitely try it again! 🙏
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well i'm not sure what i was doing before, but yes sir stringData does in fact work 😅
|
ah, should have run |
haarchri
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for the guide - few small things
| if "accesskey-0" in req.observed.resources: | ||
| accesskey0_conn = req.observed.resources["accesskey-0"].connection_details | ||
| if "username" in accesskey0_conn: | ||
| secret_data["user-0"] = base64.b64encode(accesskey0_conn["username"]).decode("utf-8") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
using stringData instead of data so you don't need the base64
| metadata: | ||
| namespace: default | ||
| name: my-keys | ||
| spec: {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would expect users to be able to provide a secret name as input. Otherwise, it’s hard to use the secret in a Deployment (for example, as an input), since it gets a random name by default. Just saying.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
spec.writeConnectionSecretToRef.name
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking it was OK because the secret gets labeled with the XR name, so it should be easy to find that way. I was trying to avoid adding more config and more logic, but I can see a case for having more control over where the secret gets created and thus easier discoverability of it to consume it.
This is also probably related to what namespace do we use when the XR is cluster scoped. I'll consider how to improve this!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i've included an optional .spec.writeConnectionSecretToRef.name to the XRD schema, the examples show how to use it, and the compositions use this name if it is provided.
| names: | ||
| kind: UserAccessKey | ||
| plural: useraccesskeys | ||
| scope: Namespaced |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any difference when creating a cluster-scoped XR? Which namespace is used to create the Secret? The Crossplane default namespace?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
very good question, that was on my TODO list to figure out later 😂 - may as well deal with it now. I have a feeling this example wouldn't work with a cluster scoped XR since the namespace for the secret isn't being provided in the composition, and Crossplane won't default it for us like it does for namespaced XRs (using the XR's namespace).
I'll dig in deeper!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actually, i wonder how the namespaced MRs work in a cluster scoped XR, if you don't provide the namespace for them in the composition. I assume it'd be the same problem as I expect for the secret resource, i.e. they would fail to be created because they have no namespace specified and crossplane won't default one for them 🤔
I will probably end up just including a namespaced example in this guide, as opposed to having both a cluster and namespaced example, but then have a "tip" or "note" callout box that says for cluster scoped XRs you need to be sure to set namespaces for any namespaced resources like the Secret.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is what i ended up doing. the main example we are providing in this guide is namespaced and shows how to provide a name for the secret on the XR that gets plumbed via the compositions to the composed secret.
i've added a tip box that calls out how to take this information and extend it to also take in a namespace and set it on the composed resources in the cluster scoped XR scenario. I think that's a good balance here!
ezgidemirel
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Much-needed guide @jbw976, thanks for preparing it!
* use stringData instead of base64 encoding ourselves for function-python * expose a writeConnectionSecretToRef.name field for the XR so the secret name can be set if desired * update all compositions to safely handle the secret name existing or not * add note with guidance about cluster scoped XRDs and setting the namespace for composed resources Signed-off-by: Jared Watts <[email protected]>
|
@haarchri @ezgidemirel i pushed 95bc6b0 that incorporates all the feedback you all provided so far, take another look! (still another commit coming to appease vale, but that shouldn't have functional differences i hope 🤪) |
Signed-off-by: Jared Watts <[email protected]>
|
Sweet, with 5be0d39 Vale is now passing again! ✅ |
Thanks @jbw976, this is much clearer now! |
Signed-off-by: Jared Watts <[email protected]>
Signed-off-by: Jared Watts <[email protected]>
Signed-off-by: Jared Watts <[email protected]>
|
Alrighty, I think this PR is all good from my side! The PR checklist is complete, Vale is happy, master has been synced to v2.1/v2.0, and I did a final quality testing run through all languages ✅ |

This PR adds a new guide for how to expose connection details for XRs in v2. As described in #1001, since XR/XRDs no longer have native connection details support, composition authors must manually compose a secret with their desired connection details (if they want them at all).
This is a tutorial based guide that walks through an example of composing an IAM User and two AccessKeys for that user. The composition also composes a secret that aggregates the username/password for both users into a single connection secret.
Similar to the getting started with composition guide, this connection details guide has support for function-go-templating, function-python, and function-kcl.
Support for function-patch-and-transform will be added to this guide once that function is updated with further support for composing connection details secrets - it is not possible currently and a code change is required.
Part of #1001
TODO: