docs(binding-policy): add binding policy management documentation#2376
docs(binding-policy): add binding policy management documentation#2376cynox-66 wants to merge 2 commits intokubestellar:devfrom
Conversation
kubestellar-prow
bot
added
the
dco-signoff: no
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Hi @cynox-66. Thanks for your PR. I'm waiting for a kubestellar member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
kubestellar-prow
bot
added
size/XL
github-actions
bot
added
frontend
other
and removed
needs-ok-to-test
kubestellar-prow
bot
added
the
size/XL
There was a problem hiding this comment.
Pull request overview
This PR adds comprehensive documentation for managing Binding Policies in the KubeStellar UI, covering the visual policy builder interface, policy creation workflows, and management features.
Changes:
- Added documentation for Binding Policy management features with visual builder interface descriptions
- Included one image file (
yaml-preview.png) to illustrate the YAML editor - Modified frontend package-lock.json to remove peer dependency flags from multiple packages
Reviewed changes
Copilot reviewed 2 out of 17 changed files in this pull request and generated 10 comments.
| File | Description |
|---|---|
| images/yaml-preview.png | Screenshot showing YAML editor preview interface (binary file) |
| frontend/package-lock.json | Removed "peer": true flags from numerous dependencies, changing dependency resolution |
| docs/binding-policy-management.mdx | Concise documentation (178 lines) covering basic policy management features |
| binding-policy-management.mdx | Extended documentation (370 lines) with additional use cases, troubleshooting, and API details |
Files not reviewed (1)
- frontend/package-lock.json: Language not supported
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| ### Three-Panel Layout | ||
|
|
||
| The interface is divided into three areas to facilitate policy creation. |
There was a problem hiding this comment.
The phrase "three-panel layout" is mentioned but the actual layout description immediately follows with "The interface is divided into three areas" (line 29). This is redundant. Consider consolidating: "The interface uses a three-panel layout divided into the following areas:" or similar phrasing to improve flow.
| The interface is divided into three areas to facilitate policy creation. | |
| The interface uses a three-panel layout divided into the following areas: |
|
|
||
| The system monitors the status of every policy in real-time. | ||
|
|
||
|  |
There was a problem hiding this comment.
Missing image references. The root-level documentation file references even more images that are not included in the PR:
./images/bp-overview.png(line 44)./images/cluster-panel-filter.png(line 49)./images/canvas-action.gif(line 57)./images/deploy-modal.png(line 87)./images/radial-layout.png(line 174)./images/policy-list.png(line 190)./images/status-details.png(line 245)
These missing images will result in broken references when the documentation is rendered. All referenced images should be included in the PR.
|  | |
| The **Status Monitoring Dashboard** provides a visual overview of policy health and conditions across all selected clusters. |
|
|
||
| Before creating binding policies, ensure you have: | ||
|
|
||
| * **Imported Clusters**: Clusters registered in the Inventory Transfer Storage (ITS) with appropriate labels. |
There was a problem hiding this comment.
Inconsistent capitalization of "Inventory Transfer Storage" vs "Inventory and Transport Space". Line 24 uses "Inventory Transfer Storage (ITS)" but the docs/binding-policy-management.mdx file (line 8) uses "Inventory and Transport Space (ITS)". These should use consistent terminology throughout the documentation.
| * **Imported Clusters**: Clusters registered in the Inventory Transfer Storage (ITS) with appropriate labels. | |
| * **Imported Clusters**: Clusters registered in the Inventory and Transport Space (ITS) with appropriate labels. |
| ```mermaid | ||
| graph LR | ||
| A[Select Clusters] --> B[Select Workloads] | ||
| B --> C[Configure Rules] | ||
| C --> D[Deploy Policy] | ||
| D --> E[Generate YAML] | ||
| E --> F[Apply to Cluster] | ||
| ``` |
There was a problem hiding this comment.
The Mermaid diagram syntax on lines 132-139 may have rendering issues. The graph uses "LR" (left-to-right) orientation but the flow is linear with arrows (-->) suggesting a sequential workflow. Consider testing this diagram to ensure it renders correctly in the documentation system, or use a simpler flowchart syntax if supported.
| downsync: | ||
| - apiGroup: apps | ||
| resources: [deployments] | ||
| namespaces: [default] |
There was a problem hiding this comment.
The YAML code example is incomplete. Line 178 ends with "namespaces: [default]" but the downsync rule structure typically includes additional fields. The example should either be marked as explicitly incomplete with a comment like "# Additional fields omitted for brevity" or completed with remaining required/common fields to provide a fully functional example.
| namespaces: [default] | |
| namespaces: [default] | |
| # Additional fields omitted for brevity |
| --- | ||
| title: Binding Policy Management | ||
| description: Comprehensive guide to creating, visualizing, and managing Binding Policies in KubeStellar. | ||
| --- | ||
|
|
||
| # Binding Policy Management | ||
|
|
||
| The **Binding Policy (BP)** component is the heart of KubeStellar's multi-cluster deployment capability. It allows users to define explicit rules for *what* (workloads) gets deployed *where* (clusters) and *how* (configuration). | ||
|
|
||
| This guide covers the visual policy builder, the drag-and-drop interface, policy creation workflows, and advanced management features. | ||
|
|
||
| Binding Policies (BP) solve the "Where is my code?" problem in massive multi-cluster environments. Instead of manually targeting Cluster A or Cluster B, KubeStellar uses an Intent-Based Networking model. You define the intent (e.g., "All clusters in US-East with a PCI-compliance label should run the Payment-Gateway workload"), and KubeStellar handles the heavy lifting of reconciliation. | ||
|
|
||
| This approach offers three major benefits: | ||
|
|
||
| * **Scalability**: As you add 100 more edge clusters, if they carry the correct labels, policies apply to them automatically without manual intervention. | ||
| * **Consistency**: By using `matchExpressions`, you ensure that dev, staging, and prod environments stay synchronized based on their lifecycle tags. | ||
| * **Observability**: The visual builder provides a real-time topology map, turning abstract YAML into a visible relationship graph between your infrastructure and your applications. | ||
|
|
||
| ## Prerequisites | ||
|
|
||
| Before creating binding policies, ensure you have: | ||
|
|
||
| * **Imported Clusters**: Clusters registered in the Inventory Transfer Storage (ITS) with appropriate labels. | ||
| * **Created Workloads**: Workload objects (Deployments, Services, CRDs, etc.) available in the Workload Description Space (WDS). | ||
| * **Labeling Strategy**: A clear understanding of your label taxonomy for both clusters and workloads, as KubeStellar relies heavily on label selectors. | ||
|
|
||
| ## Feature Overview | ||
|
|
||
| * **Visual Policy Builder**: A three-panel drag-and-drop interface to intuitively map workloads to clusters. | ||
| * **Flexible Selection**: Select resources individually or dynamically using label selectors. | ||
| * **Interactive Visualization**: View relationships between policies, workloads, and clusters in Radial, Horizontal, or Vertical graph layouts. | ||
| * **Real-time Status**: Monitor the reconciliation status of your policies instantly. | ||
| * **Advanced Configuration**: Fine-tune downsync rules, propagation modes, and update strategies. | ||
|
|
||
| --- | ||
|
|
||
| ## Visual Policy Builder Interface | ||
|
|
||
| The Visual Policy Builder provides a unified workspace for defining binding policies without writing complex YAML manually. | ||
|
|
||
| ### Three-Panel Layout | ||
|
|
||
|  | ||
|
|
||
| The interface is divided into three distinct zones: | ||
|
|
||
| #### 1. Left Panel: Clusters | ||
|  | ||
| Displays all available managed clusters from the ITS. | ||
| * **Search & Filter**: Find clusters by name or labels. | ||
| * **Status Indicators**: See the connection status (Ready/NotReady) of each cluster. | ||
| * **Drag & Drop**: Drag individual clusters or groups of clusters (via labels) to the center canvas. | ||
| * **Metrics**: View basic capacity metrics (CPU, Memory) for informed placement decisions. | ||
|
|
||
| #### 2. Center Panel: Canvas Workspace | ||
|  | ||
| The active staging area for your policy. | ||
| * **Visual Connections**: Automatically draws lines between dropped clusters and workloads to indicate potential bindings. | ||
| * **Clear & Reset**: Easily remove items or clear the entire canvas to start over. | ||
| * **Context Menus**: Right-click items to remove them or view details. | ||
| * **Empty State**: Provides clear instructions and drop zones when starting a new policy. | ||
|
|
||
| #### 3. Right Panel: Workloads | ||
| Displays all available workload objects from the WDS. | ||
| * **Namespace Filtering**: Filter workloads by namespace (default is filtered out by default). | ||
| * **Kind Filtering**: Filter by resource Kind (Deployment, Service, ConfigMap, etc.). | ||
| * **Drag & Drop**: Drag specific workloads or label-based groups to the canvas. | ||
|
|
||
| ## Policy Creation Workflow | ||
|
|
||
| ### Step 1: Select Clusters | ||
| 1. Navigate to the **Clusters Panel** on the left. | ||
| 2. **Search** for specific clusters or use the filter to find clusters by label (e.g., `location=edge`). | ||
| 3. **Drag** the desired clusters onto the central Canvas. | ||
| * *Tip:* Dragging a label group will dynamically select all current and future clusters with that label. | ||
|
|
||
| ### Step 2: Select Workloads | ||
| 1. Navigate to the **Workloads Panel** on the right. | ||
| 2. **Search** for the application resources you want to deploy. | ||
| 3. **Drag** the workloads onto the central Canvas. | ||
| * *Tip:* You can select related resources (e.g., a Deployment and its Service) together. | ||
|
|
||
| ### Step 3: Configure & Deploy | ||
| 1. Once items are on the canvas, click the **Deploy** button. | ||
| 2. **Name Your Policy**: Enter a unique name for the Binding Policy. | ||
|  | ||
| 3. **Review Configuration**: | ||
| * The system automatically generates the Binding Policy YAML. | ||
| * **Downsync Rules**: Verify which resources will be synced. | ||
| * **Propagation Mode**: Choose `DownsyncOnly` (standard) or `UpsyncAndDownsync` (if status returns are needed). | ||
| 4. **Confirm**: Click **Create** to apply the policy. | ||
| 5. **Status**: Watch for the success notification and real-time status update. | ||
|
|
||
|
|
||
| ### Guide: Creating Policy via YAML Editor | ||
|
|
||
| 1. Click the **YAML toggle** in the top right of the Visual Builder. | ||
| 2. **Paste** your pre-configured `BindingPolicy` manifest. | ||
|  | ||
| 3. The Canvas will automatically update to reflect the resources defined in your YAML. | ||
| 4. Click **Deploy**. | ||
|
|
||
| ### Guide: Using Advanced Cluster Selectors | ||
|
|
||
| 1. In the **Cluster Panel**, click the **Expression Builder** icon. | ||
| 2. Select the operator `NotIn`. | ||
| 3. Enter the key `status` and value `maintenance`. | ||
| 4. This ensures your workloads are automatically evacuated from any cluster labeled for maintenance. | ||
| * *Note*: When using the YAML editor, `matchExpressions` requires a specific list structure (key, operator, values). | ||
|
|
||
| ### Guide: Editing Existing Policies | ||
|
|
||
| 1. From the **Policy List**, click the **Edit (Pencil)** icon. | ||
| 2. This reloads the canvas with current connections. | ||
| 3. Modify the drag-and-drop items and click **Update**. | ||
|
|
||
| ### Guide: Configuring Downsync Rules | ||
|
|
||
| 1. In the **Deploy** dialog, go to the **Rules** tab. | ||
| 2. Use the **Add Rule** button to specify that only `ConfigMaps` should sync. | ||
| 3. This prevents Secrets from moving to less secure edge clusters. | ||
|
|
||
| ### Guide: Bulk Exporting Policies | ||
|
|
||
| 1. In the **Table View**, select multiple checkboxes. | ||
| 2. Click the **Bulk Actions** dropdown and select **Download YAML**. | ||
| 3. This creates a zip file of all selected manifests for GitOps backup. | ||
|
|
||
| ### Flow Diagram | ||
|
|
||
| ```mermaid | ||
| graph LR | ||
| A[Select Clusters] --> B[Select Workloads] | ||
| B --> C[Configure Rules] | ||
| C --> D[Deploy Policy] | ||
| D --> E[Generate YAML] | ||
| E --> F[Apply to Cluster] | ||
| ``` | ||
|
|
||
| ## Policy Visualization | ||
|
|
||
| Gain insights into your deployment topology with the interactive graph visualization. | ||
|
|
||
| ### Three-Panel Layout Structure | ||
|
|
||
| ```mermaid | ||
| block-beta | ||
| columns 3 | ||
| block:left | ||
| clusters["Clusters Panel"] | ||
| search1["[Search]"] | ||
| list1["Cluster List..."] | ||
| end | ||
| block:center | ||
| canvas["Canvas Workspace"] | ||
| drop["[Drag Items Here]"] | ||
| conn["Visual Connections"] | ||
| end | ||
| block:right | ||
| workloads["Workloads Panel"] | ||
| search2["[Search]"] | ||
| list2["Workload List..."] | ||
| end | ||
| ``` | ||
|
|
||
|
|
||
| ### Layout Options | ||
| Toggle between different views to suit your analysis needs: | ||
| * **Horizontal**: Best for hierarchical flows from Policy -> Workload -> Cluster. | ||
| * **Vertical**: Top-down tree view of relationships. | ||
| * **Radial**: Circular arrangement with the Policy at the center, ideal for seeing the "blast radius" of a policy. | ||
|
|
||
|  | ||
|
|
||
| ### Visual Elements | ||
| * **Policy Nodes** (Blue): The central binding definitions. | ||
| * **Workload Nodes** (Light Blue): The resources being propagated. | ||
| * **Cluster Nodes** (Gray): The destination targets. | ||
| * **Edges**: Connections representing the binding. | ||
| * **Animated Edges**: Indicate active data flow or pending reconciliation. | ||
| * **Color Coding**: Green (Active), Yellow (Pending), Red (Error). | ||
|
|
||
| ## Policy List Management | ||
|
|
||
| The main dashboard provides a tabular view of all your Binding Policies. | ||
|
|
||
| ### Table Features | ||
|
|
||
|  | ||
|
|
||
| * **Sortable Columns**: Name, Namespace, Status, Cluster Count. | ||
| * **Status Badges**: Quickly identify policies that are `Active`, `Inactive`, or `Pending`. | ||
| * **Action Menu**: | ||
| * **View Details**: Inspect the full configuration. | ||
| * **Edit**: Re-open the policy in the Visual Builder. | ||
| * **View YAML**: See the underlying CRD definition. | ||
| * **Delete**: Remove the policy (and undeploy workloads). | ||
|
|
||
| ### Bulk Operations | ||
| Select multiple policies to perform batch actions: | ||
| * **Bulk Delete**: Remove multiple policies simultaneously. | ||
| * **Export**: Download YAML definitions for backup or GitOps integration. | ||
|
|
||
| ## Advanced Policy Features | ||
|
|
||
| ### Cluster Selectors | ||
| For dynamic environments, use advanced label selectors: | ||
| * **matchLabels**: Exact key-value matching (e.g., `environment: production`). | ||
| * **matchExpressions**: Complex logic using operators: | ||
| * `In`: Value must be in a list (e.g., `region in [us-east, us-west]`). | ||
| * `NotIn`: Value must not be in a list. | ||
| * `Exists`: Label key must exist (regardless of value). | ||
| * `DoesNotExist`: Label key must not exist. | ||
|
|
||
| ### Downsync Rules | ||
| Control precisely what gets synced: | ||
| * **API Groups**: Limit sync to specific API groups (e.g., `apps`, `networking.k8s.io`). | ||
| * **Resources**: Whitelist specific resource kinds. | ||
| * **Namespaces**: Define source and destination namespaces. | ||
| * **Object Selectors**: Filter individual objects based on their labels within the namespace. | ||
|
|
||
| ### Update Strategies & Propagation | ||
|
|
||
| * **Propagation Mode**: | ||
| * `DownsyncOnly`: One-way push from WDS to clusters (best for stateless apps). | ||
| * `UpsyncAndDownsync`: Allows status reports to flow back from clusters to WDS (required for monitoring health). | ||
| * **Update Strategy**: | ||
| * `Recreate`: Terminates existing pods before creating new ones. | ||
| * `RollingUpdate`: Standard Kubernetes zero-downtime deployment. | ||
|
|
||
| ## Quick Connect | ||
| The **Quick Connect** feature streamlines the creation process for simple use cases: | ||
| 1. Click **Quick Connect** on the dashboard. | ||
| 2. Select a single Workload. | ||
| 3. Select a single Cluster. | ||
| 4. Click **Create**. | ||
| * *Result:* An auto-named policy is created instantly with default settings. | ||
|
|
||
| ## Policy Status Monitoring | ||
|
|
||
|
|
||
| The system monitors the status of every policy in real-time. | ||
|
|
||
|  | ||
|
|
||
| ### Detailed Condition Tracking | ||
|
|
||
| The system tracks specific conditions in the `.status` field: | ||
| * **PolicyValid**: `True` if the YAML structure and selectors are logically sound. | ||
| * **ClusterSelected**: `True` if at least one cluster matches the criteria. | ||
| * **WorkloadSelected**: `True` if the specified resources exist in the WDS. | ||
| * **Reconciled**: `True` if the binding has been successfully written to the WECS. | ||
|
|
||
| ## Use Cases | ||
|
|
||
| ### Scenario 1: Canary Deployment | ||
| Create two policies: | ||
| 1. **"Canary-Policy"**: Selects workloads with `tag: canary` and clusters with `type: staging`. | ||
| 2. **"Prod-Policy"**: Selects workloads with `tag: stable` and clusters with `type: production`. | ||
| * *Workflow*: Update the workload labels to promote features from Canary to Prod without changing the cluster selection. | ||
|
|
||
| ### Scenario 2: Edge Distribution | ||
| 1. Group clusters by location label (e.g., `site: factory-a`, `site: factory-b`). | ||
| 2. Create a policy targeting `site: *`. | ||
| 3. Deploy a common base configuration to all edge sites simultaneously. | ||
|
|
||
| ### Scenario 3: Multi-Region Deployment | ||
|
|
||
| * **Goal**: Deploy a global load balancer and frontend to clusters in `us-east-1` and `eu-central-1`. | ||
| * **Cluster Selector**: `region in [us-east-1, eu-central-1]` | ||
| * **Workload**: `frontend-deployment`, `frontend-service` | ||
| * **Benefit**: High availability across geographic boundaries with a single policy. | ||
|
|
||
| ### Scenario 4: Development vs Production Policies | ||
|
|
||
| * **Goal**: Prevent "Dev" workloads from ever touching "Prod" clusters. | ||
| * **Strategy**: Create a global policy with a `matchExpression` where `environment` must `DoesNotExist` for "Prod" tags when deploying experimental features. | ||
|
|
||
| ## API Reference | ||
|
|
||
| The Binding Policy interacts with the backend via standard Kubernetes CRDs. | ||
|
|
||
| | Feature | Endpoint / Path | Method | | ||
| |---------|-----------------|--------| | ||
| | Policy List | `/api/v1/wds/bp` | GET | | ||
| | Create Policy | `/api/v1/wds/bp` | POST | | ||
| | Live Updates | `/api/v1/ws/bp/status` | WebSocket (SSE) | | ||
| | Cluster Metrics | `/api/v1/its/metrics` | GET | | ||
|
|
||
| ### Policy Architecture | ||
|
|
||
| ```mermaid | ||
| classDiagram | ||
| class BindingPolicy { | ||
| +ClusterSelectors | ||
| +DownsyncRules | ||
| +PropagationMode | ||
| } | ||
| class ClusterSelector { | ||
| +MatchLabels | ||
| +MatchExpressions | ||
| } | ||
| class DownsyncRule { | ||
| +APIGroups | ||
| +Resources | ||
| +Namespaces | ||
| +ObjectSelectors | ||
| } | ||
| BindingPolicy --> ClusterSelector | ||
| BindingPolicy --> DownsyncRule | ||
| ``` | ||
|
|
||
| **Resource**: `BindingPolicy` | ||
| **Group**: `control.kubestellar.io` | ||
| **Version**: `v1alpha1` | ||
|
|
||
| ### Architecture Detail | ||
|
|
||
| ```mermaid | ||
| graph TD | ||
| BP[Binding Policy] --> CS[ClusterSelectors] | ||
| CS --> T1[Target: Cluster 1] | ||
| CS --> T2[Target: Cluster 2] | ||
| BP --> WS[WorkloadSelectors] | ||
| WS --> AG[API Groups: apps, core] | ||
| WS --> RS[Resources: Deployment, Service] | ||
| WS --> NS[Namespaces: default] | ||
| BP --> DR[Downsync Rules] | ||
| DR --> SY[Sync Rules to Clusters] | ||
| ``` | ||
|
|
||
| ### YAML Structure | ||
| ```yaml | ||
| apiVersion: control.kubestellar.io/v1alpha1 | ||
| kind: BindingPolicy | ||
| metadata: | ||
| name: my-policy | ||
| spec: | ||
| clusterSelectors: | ||
| - matchLabels: | ||
| location: edge | ||
| downsync: | ||
| - apiGroup: apps | ||
| resources: [ deployments ] | ||
| namespaces: [ default ] | ||
| objectSelectors: | ||
| - matchLabels: | ||
| app: nginx | ||
| ``` | ||
|
|
||
| ## Troubleshooting | ||
|
|
||
| | Issue | Symptom | Resolution | | ||
| |-------|---------|------------| | ||
| | **Stale Status** | `ObservedGeneration < Generation` | The controller hasn't processed the latest change. Check `kubestellar-controller-manager` logs. | | ||
| | **Cyclic Dependency** | Policy targets its own namespace | Ensure downsync rules do not target the KubeStellar system namespaces. | | ||
| | **0 Clusters Selected** | "ClusterSelected: 0" in Status | Check if ITS clusters are in Ready state. Use `kubectl get managedclusters`. | | ||
| | **CRD Not Found** | Error during Deploy | Ensure the custom resource definitions are applied to the WDS before the policy is created. | | ||
| | **Selector Overlap** | Multiple policies hitting 1 cluster | Check for conflicting `UpdateStrategy`. One policy might be "Recreating" while another is "Rolling". | | ||
| | **Namespace Missing** | Workload Stuck | Ensure target namespaces exist on destination clusters or set `createNamespace: true`. | | ||
| | **Invalid Syntax** | PolicyValid: False | Check YAML for syntax errors or invalid label selector operators. | | ||
| | **Sync Timeout** | Status Not Ready | Network connectivity issues between WECS and ITS. Check WECS logs. | | ||
| | **Conflict** | Resource Drift | Another controller or policy is managing the same resource. | | ||
| | **Image Pull Error** | Pods Pending | Check image registry credentials and connectivity on the edge cluster. | | ||
|
|
||
| ## Related Features | ||
| * **ITS (Inventory Transfer Storage)**: The source of truth for your clusters. | ||
| * **WDS (Workload Description Space)**: The source of truth for your workloads. | ||
| * **WECS (Workload Execution Control Space)**: The execution layer where binding policies are actualized. |
There was a problem hiding this comment.
There appear to be two separate documentation files with the same name but different content. The file docs/binding-policy-management.mdx contains a minimal version (178 lines), while binding-policy-management.mdx at the root contains an extended version (370 lines) with additional sections like use cases, troubleshooting, and API references.
This duplication creates ambiguity - it's unclear which file is intended to be the canonical documentation. Consider consolidating these into a single file or clarifying the purpose of each if they serve different audiences.
|
|
||
| # Binding Policy Management | ||
|
|
||
| Binding Policies define how workloads from the Workload Description Space (WDS) are associated with clusters registered in the Inventory and Transport Space (ITS). In this document, *Binding Policy* may be abbreviated as **BP**. |
There was a problem hiding this comment.
The abbreviation "BP" is introduced for "Binding Policy" but is inconsistently used throughout the document. The document states "Binding Policy may be abbreviated as BP" on line 8, but then uses the full term "Binding Policy" in most places with only occasional uses of "BP" (lines 8, 12). For better readability, either use the abbreviation consistently after introduction or avoid introducing it if it won't be used regularly.
| Binding Policies define how workloads from the Workload Description Space (WDS) are associated with clusters registered in the Inventory and Transport Space (ITS). In this document, *Binding Policy* may be abbreviated as **BP**. | |
| Binding Policies define how workloads from the Workload Description Space (WDS) are associated with clusters registered in the Inventory and Transport Space (ITS). |
|
|
||
| The dashboard provides a list view of existing Binding Policies. | ||
|
|
||
|  |
There was a problem hiding this comment.
The documentation contains several image references that may not exist in the repository. The following images are referenced but were not included in this PR:
./images/bp-overview.png(line 25)./images/cluster-panel-filter.png(line 33)./images/deploy-modal.png(line 90)./images/policy-list.png(line 120)
Only ./images/yaml-preview.png was added. Either these images should be included in the PR, or the references should be updated to existing images or removed until the images are available.
|  | |
| _Screenshot of the policy list view is omitted in this version of the documentation._ |
| block-beta | ||
| columns 3 | ||
| block:left | ||
| clusters["Clusters Panel"] | ||
| search1["[Search]"] | ||
| list1["Cluster List..."] | ||
| end | ||
| block:center | ||
| canvas["Canvas Workspace"] | ||
| drop["[Drag Items Here]"] | ||
| conn["Visual Connections"] | ||
| end | ||
| block:right | ||
| workloads["Workloads Panel"] | ||
| search2["[Search]"] | ||
| list2["Workload List..."] | ||
| end |
There was a problem hiding this comment.
The Mermaid "block-beta" diagram syntax (lines 147-165) uses experimental beta features that may not be supported in all documentation rendering systems. This could cause rendering failures. Consider using a more standard Mermaid diagram type (flowchart, graph, or sequence diagram) or verify that the documentation platform supports block-beta diagrams.
| block-beta | |
| columns 3 | |
| block:left | |
| clusters["Clusters Panel"] | |
| search1["[Search]"] | |
| list1["Cluster List..."] | |
| end | |
| block:center | |
| canvas["Canvas Workspace"] | |
| drop["[Drag Items Here]"] | |
| conn["Visual Connections"] | |
| end | |
| block:right | |
| workloads["Workloads Panel"] | |
| search2["[Search]"] | |
| list2["Workload List..."] | |
| end | |
| flowchart LR | |
| subgraph left [Clusters Panel] | |
| clusters["Clusters Panel"] | |
| search1["[Search]"] | |
| list1["Cluster List..."] | |
| end | |
| subgraph center [Canvas Workspace] | |
| canvas["Canvas Workspace"] | |
| drop["[Drag Items Here]"] | |
| conn["Visual Connections"] | |
| end | |
| subgraph right [Workloads Panel] | |
| workloads["Workloads Panel"] | |
| search2["[Search]"] | |
| list2["Workload List..."] | |
| end | |
| clusters --> canvas --> workloads |
cynox-66
changed the title
Signed-off-by: cynox-66 <devj2311@gmail.com>
|
Thanks for your pull request. Before we can look at it, you'll need to add a 'DCO signoff' to your commits. 📝 Please follow instructions in the contributing guide to update your commits with the DCO Full details of the Developer Certificate of Origin can be found at developercertificate.org. The list of commits missing DCO signoff:
DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
|
/ok-to-test |
kubestellar-prow
bot
added
the
ok-to-test
clubanderson
added
the
kind/documentation
❌ PR Title Verification FailedYour PR title does not follow the required format. Current title: Required FormatPR titles must start with one of these emoji prefixes:
How to FixEdit your PR title to start with the appropriate emoji. For example:
You can edit the title by clicking the Edit button next to your PR title. This comment was posted to help you fix the PR title format. |
MAVRICK-1
left a comment
MAVRICK-1
left a comment
There was a problem hiding this comment.
go through the docs and fix it , lots of terms are wrong here .
|
|
||
| Before creating binding policies, ensure you have: | ||
|
|
||
| * **Imported Clusters**: Clusters registered in the Inventory Transfer Storage (ITS) with appropriate labels. |
There was a problem hiding this comment.
its inventory and transport space , go through docs again , there is a lot of mistakes here , fix all
github-project-automation
bot
moved this from In Progress
to Changes Required
in KubeStellar UI Project
Summary
This PR adds documentation for managing Binding Policies in the KubeStellar UI.
The documentation covers:
Scope and Notes
Related Issue
Closes / Addresses: #2285