refactor schemas and docs corrections

Author: petercrocker

docs/docs/containerlab-deployment.mdx

@@ -21,7 +21,7 @@ Before starting this tutorial, ensure you have:
 
 - Completed the [installation guide](./install.mdx) and have Infrahub running
 - Completed the [user walkthrough](./user-walkthrough.mdx) to understand the basic workflow
-- **Docker** installed and running with sufficient resources (at least 8GB RAM recommended)
+- **Docker** installed and running with sufficient resources (at least 16GB RAM recommended to support a few cEOS containers)
 - **Containerlab** installed ([installation instructions](https://containerlab.dev/install/))
 - **sudo access** for running Containerlab (required for network namespace operations)
 
@@ -253,50 +253,7 @@ ssh admin@<management-ip>
 
 Default credentials are typically `admin` / `admin` for cEOS devices.
 
-## Step 6: Test the fabric
-
-With all devices running, verify the data center fabric is functioning:
-
-### Check underlay connectivity
-
-From any spine, ping the loopback addresses of all leaves:
-
-```bash
-sudo containerlab exec --name DC-3 --node dc3-spine1 Cli
-
-# In the EOS CLI
-ping <leaf1-loopback-ip>
-ping <leaf2-loopback-ip>
-```
-
-### Verify BGP convergence
-
-Check that all BGP sessions are established:
-
-```bash
-# From a spine
-show ip bgp summary
-
-# From a leaf
-show ip bgp summary
-show bgp evpn summary
-```
-
-All neighbors should show state "Established" with non-zero prefix counts.
-
-### Verify the EVPN control plane
-
-On leaf switches, check EVPN VXLAN status:
-
-```bash
-show bgp evpn summary
-show vxlan vtep
-show vxlan vni
-```
-
-You should see VXLAN tunnels established between all VTEPs (leaf switches).
-
-## Step 7: Destroy the lab (cleanup)
+## Step 6: Destroy the lab (cleanup)
 
 When you're done testing, destroy the lab to free resources:
 
@@ -336,21 +293,6 @@ Deploy configurations from any branch:
 uv run invoke containerlab --branch my-branch --topology DC-3
 ```
 
-### Customizing the topology
-
-Edit the generated topology file before deployment:
-
-```bash
-# Extract configs only (don't deploy yet)
-uv run scripts/get_configs.py --branch add-dc3
-
-# Edit the topology file
-vim generated-configs/clab/DC-3.clab.yml
-
-# Deploy manually
-sudo -E containerlab deploy -t generated-configs/clab/DC-3.clab.yml
-```
-
 ### Testing configuration changes
 
 Use this workflow to test changes before production:
@@ -362,15 +304,6 @@ Use this workflow to test changes before production:
 5. Test in virtual lab
 6. If successful, merge to main and deploy to production
 
-### Connecting external tools
-
-Containerlab labs can be accessed by external tools:
-
-- **Ansible** - Use management IPs to configure devices
-- **Network monitoring** - Connect SNMP or streaming telemetry collectors
-- **Traffic generators** - Inject test traffic using additional containers
-- **CI/CD pipelines** - Automate testing with Containerlab in CI
-
 ## Troubleshooting
 
 ### Deployment fails with "permission denied"
@@ -401,15 +334,6 @@ docker logs clab-DC-3-dc3-spine1
 
 Look for configuration syntax errors or boot failures.
 
-### BGP sessions don't establish
-
-Verify:
-
-1. All containers are running (`docker ps`)
-2. Device configurations were loaded correctly (check `show running-config`)
-3. Interface states are up (`show ip interface brief`)
-4. No IP address conflicts
-
 ### Out of memory errors
 
 Containerlab labs can be resource-intensive. For DC-3 with 8 devices:
@@ -422,16 +346,8 @@ Reduce device count or increase Docker's memory allocation if needed.
 
 ## Next steps
 
-Now that you can deploy virtual labs, you can:
-
-- **Test other vendor designs** - Deploy DC-2 (Cisco), DC-4 (SONiC), or DC-5 (Juniper) topologies
-- **Experiment with changes** - Modify designs in Infrahub, regenerate, and test in Containerlab
-- **Automate testing** - Write scripts that deploy, test, and validate configurations automatically
-- **Integrate with CI/CD** - Add Containerlab deployment to your pipeline for automated validation
-- **Learn device CLIs** - Practice configuring Arista EOS in a safe virtual environment
-
 For deeper understanding:
 
-- **[Understanding the concepts](./concepts.mdx)** - Learn about design-driven automation
-- **[Developer guide](./developer-guide.mdx)** - Understand how generators and transforms work
+- **[Understanding the concepts](./concepts.mdx)** - Learn about this design-driven automation demo
+- **[Developer guide](./developer-guide.mdx)** - Understand how generators and transformations work
 - **[Containerlab documentation](https://containerlab.dev/)** - Explore advanced Containerlab features

docs/docs/developer-guide.mdx

@@ -760,67 +760,6 @@ config = template.render(hostname="spine1", interfaces=[...])
 print(config)
 ```
 
-## Troubleshooting
-
-### Generator fails
-
-1. Check task logs in Infrahub UI (System → Tasks)
-2. Look for Python exceptions in generator code
-3. Verify input data matches expected structure
-4. Add debug logging to narrow down issue
-
-### Transform produces incorrect output
-
-1. Examine GraphQL query results
-2. Print context data before rendering
-3. Test template with sample data
-4. Check for Jinja2 syntax errors
-
-### Check fails unexpectedly
-
-1. Review check query and data
-2. Verify validation logic
-3. Check for missing relationships or attributes
-4. Test with minimal dataset
-
-### Schema conflicts
-
-1. Check for naming conflicts
-2. Verify relationship peer nodes exist
-3. Ensure proper inheritance
-4. Review schema validation errors
-
-## Best practices
-
-### Code organization
-
-- Keep generators focused on single topology type
-- Separate common logic into utilities (`common.py`)
-- Use type hints throughout
-- Write docstrings for classes and methods
-
-### Testing
-
-- Write tests before implementing features (TDD)
-- Cover both success and failure cases
-- Use mocks for external dependencies
-- Maintain high test coverage
-
-### Documentation
-
-- Document complex generator logic
-- Add inline comments for non-obvious code
-- Update this guide when adding features
-- Keep README.md current
-
-### Performance
-
-- Use batch operations for creating many objects
-- Leverage async/await for concurrent operations
-- Profile generators for large topologies
-- Optimize GraphQL queries to fetch only needed data
-
 ## Additional resources
 
-- **Infrahub SDK documentation**: [docs.infrahub.app/python-sdk/](https://docs.infrahub.app/python-sdk/)
-- **Infrahub schema guide**: [docs.infrahub.app/topics/schema/](https://docs.infrahub.app/topics/schema/)
+- **Infrahub documentation**: [docs.infrahub.app/](https://docs.infrahub.app/)

docs/docs/enterprise.mdx

@@ -30,7 +30,7 @@ export INFRAHUB_ENTERPRISE="true"
 | Variable | Default | Description |
 |----------|---------|-------------|
 | `INFRAHUB_ENTERPRISE` | `false` | Set to `true` to use Enterprise edition |
-| `INFRAHUB_VERSION` | `stable` | Infrahub version to use (for example, `1.5.0b1`, `stable`, `develop`) |
+| `INFRAHUB_VERSION` | `stable` | Infrahub version to use (for example, `1.5.0`, `stable`, `develop`) |
 | `INFRAHUB_ADDRESS` | `http://localhost:8000` | Infrahub API address |
 | `INFRAHUB_API_TOKEN` | (demo token) | API authentication token |
 
@@ -67,8 +67,8 @@ You should see output similar to:
 
 ```bash
 Infrahub Edition: Enterprise
-Version: 1.5.0b1
-Command: curl -s https://infrahub.opsmill.io/enterprise/1.5.0b1 | ...
+Version: 1.5.0
+Command: curl -s https://infrahub.opsmill.io/enterprise/1.5.0 | ...
 ```
 
 ### Step 4: restart Infrahub
@@ -91,19 +91,6 @@ The `destroy` command removes all containers and data volumes. If you have data
 
 After switching editions, you'll need to reload your schemas and data:
 
-```bash
-# Load schemas
-uv run infrahubctl schema load schemas
-
-# Load menu definitions
-uv run infrahubctl menu load menu
-
-# Load bootstrap data
-uv run infrahubctl object load objects/bootstrap
-```
-
-Or use the bootstrap command:
-
 ```bash
 uv run invoke bootstrap
 ```
@@ -161,7 +148,7 @@ This displays:
 Enterprise edition includes additional capabilities not available in Community edition. For details on specific enterprise features, refer to the [Infrahub documentation](https://docs.infrahub.app).
 
 :::info
-Enterprise edition may require valid licensing credentials or enterprise authentication. Contact OpsMill for enterprise licensing information.
+Enterprise edition requires valid licensing for production usage. Contact OpsMill for enterprise licensing information.
 :::
 
 ## Troubleshooting
@@ -182,13 +169,9 @@ If you get errors about missing environment variables:
 2. Make sure you're running commands from the demo repository root
 3. Source the file explicitly: `source .env`
 
-### Version compatibility
-
-Ensure your `INFRAHUB_VERSION` setting is compatible with Enterprise edition. Some development or beta versions may not have Enterprise builds available.
-
 ## Best practices
 
-- **Use explicit versions** - Instead of `stable`, specify exact versions like `1.5.0b1` for reproducible environments
+- **Use explicit versions** - Instead of `stable`, specify exact versions like `1.5.0` for reproducible environments
 - **Document your choice** - Note which edition you're using in project documentation
 - **Test on Community first** - Validate your schemas and generators on Community edition before deploying to Enterprise
 - **Keep configurations in sync** - If working in a team, ensure everyone uses the same edition for consistency

docs/docs/security-management.mdx

@@ -28,9 +28,13 @@ Before starting this tutorial, ensure you have:
 The security data is loaded as part of the bootstrap process. If you haven't loaded it yet, run `uv run infrahubctl object load objects/security/` followed by `uv run python scripts/populate_security_relationships.py` to populate the many-to-many relationships.
 :::
 
-## Understanding the security schema
+## Understanding the demo security schema
 
-Infrahub's security management schema provides a comprehensive data model for firewall policies, zones, services, and applications. The schema is organized into several categories of security objects that work together to define complete security policies.
+The demo security management schema in this repository provides an example data model for firewall policies, zones, services, and applications. The schema is organized into several categories of security objects that work together to define complete security policies.
+
+:::info
+As Infrahub provides the user a flexible schema, this specific security schema implementation serves as an example of what is possible, not a finished solution. The value of Infrahub is the ability to create a specific schema to the needs of your organization.
+:::
 
 ### Security schema architecture
 
@@ -505,5 +509,5 @@ Now that you understand security management in Infrahub, you can:
 For deeper understanding:
 
 - **[Understanding the concepts](./concepts.mdx)** - Learn about schema-driven data modeling
-- **[Developer guide](./developer-guide.mdx)** - Understand how transforms and templates work
+- **[Developer guide](./developer-guide.mdx)** - Understand how transformations and templates work
 - **[Infrahub security schema](https://github.com/opsmill/infrahub-demo/blob/main/schemas/extensions/security/security.yml)** - Review the complete schema definition

docs/docs/user-walkthrough.mdx

@@ -126,7 +126,7 @@ To explore Arista EOS configurations, you can use the automated demo command:
 uv run invoke demo-dc-arista
 ```
 
-This command creates a branch, loads the Arista design, and waits for generator completion.
+This command creates a branch, loads the Arista design, waits for generator completion, then creates a proposed change.
 
 For other vendors, load the design files directly:
 
@@ -375,23 +375,3 @@ If you encounter merge conflicts:
 1. Review the conflicting objects
 2. Resolve conflicts manually if needed
 3. You may need to rebase your branch or create a new branch
-
-## Using the CLI for the workflow
-
-You can also perform this entire workflow from the command line. Here's the abbreviated version:
-
-```bash
-# Create branch
-uv run infrahubctl branch create add-dc3
-
-# Load design (this automatically triggers the generator)
-uv run infrahubctl object load objects/dc/dc-arista-s.yml --branch add-dc3
-
-# Monitor generator progress in the web interface (System → Tasks)
-# Create proposed change (easier via web interface)
-
-# After merge, verify on main
-uv run infrahubctl branch list
-```
-
-For complex workflows involving proposed changes and monitoring generator execution, the web interface provides a better experience with visual feedback and real-time status updates.

schemas/base/dcim.yml

@@ -12,8 +12,7 @@ generics:
       - name__value
     order_by:
       - name__value
-    display_labels:
-      - name__value
+    display_label: "{{ name__value }}"
     attributes:
       - name: name
         kind: Text
@@ -172,8 +171,7 @@ generics:
     human_friendly_id:
       - device__name__value
       - name__value
-    display_labels:
-      - name__value
+    display_label: "{{ name__value }}"
     attributes:
       - name: name
         kind: Text
@@ -323,8 +321,7 @@ nodes:
     icon: mdi:poll
     human_friendly_id:
       - name__value
-    display_labels:
-      - name__value
+    display_label: "{{ name__value }}"
     order_by:
       - manufacturer__name__value
       - name__value
@@ -386,8 +383,7 @@ nodes:
     icon: mdi:application-cog-outline
     human_friendly_id:
       - name__value
-    display_labels:
-      - name__value
+    display_label: "{{ name__value }}"
     order_by:
       - manufacturer__name__value
       - name__value
@@ -514,8 +510,7 @@ nodes:
       - DcimEndpoint
       - DcimSubInterface
     include_in_menu: false
-    display_labels:
-      - name__value
+    display_label: "{{ name__value }}"
 
     attributes:
       - name: interface_type
@@ -604,8 +599,7 @@ nodes:
       - DcimInterface
       # - DcimSubInterface # Depending if you want your virtual interfaces to have sub interface
     include_in_menu: false
-    display_labels:
-      - name__value
+    display_label: "{{ name__value }}"
     # human_friendly_id:
     #   - device__name__value
     #   - name__value