As much as we would all like, rolling out updates to any software can result in some bumps along the way. This applies to updates to Promises too but Kratix has some feature to help identify any issues within your Promise spec, your Promise workflows and the scheduling of documents outputted by your workflows.

In this blog post we'll explore some of the common issues that users experience when configuring Kratix and developing Promises and well as how Kratix tries to steer you in the right direction when something goes wrong. We'll be exploring:

• Querying Kratix effectively with labels
• Debugging scheduling issues Kratix
• Getting information from Destination and State Store status updates
• Validating the Kratix Promise spec

Click on "read more" to continue!

So you read the guide on Compound Promises and tried out the Workshop, and decided that a compound promise is the right abstraction to expose in your platform. You are about to start writing it, but you are still wondering how you would really go about writing one.

We hear you.

In this blog post, we will build a Compound Promise from scratch. Consider this the ultimate guide on how to build compound promises effectively.

You can follow this guide and build the Promise along with us, or you can use it as a reference when building your own Compound Promises. The Promise we will build is available here.

After reading this post you will:

• Learn about some basic Kratix concepts
• Learn how to write a Compound Promise
  • By transforming an user's request into a series of sub-requests
  • By sending those sub-requests to the Platform cluster (and why you need it)
  • By defining the sub-Promises that the parent Promise depends on

Click on "read more" to continue!

Ever wondered how Kratix actually gets your documents from the Platform Cluster to the correct Destination?

The Syntasso Team has recently introduced a change to Kratix to reduce the size of the Work object. While this change is mostly internal, we wanted to share how the innards of Kratix work.

So brace yourself to learn:

• how Kratix moves documents from Platform to Destinations
• what works and workplacements are
• how to inspect works to debug your Promises

You are probably already familiar with how Kratix works at a high level and with the diagram below:

As illustrated above:

1. The user sends a new App Request to the Platform Cluster.
2. The Promise reacts to that request and triggers the Resource Configure Workflows.
3. The Workflow completes and outputs a series of documents to be scheduled to a Destination.
4. These documents are written to a specific directory in the State Store.
5. In the diagram, the documents are scheduled to a Kubernetes Destination. These type of Destination usually have Flux (or ArgoCD, or another GitOps tool) watching the State Store. The tool picks up the new documents.
6. The documents are then processed and applied to the Destination.
7. The App becomes operational on the Destination.

In this post, I'm going to expand on points (3) and (4): what happens at the end of the Workflow? How is the document written to the State Store? And how does the change linked above affect this process?

Hi friends 😊 I'm Cat, Product Manager here at Syntasso, and I've been listening to you, our avid followers. "Cat, we love Kratix, and we love your team; we want an update!" I hear you scream, so here I am, delivering this top-quality content. You're welcome.

Given that this is our first Kratix Product Update™ (not really ™), I wanted to shout about some of the great work the team has done over the last few months, so we're going back a bit further than we usually will… Indulge me; it was my birthday this month.

TL;DR​

If you only have 10 seconds spare to read this blog, these are the features you need to know about:

• We have two CLIs now! One for building promises and one for installing SKE (Syntasso Kratix Enterprise)
• Setting permissions just got a little bit easier
• If you like Backstage, you’ll like what we’re up to