Add Mistral Guide and Assets

.github/styles/Vocab/FluxNinja/accept.txt

@@ -123,3 +123,4 @@ Duolingo
 APIKey
 [Aa]uthz
 exat
+productizing

docs/content/aperture-for-infra/guides/api-quota-management/api-quota-management.md

@@ -42,11 +42,11 @@ Requests coming into the system are categorized into different workloads, each
 of which is defined by its priority and weight. This classification is crucial
 for the scheduling process within each agent.
 
-Inside every agent, there is a scheduler that priorities request admission based
-on two factors: the priority and weight assigned to the corresponding workload,
-and the availability of tokens from the global token bucket. This mechanism
-ensures that high-priority requests are handled appropriately even under high
-load or when the request rate is close to the rate limit.
+Inside every agent, there is a scheduler that prioritizes request admission
+based on two factors: the priority and weight assigned to the corresponding
+workload, and the availability of tokens from the global token bucket. This
+mechanism ensures that high-priority requests are handled appropriately even
+under high load or when the request rate is close to the rate limit.
 
 ## Example Scenario
 

docs/content/guides/api-quota-management.md

@@ -55,7 +55,7 @@
 of which is defined by its priority and weight. This classification is crucial
 for the request scheduling process.
 
-The scheduler priorities request admission based on two factors: the priority
+The scheduler prioritizes request admission based on two factors: the priority
 and weight assigned to the corresponding workload, and the availability of
 tokens from the token bucket. This mechanism ensures that high-priority requests
 are handled appropriately even under high load or when the request rate is close
@@ -72,7 +72,7 @@
 
 ## Quota Scheduling with Aperture SDK
 
 The first step to using the Aperture SDK is to import and set up Aperture
 Client:
 
 ```mdx-code-block
@@ -113,7 +113,7 @@
 `priority` label is necessary for request prioritization, while the `workload`
 label differentiates each request. In this example, we're only tracking and
 logging requests sent to Aperture. However, after making the `startFlow` call,
 you can execute relevant business operations.
 
 According to the policy logic designed to prevent third-party API rate limit
 breaches, Aperture will, on each `startFlow` call, either give precedence to a
@@ -136,7 +136,7 @@
 </Tabs>
 ```
 
 It is important to make the `end` call made after processing each request, in
 order to send telemetry data that would provide granular visibility for each
 flow.
 
@@ -148,26 +148,26 @@
 ```
 
 Navigate to the `Policies` tab on the sidebar menu, and select `Create Policy`
-in the upper right corner. Next, choose the Request Prioritization blueprint,
+in the upper-right corner. Next, choose the Request Prioritization blueprint,
 and from the drop-down options select Quota based. Now, complete the form with
 these specific values:
 
 1. `Policy name`: Unique for each policy, this field can be used to define
    policies tailored for different use cases. Set the policy name to
    `quota-scheduling-test`.
 2. `Fill amount`: Configures the number of tokens added to the bucket within the
    selected interval. Set `Fill amount` to `15`.
 3. `Bucket Capacity`: Defines the maximum capacity of the bucket in the rate
    limiter. Clear the option `same value for bucket capacity option` to set
    value as `30`.
 4. `Interval`: Specifies the time amount of time `Fill amount` will take to
    refill tokens in the bucket. Set `Interval` to `1 minute`.
 5. `Limit By Label Key`: Determines the specific label key used for enforcing
    rate limits. We'll use `user_id` as an example.
 6. `Priority label key`: This field specifies the label that is used to
    determine the priority. It is set to `priority` in the policy and SDK code
    example.
 7. `Workload label key`: This field specifies the label that is used to
    determine the workload. It is set to `workload` in the policy and SDK code
    example.
 8. `Control point`: It can be a particular feature or execution block within a

docs/content/guides/assets/mistral/mistral.mmd

@@ -0,0 +1,21 @@
+flowchart LR
+classDef Orange fill:#F8773D,stroke:#000000,stroke-width:2px;
+classDef Green fill:#56AE89,stroke:#000000,stroke-width:2px;
+classDef Red fill:#F13C15,stroke:#000000,stroke-width:1px;
+classDef Pink fill:#ffb6c1,stroke:#000000,stroke-width:1px;
+
+TC[\Token Counter/]
+class TC Orange
+
+Scheduler
+class Scheduler Orange
+
+SDK
+class SDK Green
+
+subgraph Aperture_Cloud ["Aperture Cloud"]
+    Scheduler -- "Counting" --> TC
+end
+class Aperture_Cloud Green
+
+SDK -- "Schedule Request" --> Scheduler

docs/content/guides/assets/mistral/mistral.mmd.md5sum

@@ -0,0 +1 @@
+5df63f64375615e3ec9761cb92b987af

docs/content/guides/assets/mistral/policy.yaml

@@ -10,7 +10,6 @@ spec:
     - flow_control:
         concurrency_scheduler:
           concurrency_limiter:
-            limit_by_label_key: limit_by_label_key
             max_inflight_duration: 60s
           in_ports:
             max_concurrency:

docs/content/guides/assets/mistral/validate.sh

@@ -0,0 +1,22 @@
+#!/usr/bin/env bash
+
+set -e
+
+git_root=$(git rev-parse --show-toplevel)
+
+# shellcheck disable=SC1091
+source "$git_root"/docs/tools/aperturectl/validate_common.sh
+
+generate_from_values \
+	values.yaml \
+	tmp
+
+# copy the generated policy and graph to this (assets) directory so that they can be used in the docs
+cp tmp/policies/mistral-concurrency-scheduling-cr.yaml policy.yaml
+cp tmp/graphs/mistral-concurrency-scheduling-cr.mmd graph.mmd
+
+# git add the generated policy and graph
+"$git_root"/scripts/git_add_safely.sh policy.yaml graph.mmd
+
+# remove the tmp directory
+rm -rf tmp

docs/content/guides/assets/mistral/values.yaml

@@ -0,0 +1,21 @@
+# yaml-language-server: $schema=../../../../../blueprints/concurrency-scheduling/base/gen/definitions.json
+blueprint: concurrency-scheduling/base
+uri: ../../../../../blueprints
+policy:
+  policy_name: "mistral-concurrency-scheduling"
+  components: []
+  concurrency_scheduler:
+    alerter:
+      alert_name: "Too many inflight requests"
+    concurrency_limiter:
+      max_inflight_duration: "60s"
+    max_concurrency: 2
+    scheduler:
+      priority_label_key: "priority"
+      tokens_label_key: "tokens"
+      workload_label_key: "workload"
+    selectors:
+      - control_point: "mistral-prompt"
+  resources:
+    flow_control:
+      classifiers: []

docs/content/guides/concurrency-control-and-prioritization.md

@@ -144,7 +144,7 @@ visibility for each flow.
 ```
 
 Navigate to the `Policies` tab on the sidebar menu, and select `Create Policy`
-in the upper right corner. Next, choose the Request Prioritization blueprint,
+in the upper-right corner. Next, choose the Request Prioritization blueprint,
 and from the drop-down options select Concurrency based. Now, complete the form
 with these specific values:
 
@@ -247,7 +247,7 @@ and API Key. In the Aperture Cloud UI, select the Aperture tab from the sidebar
 menu. Copy and enter both your Organization address and API Key to establish a
 connection between the SDK and Aperture Cloud.
 
-## Monitoring concurrency Scheduling Policy
+## Monitoring Concurrency Scheduling Policy
 
 After running the example for a few minutes, you can review the telemetry data
 in the Aperture Cloud UI. Navigate to the Aperture Cloud UI, and click the