Skip to main content

AI Action

AI Action allows you to integrate AI capabilities into your playbooks by leveraging the rich context that Mission Control maintains about your infrastructure. When executed against configs or components, the AI action automatically injects:

  • Component/config manifests and specifications
  • Related configurations with configurable relationship depth
  • Historical analysis data within the specified time period
  • Change history across related infrastructure within defined time ranges

This comprehensive context enables AI models to provide more informed analysis and insights about your infrastructure state and relationships. For example, when a Kubernetes pod fails, it examines the pod spec, ConfigMap changes, service logs together, revealing patterns that single-component analysis might overlook.

context-provider-playbook.yaml
# Source: mission-control-playbooks-ai/templates/recommend-playbooks.yaml
apiVersion: mission-control.flanksource.com/v1
kind: Playbook
metadata:
name: recommend-playbook
spec:
title: Recommend Playbooks
description: Diagnoses the health of a resource using AI, and then recommends playbooks to fix the issue, sending the results to Slack
icon: bot
category: AI
configs:
- name: '*'
parameters:
- name: prompt
label: Prompt
default: Find out why $(.config.name) is unhealthy
properties:
multiline: 'true'
actions:
- name: analyse
ai:
formats:
- recommendPlaybook
recommendPlaybooks:
- search: category!=AI
connection: 'connection://mission-control/anthropic'
systemPrompt: 'You are an experienced Kubernetes engineer and diagnostic expert. Your task is to analyze Kubernetes resources and provide a comprehensive diagnosis of issues with unhealthy resources. You will be given information about various Kubernetes resources, including manifests and related components.

Please follow these steps to diagnose the issue:

1. Thoroughly examine the manifest of the unhealthy resource. 2. Consider additional related resources provided (e.g., pods, replica sets, namespaces) to gain a comprehensive understanding of the issue. 3. Analyze the context and relationships between different resources. 4. Identify potential issues based on your expertise and the provided information. 5. Formulate clear and precise diagnostic steps. 6. Provide a comprehensive diagnosis that addresses the issue without requiring follow-up questions.

Before providing your final diagnosis, show your thought process and break down the information. This will ensure a thorough interpretation of the data and help users understand your reasoning.

- Identify the unhealthy resource(s). - Examine relationships between resources, noting any dependencies or conflicts. - Consider common Kubernetes issues and check if they apply to this situation. - Formulate hypotheses about potential root causes. '
playbooks:
- if: config.status == 'CrashLoopBackOff'
name: kubernetes-logs
namespace: 'default'
params:
lines: "500"
since: 2h
prompt: '$(.params.prompt)'
changes:
since: 24h
analysis:
since: 1d
relationships:
- depth: 3
direction: outgoing
changes:
since: 24h
analysis:
since: 1d
- depth: 5
direction: incoming
changes:
since: 24h
analysis:
since: 1d
- name: send recommended playbooks
notification:
connection: 'connection://mission-control/slack'
title: Recommended playbooks
message: '$(getLastAction.result.recommendedPlaybooks)'
FieldDescriptionScheme
name*

Step Name

string

ai

AI Action

AI

delay

A delay before running the action e.g. 8h

Duration or CEL with Playbook Context

filter

Conditionally run an action

CEL with Playbook Context

runsOn

Which runner (agent) to run the action on

[]Agent

templatesOn

Where templating (and secret management) of actions should occur

host or agent

timeout

Timeout on this action.

Duration

AI

FieldDescriptionScheme
prompt*

Main prompt

string

systemPrompt*

Context-setting system prompt

string

analysis.since

Select the analysis of the playbook resource to feed into the AI

Duration

apiKey

AI service API key

EnvVar

apiURL

Custom API endpoint (applicable when behind a proxy or using Ollama)

string

backend

LLM provider

openai | anthropic | ollama

changes.since

Select the changes of the playbook resource to feed into the AI

Duration

connection

Connection string for the LLM

string

formats

Output format. (Only markdown supported as of now)

[]string

model

LLM model (e.g. gpt-4)

string

playbooks

List of playbooks to execute and use as context

[]ContextProviderPlaybook

relationships

Select the related configs and their changes and analysis to feed into the AI

[]Relationship

Context provider playbook

These playbooks are executed concurrently and their output is used as context for the AI action. If any of these playbooks fail, it does not affect the execution of the main playbook - the AI action will continue with whatever context is available from the successful playbooks.

FieldDescriptionScheme
name*

Name of the playbook

string

namespace*

Namespace of the playbook

string

if

If is a CEL expression that decides if this playbook should be included in the context

CEL

params

Parameters to pass to the playbook

map[string]string

Relationship

The AI Action can maintain relationships with other elements:

FieldDescriptionScheme
analysis.since

Select the analysis of the related resources to feed into the AI

Duration

changes.since

Select the changes of the related resources to feed into the AI

Duration

depth

Depth of the relationship

int

direction

Direction of the relationship

all | incoming | outgoing

Artifacts

When Mission Control has a configured artifact store, the AI Action automatically stores its prompts as artifacts. These artifacts are:

  • Available in the Playbook Runs page
  • Downloadable for reference and analysis

Templating

CEL Expressions

The following variables can be used within the CEL expressions of filter, if, delays and parameters.default:

FieldDescriptionSchema
configConfig passed to the playbookConfigItem
componentComponent passed to the playbookComponent
checkCanary Check passed to the playbookCheck
playbookPlaybook passed to the playbookPlaybook
runCurrent runRun
paramsUser provided parameters to the playbookmap[string]any
requestWebhook requestWebhook Request
envEnvironment variables defined on the playbookmap[string]any
user.nameName of the user who invoked the actionstring
user.emailEmail of the user who invoked the actionstring
agent.idID of the agent the resource belongs to.string
agent.nameName of the agent the resource belongs to.string
Conditionally Running Actions

Playbook actions can be selectively executed based on CEL expressions. These expressions must either return

  • a boolean value (true indicating run the action & skip the action otherwise)
  • or a special function among the ones listed below
FunctionDescription
always()run no matter what; even if the playbook is cancelled/fails
failure()run if any of the previous actions failed
skip()skip running this action
success()run only if all previous actions succeeded (default)
timeout()run only if any of the previous actions timed out
delete-kubernetes-pod.yaml
---
apiVersion: mission-control.flanksource.com/v1
kind: Playbook
metadata:
name: notify-send-with-filter
spec:
parameters:
- name: message
label: The message for notification
default: '{{.config.name}}'
configs:
- types:
- Kubernetes::Pod
actions:
- name: Send notification
exec:
script: notify-send "{{.config.name}} was created"
- name: Bad script
exec:
script: deltaforce
- name: Send all success notification
if: success() # this filter practically skips this action as the second action above always fails
exec:
script: notify-send "Everything went successfully"
- name: Send notification regardless
if: always()
exec:
script: notify-send "a Pod config was created"
Defaulting Parameters
delete-kubernetes-pod.yaml
apiVersion:
mission-control.flanksource.com/v1
kind: Playbook
metadata:
name: edit
spec:
title: 'Edit Kustomize Resource'
icon: flux
parameters:
- default: 'chore: update $(.config.type)/$(.config.name)'
name: commit_message

Go Templating

When templating actions with Go Templates, the context variables are available as fields of the template's context object . eg .config, .user.email

Templating Actions
delete-kubernetes-pod.yaml
apiVersion: mission-control.flanksource.com/v1
kind: Playbook
metadata:
name: scale-deployment
spec:
description: Scale Deployment
configs:
- types:
- Kubernetes::Deployment
parameters:
- name: replicas
label: The new desired number of replicas.
actions:
- name: kubectl scale
exec:
script: |
kubectl scale --replicas={{.params.replicas}} \
--namespace={{.config.tags.namespace}} \
deployment {{.config.name}}

Functions

FunctionDescriptionReturn
getLastAction()Returns the result of the action that just runAction Specific
getAction({action})Return the result of a specific actionAction Specific
Printing out Results
Reusing Action Results
action-results.yaml
apiVersion: mission-control.flanksource.com/v1
kind: Playbook
metadata:
name: use-previous-action-result
spec:
description: Creates a file with the content of the config
configs:
- types:
- Kubernetes::Pod
actions:
- name: Fetch all changes
sql:
query: SELECT id FROM config_changes WHERE config_id = '{{.config.id}}'
driver: postgres
connection: connection://postgres/local
- name: Send notification
if: 'last_result().count > 0'
notification:
title: 'Changes summary for {{.config.name}}'
connection: connection://slack/flanksource
message: |
{{$rows:=index last_result "count"}}
Found {{$rows}} changes