Skip to content
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

Docs should take a "functions first" approach #791

Open
5 tasks
Tracked by #4951
jbw976 opened this issue Jul 3, 2024 · 1 comment
Open
5 tasks
Tracked by #4951

Docs should take a "functions first" approach #791

jbw976 opened this issue Jul 3, 2024 · 1 comment
Assignees
Labels
concepts/composition concepts/xfn content request Issues requesting new content docs User docs related issues and content enhancement New feature or request functions P1 Must fix, critical issues. Frequent or wide-spread user impact.

Comments

@jbw976
Copy link
Member

jbw976 commented Jul 3, 2024

What's Missing?

Functions are the future of Crossplane's experience and how platform engineers should be composing resources. As we move towards making Functions GA, and even plan on deprecating classic patch and transform (crossplane/crossplane#4746), we should be making them more of the "default" path when using Crossplane. New users of Crossplane should be using Functions from the very start of their Crossplane journey.

The most obvious place to update with a "functions first" approach would be the quick start guides that are still currently using classic patch and transform, e.g.:

Below will track a list of broad areas that we should be updating to use and evangelize Functions more aggressively:

@jbw976 jbw976 added enhancement New feature or request P1 Must fix, critical issues. Frequent or wide-spread user impact. content request Issues requesting new content docs User docs related issues and content concepts/composition concepts/xfn functions labels Jul 3, 2024
@bobh66
Copy link
Collaborator

bobh66 commented Jul 9, 2024

The existing Composition Functions documentation needs to include more detailed information regarding the importance of the crossplane.io/composition-resource-name annotation and how it affects reconciliation. Specifically:

  • The composition-resource-name MUST be unique within the composition/composite instance
  • The composition-resource-name MUST be static for a given resource. If the name changes it will cause the existing resource (with the old name) to be deleted and a new resource will be created, even if nothing else in the resource changes.
  • The composition-resource-name SHOULD NOT use a loop index counter as part of the name (bucket-0, bucket-1) unless it is guaranteed that the loop will not reshuffle the indices and cause the names to change

I can open this as a separate issue if needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
concepts/composition concepts/xfn content request Issues requesting new content docs User docs related issues and content enhancement New feature or request functions P1 Must fix, critical issues. Frequent or wide-spread user impact.
Projects
None yet
Development

No branches or pull requests

3 participants