Skip to main content

Profiles

This topic explains the concept of profiles in Infrahub, their purpose in the system architecture, and how they enable configuration consistency across your infrastructure. You'll gain a deeper understanding of profile inheritance, priority mechanisms, and the design decisions behind this feature.

What are profiles?​

Profiles in Infrahub are configuration templates that define common attribute and relationship values for objects. They represent a fundamental approach to managing configuration at scale by separating the definition of common settings from individual object instances.

Think of profiles as reusable configuration blueprints. Just as a class in object-oriented programming defines properties that instances inherit, profiles define attribute values that objects inherit. This design pattern promotes consistency while maintaining flexibility for exceptions.

Why profiles matter​

The configuration consistency challenge​

In infrastructure management, you often have hundreds or thousands of similar components that need identical configuration. Consider these scenarios:

  • Network interfaces: All user-facing switch ports need the same VLAN, mode, and security settings
  • BGP sessions: Internal BGP peers share common timers, authentication, and policy settings
  • Server configurations: Groups of servers require identical monitoring, logging, and security settings

Without profiles, you would need to:

  • Manually set the same values on each node
  • Risk configuration drift when standards change
  • Lack visibility into which nodes follow which standards
  • Struggle to update configurations consistently

How profiles solve these challenges​

Profiles address these issues through:

  1. Centralized definition: Define configuration once, apply everywhere
  2. Automatic inheritance: Objects automatically receive profile values
  3. Dynamic updates: Changes to profiles propagate to all associated objects
  4. Override capability: Individual objects can still have exceptions
  5. Data lineage: Track where each configuration value originated

Profile architecture and design​

Dynamic schema generation​

Infrahub automatically generates profile schemas based on your node schemas. This design decision ensures:

  • Type safety: Profiles always match their corresponding node type
  • Schema evolution: Profile schemas update automatically when node schemas change
  • No manual maintenance: You never need to define profile schemas separately

For every node type with generate_profile: true (the default), Infrahub creates:

  • A profile schema named Profile<Namespace><NodeName>
  • GraphQL queries and mutations for profile operations
  • Validation logic ensuring profile-node compatibility

Profile components​

Each profile contains:

  1. Core attributes (inherited from CoreProfile):

    • profile_name: Unique identifier (3-32 characters)
    • profile_priority: Numeric priority for inheritance order (default: 1000)

  2. Node-specific attributes and relationships: All attributes and relationships from the corresponding node schema, except:

    • Attributes and relationships that are part of unique constraints
    • Relationships that are not of kind Generic or Attribute

Inheritance mechanism​

Profile inheritance follows a sophisticated model:

Node Creation/Update
       ↓
Check if profiles assigned (If created from a template, inherit its profiles)
       ↓
For each attribute/relationship:
  - Is value explicitly set on node? → Use node value
  - Is default value being used? → Check profiles
       ↓
Check profiles by priority (lowest number first)
       ↓
Use first profile-defined value found
       ↓
If no profile defines it → Use schema default

This mechanism ensures predictable behavior while maintaining flexibility.

Profile priority system​

Understanding priority values​

Profile priority uses numeric values where lower numbers have higher priority. This might seem counterintuitive but aligns with common networking conventions (like route metrics).

Example scenario:

Profile A: priority = 1000 (default)
Profile B: priority = 500  (higher priority)
Profile C: priority = 1500 (lower priority)

Inheritance order: B → A → C

Priority in practice​

Consider a node with three profiles defining MTU:

  • Base profile (priority 1000): MTU = 1500
  • Department profile (priority 500): MTU = 9000
  • Legacy profile (priority 1500): MTU = 1400

The node inherits MTU = 9000 from the department profile (highest priority).

Design rationale​

The priority system enables:

  • Hierarchical configuration: Organization-wide → Department → Team → Special cases
  • Controlled overrides: Higher-priority profiles override lower-priority ones
  • Flexible composition: Combine multiple profiles without conflicts

Data lineage and metadata​

Tracking value origins​

Every attribute in Infrahub maintains metadata about its source:

attribute = {
    "value": "active",
    "is_from_profile": True,
    "is_default": False,
    "source": {
        "id": "17d5a1b2-...",
        "display_label": "ProfileInfraInterface:end-user-interface"
    }
}

This metadata enables:

  • Audit trails: Know exactly where each value came from
  • Impact analysis: Understand which nodes would be affected by profile changes
  • Troubleshooting: Quickly identify why a node has specific values

Metadata properties explained​

  • is_from_profile: Boolean indicating inheritance from a profile
  • is_default: Boolean indicating use of schema default value
  • source: Reference to the specific profile providing the value
  • is_protected: (Future) Will indicate if value is locked from changes

Relationships in profiles​

Infrahub Version

Available since Infrahub 1.7!

Starting with Infrahub 1.7, profiles can define relationship values in addition to attributes. This enables you to set relationships that objects inherit when assigned to a profile.

How relationship inheritance works​

Relationship inheritance in profiles follows the same principles as attribute inheritance:

  1. Cardinality support: Both one and many cardinality relationships are supported:

    • For cardinality one relationships, the profile defines a single related object
    • For cardinality many relationships, the profile defines a set of related objects that the inheriting object will be connected to

  2. Priority-based resolution: When multiple profiles define the same relationship, the profile with the highest priority (lowest priority number) takes precedence.

  3. Override capability: Just like attributes, relationship values can be overridden on individual objects when exceptions are needed.

  4. Metadata tracking: Relationship values inherited from profiles include metadata indicating their source, enabling full data lineage tracking.

Example use cases​

  • VLAN assignment: Define a profile that sets the untagged VLAN for all end-user interfaces
  • Default location assignment: Set a default location or site for objects of a specific type

Profile constraints and limitations​

Current constraints​

  1. Attribute restrictions:

    • Attributes that are part of a uniqueness constraint (and/or HFID) are not supported

  2. Relationship restrictions:

    • Relationships that are part of a uniqueness constraint (and/or HFID) are not supported
    • Only generic and attribute kind relationships are supported

  3. Assignment limitations:

    • Static assignment only (no dynamic rules yet)
    • No conditional logic (if X then apply profile Y)
    • No profile composition (profile extending another profile)

  4. Scope boundaries:

    • Profiles are node-type specific
    • Cannot share profiles across different node types
    • No global or cross-schema profiles

Design rationale for constraints​

These constraints exist to:

  • Maintain data integrity (unique constraints)
  • Ensure predictable behavior (static assignment)
  • Simplify mental model (type-specific profiles)
  • Preserve hierarchy integrity (hierarchical relationships excluded)
  • Enable future enhancements without breaking changes

Mental models for profiles​

Object-oriented inheritance​

Profiles work like class inheritance in programming:

class InterfaceProfile:
    mtu = 1500
    enabled = True
    mode = "access"

class UserInterface(InterfaceProfile):
    name = "GigabitEthernet0/0/1"
    # Inherits mtu, enabled, mode from profile

CSS-like cascading​

Similar to CSS, profiles cascade with priority:

/* Lower priority */
.interface { mtu: 1500; }

/* Higher priority */
.user-interface { mtu: 1500; }

/* Highest priority - direct assignment */
#interface-001 { mtu: 9000; }

Policy-based configuration​

Profiles implement policy-based management where:

  • Policies (profiles) define desired state
  • Nodes subscribe to policies
  • Changes to policies automatically propagate
  • Exceptions are explicitly documented

Future directions​

Planned enhancements​

  1. Dynamic assignment: Rules-based profile application

    if: node.location == "datacenter-1"
    then: apply_profile("dc1-standards")

  2. Profile composition: Profiles extending other profiles

    profile: edge-interface
    extends: base-interface
    overrides:
      mtu: 9000

Architecture evolution​

The profile system is designed to evolve toward:

  • More sophisticated inheritance models
  • Integration with external configuration systems
  • Event-driven profile updates
  • Multi-tenancy with profile isolation

Conclusion​

Profiles in Infrahub represent a thoughtful approach to configuration management that balances consistency with flexibility. By understanding the inheritance model, priority system, and design constraints, you can effectively use profiles to manage infrastructure at scale while maintaining clear configuration lineage and enabling controlled exceptions.

The system's design anticipates future needs while providing immediate value through reduced configuration drift, improved consistency, and clear audit trails. As Infrahub evolves, profiles will become even more powerful while maintaining backward compatibility with current usage patterns.

Guides​

Topics​

  • Schema - Deep dive into schema design and how profiles are generated
  • GraphQL - Understanding Infrahub's GraphQL API for profile operations
  • Metadata - Learn about metadata tracking and data lineage
  • Version control - How profiles work with branches and version control
  • Object templates - How profiles integrate with templates for powerful configuration management

Reference​