Hi nice series, love it. Would highlight on using AWS role instead of credentials and if how they can be incorporated into the providers configurations. Also how to promote custom compositions/xrds from V1alpha1 to beta ..
Hi Victor, firstly want to thank you for sharing your wisdom. I finished the book, really love crossplane. But one thing worries me. You're menitioning it at the beggining of "Composite Functions". There is a lot of yaml. But then you mentioned, that it can be generated by helm and kustomize and that it is not what you will be solving in the chapter. I would like to kindly suggest, if you could dedicate one of the sessions to how we could generate that yaml - meaning if there is a way or strategy how we can ease that yaml writing, if there is such way. Thank you
I'm not sure how to approach that one. There are many different tools and formats so i would either need to create different chapters for each or to choose one and risk people saying "I don't want to write it in this format". My personal favorites are CUE with Timoni and Pkl. They are certainly less popular than, let's say, Helm but, in my opinion, better. I explored CUE with Timoni in one of the videos on this channel. Later today I'll publish a video about Pkl using crossplane compositions as examples. Hence, since there are many tools and formats, I am not sure whether to keep them as videos separate from the Crossplane tutorial or to pick one (maybe two) and add them to the tutorial. What do you think?
I had an issue with crossplane packages. I created one to build azure storage. And then another for azure databases, but this one listed a dependencie bigger then the same dependencie in previous package. Since crossplane can only have one version of each dependencies I had to remake the first package and bump dependencies version. In your opinion how can we manage common dependencies versions in packages? Also, this is not required, but I will say it: I love your videos. Outstanding work Victor.
I'm not sure I understood what you meant by "dependencies bigger than the same dependencies in previous package". Can you pink me on Slack (Crossplane, CNCF, or Kubernetes) so that we go through it? My user is vfarcic.
Is there a chapter about versioning in the roadmap? I am curious how XRDs can be safely promoted from eg v1alpha1 to v1beta1 without impacting existing claims and XRs
@@DevOpsToolkit it's my what my team is currently struggling with tbh 😀 Adoption and initial config was fine but as soon as we started rolling our changes and improvements to our XRDs, we hit a wall and are now studying the docs trying to figure it how to do it right. Would be nice to have some examples from the pros
That is not true. You need to send yaml or Json to kubernetes API but you can generate that yaml any way you like, just as you are doing for your other kubernetes resources. I tend to use CUE and pkl, and you can use anything else. Cdk8s works with almost any language, helm is ok if you prefer go templating, then there is ytt, jsonnet, etc. On top of allí that, there are Crossplane Functions that can be anything you want (well cover that in the next video).
Hi nice series, love it. Would highlight on using AWS role instead of credentials and if how they can be incorporated into the providers configurations. Also how to promote custom compositions/xrds from V1alpha1 to beta ..
Adding it to my to-do list... :)
Very insightful! could you also do on updating configuration version and provider version in this scenario ? thanks
Hi Victor, firstly want to thank you for sharing your wisdom. I finished the book, really love crossplane. But one thing worries me. You're menitioning it at the beggining of "Composite Functions". There is a lot of yaml. But then you mentioned, that it can be generated by helm and kustomize and that it is not what you will be solving in the chapter.
I would like to kindly suggest, if you could dedicate one of the sessions to how we could generate that yaml - meaning if there is a way or strategy how we can ease that yaml writing, if there is such way. Thank you
I'm not sure how to approach that one. There are many different tools and formats so i would either need to create different chapters for each or to choose one and risk people saying "I don't want to write it in this format".
My personal favorites are CUE with Timoni and Pkl. They are certainly less popular than, let's say, Helm but, in my opinion, better. I explored CUE with Timoni in one of the videos on this channel. Later today I'll publish a video about Pkl using crossplane compositions as examples.
Hence, since there are many tools and formats, I am not sure whether to keep them as videos separate from the Crossplane tutorial or to pick one (maybe two) and add them to the tutorial.
What do you think?
@@DevOpsToolkit -I thing, that If you would just pick one and mention others, I believe, that would give us the directions to explore... Thanks!
Here it goes: ruclips.net/video/Nm1ioWPRRVQ/видео.html
It's not a part of the Crossplane tutorial, but it does use Crossplane as examples.
Could you do a video on importing existing resources?
Adding it to my TODO list... :)
I had an issue with crossplane packages. I created one to build azure storage. And then another for azure databases, but this one listed a dependencie bigger then the same dependencie in previous package. Since crossplane can only have one version of each dependencies I had to remake the first package and bump dependencies version. In your opinion how can we manage common dependencies versions in packages? Also, this is not required, but I will say it: I love your videos. Outstanding work Victor.
I'm not sure I understood what you meant by "dependencies bigger than the same dependencies in previous package". Can you pink me on Slack (Crossplane, CNCF, or Kubernetes) so that we go through it? My user is vfarcic.
Is this meant to not run out of CRDs quota? Should we do this to have scalable Crossplane clusters instead of installing providers?
No. That is the way to package and distribute your compositions.
Is there a chapter about versioning in the roadmap? I am curious how XRDs can be safely promoted from eg v1alpha1 to v1beta1 without impacting existing claims and XRs
I did not think that's needed, but I'm probably wrong. I'll add it to my TODO list...
@@DevOpsToolkit it's my what my team is currently struggling with tbh 😀 Adoption and initial config was fine but as soon as we started rolling our changes and improvements to our XRDs, we hit a wall and are now studying the docs trying to figure it how to do it right. Would be nice to have some examples from the pros
@pavelpikat8950 if you send me a private message on LinkedIn, we can organize s call and go through your issues.
I think the main disadvantage of crossplane compositions is that we have to write code logic in yaml instead of just coding language like typescript
Is there a solution for it?
That is not true. You need to send yaml or Json to kubernetes API but you can generate that yaml any way you like, just as you are doing for your other kubernetes resources. I tend to use CUE and pkl, and you can use anything else. Cdk8s works with almost any language, helm is ok if you prefer go templating, then there is ytt, jsonnet, etc.
On top of allí that, there are Crossplane Functions that can be anything you want (well cover that in the next video).
Any of the dozens of tools and formats used to generate yaml. I tend to use CUE but it can be anything else.
I’m sorry but the configuration engineering approach is still limited
Check out the inline kcl-function examples (see crossplane blog)