4 posts tagged with "promises"

If you have been writing Compound Promises, you have probably wondered: what happens when multiple resources need to share one unique resource provided by a sub-Promise?

For example, imagine an Application Promise that deploys applications on Kubernetes. Each application may need a namespace on the destination cluster, so you make it a Compound Promise and use the Namespace Promise from the Marketplace. You know the drill: the Application Promise's configure pipeline writes the Namespace request to /kratix/output/, Kratix schedules it to the Platform cluster, and the Namespace Promise does its thing.

You request your first application, app-one, in the team-mobile namespace. The pipelines run, you see the Namespace request come through, the namespace appears on the destination, shortly followed by the application. So far, so good. You now want to deploy a second application, app-two, also in team-mobile. You send the request, the pipeline runs, and... nothing happens.

You check your GitOps agent logs and see that you now have two requests for the same Namespace. It does not like that. You update your Promise pipeline to only emit the Namespace request if it does not exist yet. Everything seems to work, until you delete app-one, the original requester of the Namespace. As the Namespace request is owned by app-one, it gets deleted. app-two, deployed in that namespace, gets wiped out in the process. Absolute chaos.

Congratulations: you have discovered that work ownership and shared resources are not friends.

In this post we walk through a Promise design that fixes this. We call it claims, and there is a working example in the Marketplace.

As platforms are so unique to organisations, and the services required by platform users are so vast, Kratix has always been very flexible when it comes to the design of Promises. Other than the expectation that Promise writers honour the Promise schema, the scope for how Promises can be designed is vast; containers can be written in any language, workflows can be as segmented as you would like and workflow actions can be imperative or declarative.

However, there are a number design practices and approaches to Promise development that can make development and maintenance easier for Promise developers and make consuming services via Promises better for users.

In this blog post, we're going design a Promise with some core fundamentals in mind, paving the way for improved debugging, reliability and user clarity.

Are you building Pipelines and unsure about the best way to test and iterate over them? Worry not. Your questions are about to be answered!

In this blog post, you will gain insights into how you can get faster feedback on your Pipeline development by:

• Running the pipeline stage locally
• Running automated tests
• Testing imperative actions
• Running the stage as a container

We will also look into how to more effectively run system-level tests by

• Populating the image cache
• Setting the image pull policy
• Automating end-to-end (e2e) tests

Click "read more" below 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!