Configuring Dashboards and Playlists

This guide provides comprehensive documentation for configuring dynamic dashboards and playlists in SPOG. Dashboards provide customizable views of your DNS infrastructure, while playlists enable automated rotation through multiple screens for NOC displays and monitoring stations.

Table of Contents

• Overview
• Default Dashboard and Navigation
• Dashboard Configuration
• URL Parameters
• Playlist Configuration
• Dynamic Screen Expansion
• URL Parameters vs Template Variables
• Graph Widgets Reference
• Filter Query Syntax
• Access Control
• Examples

Overview

SPOG's dashboard and playlist system provides flexible, role-based views of your DNS infrastructure. Key features include:

• Dynamic Filtering: Use powerful filter queries to select and organize clusters
• Role-Based Access: Control dashboard visibility with REGO policies
• Multiple Visualizations: Tree tables, heatmaps, pie charts, and network topology graphs
• Automated Rotation: Playlists for NOC displays with dynamic screen expansion
• Template Variables: Create dynamic content based on query results

Default Dashboard and Navigation

The glass-ui Helm chart provides a default dashboard and navigation out-of-the-box, so you can deploy SPOG without any configuration:

Default Dashboard

SPOG includes a global overview dashboard at / featuring tree-table, heatmap, pie-charts, and cytoscape widgets showing all clusters.

Default Navigation

SPOG provides a default Tools menu with cache management, DNS operations, and AI assistant actions.

Extending the Defaults

Custom dashboards and navigation menus are merged with the defaults:

• Dashboards: Custom dashboards are added alongside the default. If you define a dashboard with the same URL (e.g., /), your custom dashboard overrides the default.
• Navigation: Custom menus appear before the default menus.

globalConfig:
  dashboards:
    # Custom dashboard for tier-based monitoring (not in defaults)
    critical-systems:
      title: "Critical Systems"
      url: /critical
      graphs:
        - widget: "cc-state-tree-table"
          args:
            filter: 'tier = "critical" group by region'
  navigation:
    menus:
      # This menu appears before the default menus
      - name: "Priority"
        sections:
          - name: "By Tier"
            items:
              - name: "Critical Systems"
                url: "/critical"

Disabling Defaults

To disable the default dashboard and navigation entirely:

globalConfig:
  defaults:
    enabled: false
  # Now you must provide your own dashboards and navigation
  dashboards:
    my-dashboard:
      # ...

Dashboard Configuration

Dashboards are configured in your Helm values under globalConfig.dashboards. Each dashboard represents a unique view of your infrastructure.

Dashboard Structure

globalConfig:
  dashboards:
    dashboard-id:
      title: "Dashboard Title"
      description: "Dashboard description"
      url: "/dashboards/path/to/dashboard"
      requires:
        - "rego_permission_flag"
      graphs:
        - title: "Graph Title"
          widget: "widget-type"
          args:
            filter: "filter query"
            # Additional widget-specific arguments

Dashboard Properties

Property	Type	Required	Description
title	string	Yes	Display title shown in the UI
description	string	No	Brief description of the dashboard's purpose
url	string	Yes	URL path for accessing this dashboard
requires	array	No	List of REGO policy flags required for access
graphs	array	Yes	List of graph configurations to display

Graph Configuration

Each graph in a dashboard has the following structure:

- title: "Graph Title"
  widget: "widget-type"
  args:
    filter: "filter query"
    # Widget-specific arguments

Property	Type	Required	Description
title	string	Yes	Display title for the graph
widget	string	Yes	Widget type (see Graph Widgets Reference)
args	object	Yes	Widget-specific configuration
args.filter	string	Yes	Filter query to select clusters

URL Parameters

Dashboard and playlist configurations support URL parameters that can be referenced in titles, descriptions, and filter queries. This allows you to create reusable configurations that adapt based on the URL.

URL Parameter Syntax:

Use :parameterName in the URL path to define a parameter:

globalConfig:
  dashboards:
    regional-view:
      title: "Regional Operations"
      url: "/dashboards/regional/:region"
      graphs:
        - title: "Infrastructure"
          widget: "cc-state-tree-table"
          args:
            filter: "region = \":region\""

Referencing URL Parameters:

In your configuration, reference URL parameters using :parameterName:

title: ":region Regional Status"           # Dynamic title
filter: "region = \":region\""             # In filter queries
filter: "environment = \":environment\""   # Any parameter name

Example with Multiple Parameters:

globalConfig:
  dashboards:
    cluster-detail:
      title: ":region - :environment Cluster Details"
      description: "Detailed view for :region in :environment"
      url: "/dashboards/region/:region/env/:environment"
      graphs:
        - title: ":environment clusters in :region"
          widget: "cc-state-tree-table"
          args:
            filter: "region = \":region\" and environment = \":environment\""

Access URLs: - /dashboards/region/us-east/env/production → Shows US East production clusters - /dashboards/region/eu-west/env/staging → Shows EU West staging clusters

Common Use Cases:

1. Regional dashboards: /dashboards/regional/:region
2. Environment-based views: /dashboards/env/:environment
3. Combined parameters: /dashboards/:region/:role/:environment

Notes: - Parameter names must match exactly between URL and references - Parameters are case-sensitive - Use quotes around parameter references in filter queries: ":region" not :region - Undefined parameters remain as literal text (e.g., :region if not provided)

Example: Regional Dashboard

globalConfig:
  dashboards:
    americas-operations:
      title: "Americas Regional Operations"
      description: "Americas DNS infrastructure management"
      url: "/dashboards/regional/americas"
      requires:
        - "dashboard_americas_operations"
      graphs:
        - title: "Americas Infrastructure"
          widget: "cc-state-tree-table"
          args:
            filter: "region in (\"us-east\", \"us-west\") group by role"

        - title: "Regional Health Heatmap"
          widget: "cc-state-readiness-heatmap"
          args:
            filter: "region in (\"us-east\", \"us-west\") group by role"

        - title: "Service Distribution"
          widget: "cc-state-readiness-pie-charts"
          args:
            filter: "region in (\"us-east\", \"us-west\") group by role"

        - title: "Americas Network Topology"
          widget: "cc-state-cytoscape"
          args:
            filter: "region in (\"us-east\", \"us-west\")"
            depth: "product"
            layout: "Radial"

Playlist Configuration

Playlists enable automated rotation through multiple screens, ideal for NOC displays and monitoring stations. They support both static graphs and dynamic screens that expand based on query results.

Playlist Structure

globalConfig:
  playlists:
    playlist-id:
      name: "Playlist Name"
      description: "Playlist description"
      url: "/playlist/path/to/playlist"
      interval: "15s"
      requires:
        - "rego_permission_flag"
      animatedBackground: true
      showCountdown: true
      screens:
        - graph:
            title: "Static Screen Title"
            widget: "widget-type"
            args:
              filter: "filter query"
        - dynamic:
            query: "filter query with grouping"
            interval: "30s"
            templates:
              - title: "Template {{variable}}"
                widget: "widget-type"
                args:
                  filter: "filter with {{variable}}"

Playlist Properties

Property	Type	Required	Default	Description
name	string	Yes	-	Display name for the playlist
description	string	No	-	Brief description
url	string	Yes	-	URL path for accessing the playlist
interval	string	No	-	Default time to show each screen (e.g., "15s")
requires	array	No	-	REGO policy flags required for access
animatedBackground	boolean	No	false	Enable animated background effects
showCountdown	boolean	No	true	Show countdown timer
screens	array	Yes	-	List of static or dynamic screens

Static Screens

Static screens display a single graph:

- graph:
    title: "Global Infrastructure Health"
    widget: "cc-state-readiness-heatmap"
    interval: "20s"  # Optional: Override playlist default
    args:
      filter: "group by region"

Dynamic Screens

Dynamic screens expand based on query results, creating multiple screens from templates:

- dynamic:
    query: "region in (\"us-east\", \"us-west\")"
    interval: "25s"  # Optional: Override for all expanded screens
    templates:
      - title: "{{cluster.name}} Status"
        widget: "cc-state-cytoscape"
        args:
          filter: "cluster_id = {{cluster.id}}"
          depth: "product"

Dynamic Screen Expansion

Dynamic screens use template variables that are replaced based on query results.

Non-Grouped Queries

For queries without group by, the system creates one screen per matching cluster. This is useful in playlists for rotating through individual cluster details:

- dynamic:
    query: "region = \"us-east\""
    templates:
      - title: "{{cluster.name}} Details"
        widget: "cc-state-cytoscape"
        args:
          filter: "cluster_id = {{cluster.id}}"
          depth: "product"

Available variables: - {{cluster.name}} - Cluster name - {{cluster.id}} - Cluster ID

Note: Non-grouped queries work well in playlists but are not recommended for dashboards.

Single-Level Grouping

For queries with a single group by field, the system creates screens for each unique value:

- dynamic:
    query: "group by region"
    templates:
      - title: "{{region}} Regional Overview"
        widget: "cc-state-readiness-heatmap"
        args:
          filter: "region = \"{{region}}\""

Available variables: Each group field becomes a variable (e.g., {{region}}, {{role}})

Multi-Level Grouping

For multi-level grouping, screens are created for each leaf node in the hierarchy:

- dynamic:
    query: "group by region, role"
    templates:
      - title: "{{role}} in {{region}}"
        widget: "cc-state-tree-table"
        args:
          filter: "region = \"{{region}}\" and role = \"{{role}}\""

Available variables: All group fields (e.g., {{region}}, {{role}})

URL Parameters vs Template Variables

It's important to understand the difference between URL parameters and template variables:

Feature	URL Parameters	Template Variables
Syntax	:parameter	{{variable}}
Source	Extracted from URL path	Generated from query results
Use Case	User-driven navigation	Dynamic screen expansion
Scope	Entire dashboard/playlist	Individual dynamic screens
Example	/dashboard/:region	{{cluster.name}} from query

URL Parameters (:region) are defined in the URL and set when users navigate:

url: "/dashboards/:region/:environment"
# User accesses: /dashboards/us-east/production
# :region = "us-east", :environment = "production"

Template Variables ({{region}}) are populated from query results in dynamic screens:

- dynamic:
    query: "group by region"  # Returns: us-east, us-west, eu-east
    templates:
      - title: "{{region}} Status"  # Creates 3 screens with different regions

Can be used together:

globalConfig:
  playlists:
    regional-detail:
      url: "/playlist/region/:region"  # URL param from navigation
      screens:
        - dynamic:
            query: "region = \":region\" group by role"  # URL param in query
            templates:
              - title: ":region {{role}} Services"  # Both URL param and template var
                filter: "region = \":region\" and role = \"{{role}}\""

Example: NOC Monitoring Playlist

globalConfig:
  playlists:
    noc-24x7:
      name: "NOC 24/7 Operations"
      description: "Continuous monitoring for Network Operations Center"
      url: "/playlist/noc/24x7"
      interval: "15s"
      requires:
        - "playlist_noc_24x7"
      animatedBackground: true
      showCountdown: true
      screens:
        # Static overview screens
        - graph:
            title: "Global Infrastructure Health"
            widget: "cc-state-readiness-heatmap"
            args:
              filter: "group by region"

        - graph:
            title: "Critical Systems"
            widget: "cc-state-readiness-pie-charts"
            args:
              filter: "group by region"

        - graph:
            title: "Global Network Topology"
            widget: "cc-state-cytoscape"
            args:
              filter: ""
              depth: "cluster"
              layout: "Radial"

Example: Regional Rotation Playlist

globalConfig:
  playlists:
    regional-rotation:
      name: "Regional Status Rotation"
      description: "Rotating view of all regions"
      url: "/playlist/regional/rotation"
      interval: "20s"
      requires:
        - "playlist_regional_rotation"
      screens:
        - graph:
            title: "Global Overview"
            widget: "cc-state-readiness-heatmap"
            args:
              filter: "group by region"

        # Dynamic screens - one per region
        - dynamic:
            query: "group by region"
            templates:
              - title: "{{region}} Regional Status"
                widget: "cc-state-readiness-heatmap"
                args:
                  filter: "region = \"{{region}}\""

              - title: "{{region}} Service Distribution"
                widget: "cc-state-readiness-pie-charts"
                args:
                  filter: "region = \"{{region}}\" group by role"

              - title: "{{region}} Network Topology"
                widget: "cc-state-cytoscape"
                args:
                  filter: "region = \"{{region}}\""
                  depth: "product"
                  layout: "Radial"

Playlist Token Authentication

For NOC displays and kiosk screens that need to show playlists without interactive login, SPOG supports playlist tokens - simple bearer tokens that grant access to specific playlists.

Configuring Playlist Tokens

Define tokens in your Helm values:

playlistTokens:
  noc-main:
    token: "PLT_secure-random-token-here"
    claims:
      groups:
        - "noc-viewers"
      playlists:
        - "noc-24x7"
        - "regional-rotation"

  production-display:
    generate:
      secretName: "glass-production-noc-token"
      key: "token"
      length: 32
    claims:
      groups:
        - "production-monitors"

Using Playlist Tokens

Access playlists using the token in one of two ways:

URL Parameter:

https://console.spog.local/playlist/noc-24x7?token=PLT_your-token-here

Authorization Header:

Authorization: Bearer PLT_your-token-here

Access Control with Playlist Tokens

Playlist tokens work with the requires field in playlist configuration. The token's claims are available in REGO as input.playlist:

playlists:
  noc-24x7:
    name: "NOC 24x7 Rotation"
    requires:
      - "playlist_noc_24x7"  # Checked against token claims
    screens:
      # ...

REGO policy to control access:

package pdns_global_flags



# Token must have playlist in claims
playlist_noc_24x7 if {
    "noc-24x7" in input.playlist.playlists
}

# Or be in the NOC viewers group
playlist_noc_24x7 if {
    "noc-viewers" in input.playlist.groups
}

# Admin users can also access
playlist_noc_24x7 if "admin" in input.user.roles

Retrieving Auto-Generated Tokens

For tokens created with the generate mode:

kubectl get secret glass-production-noc-token -n center -o jsonpath='{.data.token}' | base64 -d

Token Security

Auto-generated tokens are recommended for production. They're stored in Kubernetes secrets and never exposed in Helm values.

---

Graph Widgets Reference

SPOG provides several visualization widgets for displaying infrastructure state.

cc-state-tree-table

Hierarchical tree table showing cluster structure with expandable nodes.

Widget ID: cc-state-tree-table

Arguments:

Argument	Type	Required	Description
filter	string	Yes	Filter query to select and organize clusters

Example:

- title: "Infrastructure Tree"
  widget: "cc-state-tree-table"
  args:
    filter: "region in (\"us-east\", \"us-west\") group by role"

Features: - Expandable tree structure (Cluster → Product → Instance Set → Pod → Container) - Readiness indicators for each level - Inline actions (Clear Cache, etc.) - Supports grouping for organized hierarchy

cc-state-readiness-heatmap

Heatmap visualization showing readiness status across clusters.

Widget ID: cc-state-readiness-heatmap

Arguments:

Argument	Type	Required	Description
filter	string	Yes	Filter query to select and organize clusters

Example:

- title: "Regional Health Heatmap"
  widget: "cc-state-readiness-heatmap"
  args:
    filter: "group by region, role"

Features: - Color-coded cells (green=ready, yellow=degraded, red=unhealthy) - Supports grouping for hierarchical organization - Hover details showing exact readiness counts - Click-through to cluster details

cc-state-readiness-pie-charts

Pie chart visualization showing readiness distribution.

Widget ID: cc-state-readiness-pie-charts

Arguments:

Argument	Type	Required	Description
filter	string	Yes	Filter query to select and organize clusters

Example:

- title: "Service Distribution"
  widget: "cc-state-readiness-pie-charts"
  args:
    filter: "role = \"authoritative\" group by region"

Features: - Shows ready vs. not-ready container counts - Supports grouping (creates one pie chart per group) - Interactive legends - Color-coded segments

cc-state-cytoscape

Network topology graph showing relationships between infrastructure components.

Widget ID: cc-state-cytoscape

Arguments:

Argument	Type	Required	Default	Description
filter	string	Yes	-	Filter query to select clusters
depth	string	No	"cluster"	Detail level: "cluster", "product", "instance_set", "pod", "container"
layout	string	No	"Hierarchical"	Layout algorithm: "Hierarchical", "Radial"

Example:

- title: "DNS Network Topology"
  widget: "cc-state-cytoscape"
  args:
    filter: "role = \"authoritative\""
    depth: "product"
    layout: "Radial"

Features: - Interactive network diagram - Multiple layout algorithms - Configurable depth level - Node colors indicate health status - Zoom and pan controls - Click nodes for details

Layout Descriptions:

• Hierarchical: Top-down tree layout, ideal for showing organizational structure
• Radial: Concentric circles radiating from center, good for highlighting central nodes

Filter Query Syntax

Filter queries use a SQL-like syntax to select and organize clusters. This section assumes familiarity with filter terms but provides examples for clarity.

Basic Filtering

Select clusters by label values:

region = "us-east"
role = "authoritative"
environment = "production"

Multiple Values

Select clusters matching any value in a list:

region in ("us-east", "us-west")
role in ("authoritative", "recursor")

Combining Conditions

Use logical operators:

region = "us-east" and role = "authoritative"
region in ("us-east", "us-west") and environment = "production"

Grouping

Organize results hierarchically:

group by region
group by region, role
group by region, role, environment

How grouping works:

• Single level: group by region creates a single level of organization (e.g., us-east, us-west, eu-east)
• Multi-level: group by region, role creates a hierarchy (e.g., us-east → authoritative, us-east → recursor)
• In tree tables: Groups become parent nodes in the tree
• In heatmaps: Groups become rows and columns
• In pie charts: One pie chart is created per group
• In playlists: Each unique combination creates separate screens

Empty Filters

An empty filter selects all accessible clusters:

filter: ""

Filter Examples

All authoritative DNS servers in Americas:

role = "authoritative" and region in ("us-east", "us-west")

Production clusters grouped by service type:

environment = "production" group by role

All recursors grouped by region and environment:

role = "recursor" group by region, environment

Access Control

Dashboards and playlists use REGO policies to control access. Define access rules in your policy configuration.

Dashboard Access

policy:
  policies:
    pdns_global_flags.rego: |
      package pdns_global_flags

      # Dashboard access flag
      dashboard_americas_operations if "americas" in input.user.roles
      dashboard_americas_operations if "admin" in input.user.roles

Playlist Access

policy:
  policies:
    pdns_global_flags.rego: |
      package pdns_global_flags

      # Playlist access flag
      playlist_noc_24x7 if "noc" in input.user.roles
      playlist_noc_24x7 if "admin" in input.user.roles

Multiple Permissions

Require multiple roles with OR logic:

dashboard-id:
  requires:
    - "dashboard_executive"
    - "dashboard_admin"
  # User needs EITHER dashboard_executive OR dashboard_admin

No Access Control

Omit requires for dashboards accessible to all authenticated users:

global-overview:
  title: "Global Overview"
  url: "/"
  # No requires field - accessible to all authenticated users
  graphs: [...]

Dynamic Permission Arguments

For parameterized routes, use object format with arguments to pass route values to REGO:

team-dashboard:
  title: ":team Team Dashboard"
  url: /team/:team
  requires:
    - permission: "see_team_dashboard"
      arguments:
        - name: team
          value: ":team"    # Route parameter passed to REGO
  graphs:
    - title: ":team Clusters"
      widget: "cc-state-tree-table"
      args:
        filter: 'team = ":team"'

Argument Value Syntax:

Syntax	Description	Example
:param	Extract from URL route parameter	:team from /team/:team
{{ param }}	Template expression	{{ team }}_suffix
"value"	Static string	"production"

REGO Policy:

# One rule handles all teams dynamically
see_team_dashboard if {
  input.arguments.team in input.user.roles
}
see_team_dashboard if "admin" in input.user.roles

When user visits /team/devops, REGO receives input.arguments.team = "devops" and checks if "devops" is in the user's roles.

Benefits of Dynamic Permissions

• One dashboard definition serves all teams
• One REGO rule handles all teams
• Adding a new team requires only navigation links and user role assignments

Examples

Example 1: Executive Dashboard

A high-level dashboard for executives showing global infrastructure status:

globalConfig:
  dashboards:
    executive-overview:
      title: "Executive Overview"
      description: "Global DNS infrastructure status and KPIs"
      url: "/dashboards/executive/overview"
      requires:
        - "dashboard_executive_overview"
      graphs:
        - title: "Global Infrastructure Health"
          widget: "cc-state-readiness-heatmap"
          args:
            filter: "group by region"

        - title: "Regional Status Distribution"
          widget: "cc-state-readiness-pie-charts"
          args:
            filter: "group by region"

        - title: "DNS Service Topology"
          widget: "cc-state-cytoscape"
          args:
            filter: ""
            depth: "cluster"
            layout: "Hierarchical"

        - title: "Detailed System State"
          widget: "cc-state-tree-table"
          args:
            filter: "group by region, role"

Example 2: Service-Specific Dashboard

Dashboard focusing on a specific DNS service type:

globalConfig:
  dashboards:
    authoritative-dns:
      title: "Authoritative DNS Global View"
      description: "All authoritative DNS servers across regions"
      url: "/dashboards/service/authoritative"
      requires:
        - "dashboard_authoritative_dns"
      graphs:
        - title: "Global Authoritative Servers"
          widget: "cc-state-tree-table"
          args:
            filter: "role = \"authoritative\" group by region"

        - title: "Authoritative Health Map"
          widget: "cc-state-readiness-heatmap"
          args:
            filter: "role = \"authoritative\" group by region"

        - title: "Regional Distribution"
          widget: "cc-state-readiness-pie-charts"
          args:
            filter: "role = \"authoritative\" group by region"

        - title: "Authoritative DNS Topology"
          widget: "cc-state-cytoscape"
          args:
            filter: "role = \"authoritative\""
            depth: "product"
            layout: "Hierarchical"

Example 3: Multi-Region Playlist with Dynamic Screens

Playlist that rotates through regional overviews and expands to show individual clusters:

globalConfig:
  playlists:
    service-status-rotation:
      name: "Service Status Rotation"
      description: "Rotating view of DNS services"
      url: "/playlist/services/rotation"
      interval: "25s"
      requires:
        - "playlist_service_status_rotation"
      animatedBackground: true
      screens:
        # Static overview screens
        - graph:
            title: "Authoritative DNS Status"
            widget: "cc-state-readiness-heatmap"
            args:
              filter: "role = \"authoritative\" group by region"

        - graph:
            title: "Recursor DNS Status"
            widget: "cc-state-readiness-heatmap"
            args:
              filter: "role = \"recursor\" group by region"

        - graph:
            title: "All Services by Region"
            widget: "cc-state-readiness-heatmap"
            args:
              filter: "group by region"

        # Dynamic screens - one set per service role
        - dynamic:
            query: "group by role"
            templates:
              - title: "{{role}} Service Infrastructure"
                widget: "cc-state-cytoscape"
                args:
                  filter: "role = \"{{role}}\""
                  depth: "product"
                  layout: "Radial"

              - title: "{{role}} Service Health"
                widget: "cc-state-readiness-pie-charts"
                args:
                  filter: "role = \"{{role}}\" group by region"

This playlist expands to: 1. Authoritative DNS Status (static) 2. Recursor DNS Status (static) 3. All Services by Region (static) 4. authoritative Service Infrastructure (dynamic, from template 1) 5. authoritative Service Health (dynamic, from template 2) 6. recursor Service Infrastructure (dynamic, from template 1) 7. recursor Service Health (dynamic, from template 2)

Navigation Integration

Dashboards should be added to the navigation menu for easy access:

globalConfig:
  navigation:
    menus:
      - name: "Regional"
        sections:
          - name: "Dashboards"
            items:
              - name: "Americas"
                url: "/dashboards/regional/americas"
              - name: "Europe"
                url: "/dashboards/regional/europe"
              - name: "Asia-Pacific"
                url: "/dashboards/regional/apac"

Playlists are typically accessed via direct URL (bookmarked for NOC displays) but can also be added to navigation if desired.

Best Practices

Dashboard Design

1. Start simple: Begin with basic tree table and heatmap views
2. Group logically: Use grouping to organize clusters by region, role, or environment
3. Multiple perspectives: Provide different graph types for the same data
4. Performance: Avoid overly complex filters on large deployments
5. Consistent naming: Use clear, descriptive titles

Playlist Design

1. Timing: Balance information density with readability (15-30s per screen)
2. Static first: Start with overview screens, then drill into details
3. Limit expansion: Be mindful of how many screens dynamic queries create
4. Test rotation: Watch full playlist cycle to verify flow

Access Control

1. Least privilege: Grant minimum required access
2. Role-based: Align with organizational roles
3. Test thoroughly: Verify access with different user accounts
4. Document requirements: Clearly state who should access each dashboard

Performance

1. Filter specificity: Use specific filters to reduce data processing
2. Depth control: Use appropriate depth in cytoscape graphs
3. Grouping levels: Limit group nesting to 2-3 levels
4. Playlist timing: Ensure screens have time to render before rotation

Summary

SPOG's dashboard and playlist system provides flexible, powerful visualization of your DNS infrastructure:

• Dashboards offer customizable views with multiple graph types
• Playlists enable automated rotation for monitoring displays
• Dynamic screens expand based on query results for detailed drill-down
• Template variables create context-specific content
• Filter queries provide powerful cluster selection and organization
• REGO policies control access based on user roles