Infrahub - v1.2.0b1

Release 1.2.0

Infrahub 1.2 contains both highly anticipated new features as well as bug-fixes and performance improvements to resolve issues found in Infrahub v1.1.6 and prior.

Main changes

One of the key features in this release, is the ability to define a Template for an object in Infrahub.
In addition, we've added a new detailed Activity Log, and enhanced the Webhook functionality.

We have also made several improvements to the UI for a cleaner look, including a more compact and reorganized builtin menu.

There are also quite a few performance improvements, including a faster object list retrieval and an optimized query for saving a diff.

See the detailed changelog in the following sections for more information on the above and more!

Templates

One often-requested feature was the ability to define a Template for an object in Infrahub, which we are happy to introduce in this release.

This feature allows you to define a Template for an object in Infrahub, which can then be used to create new objects with the same properties and relationships.

To create a Template, you need to set the generate_template property to true in the schema of the object you want to create a Template for.
Once the Template is created, you can use it to create new objects with the same properties and relationships.

Documentation

For more information on Templates, please see the below documentation.

• https://docs.infrahub.app/

Activity log

The Activity Log is a powerful tool that allows you to see all the changes that have been made to an object,
and to track the history of any object in Infrahub.
This information is critical for auditing purposes, as well as for debugging and troubleshooting.
While it has always been stored in the Infrahub database, it was not readily available in the UI until this release.

The Activity Log includes all the changes that have been made to the object, as well as all the relationships that have been added or removed.
This information is available on the right side of the node details view (for Activities related to a specific object), as well as under Activity/Activity Log in the menu (for all objects).

Screenshots

Example of the Activity Log page:

Each entry can be expanded to see more details, as well as any related child/sub-activities:

Finally, for any given object, the right side of the detail view now shows related activities:

Webhook enhancements

The Webhook functionality has been enhanced in this release to provide more flexibility and control over the Webhooks that are triggered in Infrahub.
This work is closely tied to previous and ongoing work to provide a more flexible and powerful event system in Infrahub.

Previously, Webhooks were only triggered based on node specific events.
Webhooks can now be triggered based on the following events:

• infrahub.artifact.created
• infrahub.artifact.updated
• infrahub.node.created
• infrahub.node.updated
• infrahub.node.deleted
• infrahub.branch.created
• infrahub.branch.merged
• infrahub.branch.rebased
• infrahub.branch.deleted
• infrahub.group.member_added
• infrahub.group.member_removed

There remain two types of Webhooks available to users, Standard and Custom.
Both can be triggered by the above events, but differ in the following ways:

1. Standard Webhooks send a payload to the configured destination in response to one of the selected event types (or all events).
2. Custom Webhooks trigger the same as Standard Webhooks, but are also able to execute a custom Infrahub Transformation to manipulate the data in the payload.

Below are several screenshots of the new Webhook page. First is the list view for all configured Webhooks:

And here is the view of editing or creating a Custom Webhook:

Documentation

For more information on Webhooks, please see the below documentation.

• https://docs.infrahub.app/

UI enhancements

The builtin menu has been reorganized and enhanced in this release, to provide a better user experience.

The goal of this reorganization is to make it easier to find the objects you are looking for, and to provide a more consistent experience across the different objects.
For example, the "Unified Storage" and "Change Control" sections have been deprecated, and their contents moved to either Object Management or Integrations to be more aligned with the purpose of each page.

In addition to this reorganization, the sub-menus in the sidebar now support icons, which makes it easier to identify the objects you are looking for.
The top menu has also been made more compact, to provide a cleaner look.

Changelog

The complete list of changes can always be found in the CHANGELOG.md file in the Infrahub Git repository.

Added

• Added Containerlab to the GitHub Codespace base image. (#458)
• Added validation to the UI for min_count and max_count in relationships fields. (#5661)
• Added a new feature to create object templates when setting generate_template: true in a schema on a node.
• Added activities logs into the node details view.
• Added icon support to sub-menu items in the sidebar.
• Improved Infrahub app layout for a cleaner look. Made the top menu more compact.

Changed

• Replaced PrefixPool with netaddr.IPSet. (#3547)
• Modified the query analyzer to not list all potential meta data models when only querying for "source" or "owner" ID. The full models will still show up if a fragment is used under the meta data properties. This change makes it easier to setup fine grained permissions and also speeds up the permission lookup as it doesn't require as many checks. (#4644)
• Improved the performance of the cypher query that saves a diff.
• Improved typing of GraphQL schema by defining list as non-nullable and ensure that top level item are mandatory.
• Made object list retrieval faster with an optimized query.
• Reorganized builtin/default menu to provide a better user experience.
• Updated Infrahub account tokens view:
  • Redesigned for a faster, cleaner experience.
  • Improved clarity and formatting of expiration dates.
  • Resolved an issue where expiration data was not being sent to the API.
• Updated the DiffUpdate mutation to return the id of the task when wait_until_completion is False. Also the argument wait_for_completion under data is deprecated and it has been replaced with wait_until_completion at the root of the mutation instead to align with the format of the other mutations.

Fixed

• Fixed an event error in event state after merging a proposed change, they were incorrectly set as "merging" instead of "merged". (#5600)
• Fixed an error in the query to count the number of peers for a given cardinality-many relationship. Previous logic could have resulted in the count being multiplied by a power of 2 if changes were made to the relationship during a merge.

Housekeeping

• Activated ruff B rules. (#2193)
• Activated ruff C4 rule. (#2194)
• Added a basic integration test for the HTTP service adapter. (#5553)

Migration guide

The process to migrate your instance of Infrahub to the latest version may vary depending on your deployment of Infrahub.
However, at a high-level, it will involve getting the latest version of the Infrahub code, and then performing any needed Database Migrations and Schema updates.

Please ensure you have a backup of your Infrahub environment prior to attempting any migration or upgrade activities.

Migration of an Infrahub instance

First, update the Infrahub version running in your environment.

Below are some example ways to get the latest version of Infrahub in your environment.

• For deployments via Docker Compose, update your container version by updating the VERSION environment variable and relaunch:
  • export VERSION="1.2.0"; docker compose pull && docker compose up -d
• For deployments via Kubernetes, utilize the latest version of the Helm chart supplied with this release

Second, once you have gotten the desired version of Infrahub in your envi...

Infrahub - v1.2.0rc0

Infrahub - v1.2.0rc0 - 2025-02-23

This is a Release Candidate; do not use it in production environments.

Added

• Added Containerlab to the codespace base image. (#458)
• • We added validation on UI for min_count and max_count in relationships fields. (#5661)
• • Improved Infrahub app layout for a cleaner look.
  • Made the top menu more compact.
• Add activities logs in the nodes details view
• Add new feature to create object templates when setting generate_template: true in a schema on a node

Changed

• Replace PrefixPool with netaddr.IPSet (#3547)

• Modified query analyzer to not list all potential meta data models when only querying for "source" or "owner" ID. The full models will still show up if a fragment is used under the meta data properties. This change makes it easier to setup fine grained permissions and also speeds up the permission lookup as it doesn't require as many checks. (#4644)

• • We made object list retrieval faster with an optimized query.

• Improve typing of GraphQL schema by defining list as non-nullable and ensure that top level item are mandatory.

• Reorganized builtin/default menu to provide a better user experience.

• Updated Infrahub account tokens view:

  • Redesigned for a faster, cleaner experience
  • Improved clarity and formatting of expiration dates.
  • Resolved an issue where expiration data was not being sent to the API.

Fixed

• Set correct state in events after merging a proposed change, they were incorrectly set as "merging" instead of "merged" (#5600)

Housekeeping

• Activate ruff B rules. (#2193)
• Activate ruff C4 rule. (#2194)
• Add basic integration test for the HTTP service adapter (#5553)

Infrahub - v1.1.7

Release 1.1.7

This release brings some changes and bug-fixes to resolve issues found in Infrahub v1.1.6 and prior.

Main changes

The complete list of changes can always be found in the CHANGELOG.md file in the Infrahub Git repository.

Added

• Data diffs are loaded in sequential batches for faster performance with large changes.
• The diff tree and diff list can now be scrolled independently.

Changed

• Modified node mutation events to not send metadata properties as part of the mutation payload. The reason is that the property lookup was time consuming. This information will return again in Infrahub 1.2 with a completely updated format. (#5664)

Fixed

• Fix nodes remaining in the database after a create mutation fails when using pools. (#4303)
• Modify the query for the current tasks, ensuring the correct determination of the merge button state. (#5565)
• Fix Docker task-manager-db PostgreSQL health check test by adding database and user parameters. (#5739)
• Fixed issue causing a gap in menu sidebar when text is too long.
• Prevent avatar from being cut off in menu sidebar.
• Enforce permission checks when using relationship add or delete mutation.
• Enhance the data integrity checks UI to enable navigation from the check to the diff view.
• Improved performance when updating an existing diff.

Migration guide

The process to migrate your instance of Infrahub to the latest version may vary depending on your deployment of Infrahub.
However, at a high-level, it will involve getting the latest version of the Infrahub code, and then performing any needed Database Migrations and Schema updates.

Please ensure you have a backup of your Infrahub environment prior to attempting any migration or upgrade activities.

Migration of an Infrahub instance

First, update the Infrahub version running in your environment.

Below are some example ways to get the latest version of Infrahub in your environment.

• For deployments via Docker Compose, update your container version by updating the VERSION environment variable and relaunch:
  • export VERSION="1.1.7"; docker compose pull && docker compose up -d
• For deployments via Kubernetes, utilize the latest version of the Helm chart supplied with this release

Second, once you have gotten the desired version of Infrahub in your environment, please run the following commands.

Note: If you are running Infrahub in Docker/K8s, these commands need to run from a container where Infrahub is installed.

infrahub db migrate
infrahub db update-core-schema

Finally, restart all instances of Infrahub.

Migration of a dev or demo instance

If you are using the dev or demo environments, we have provided invoke commands to aid in the migration to the latest version.
The below examples provide the demo version of the commands, however similar commands can be used for dev as well.

invoke demo.stop
invoke demo.build
invoke demo.migrate
invoke demo.start

If you don't want to keep your data, you can start a clean instance with the following command.

Warning: All data will be lost, please make sure to backup everything you need before running this command.

invoke demo.destroy demo.build demo.start demo.load-infra-schema demo.load-infra-data

The repository https://github.com/opsmill/infrahub-demo-edge has also been updated, it's recommended to pull the latest changes into your fork.

Infrahub - v1.1.6

Release 1.1.6

This release brings exciting new features to Infrahub's Artifact capability, as well as bug-fixes to resolve issues found in Infrahub v1.1.5 and prior.

Main changes

The complete list of changes can always be found in the CHANGELOG.md file in the Infrahub Git repository.

Artifact improvements

As part of our ongoing efforts to enhance the integrations and capabilities of Infrahub, the Artifact detail page has been redesigned.

This redesign focused on allowing a richer and more powerful Artifact experience.
Enhancements include support for additional content-types (as listed below), colorized syntax highlighting, and easier access to download or copy artifacts.

Supported Artifact Content Types:

• Markdown
• YAML
• JSON
• Text
• SVG

Examples

Markdown with syntax highlighting:

Markdown rendered for preview:

Text:

YAML:

JSON:

SVG:

Added

• Allow Default Address Type quick selection in the Resource Manager form (#3489)
• Added code viewer for new content-types, preview of raw markdown content, one-click file download or cop, and redesign of artifact details view (#5452)

Fixed

• Automatically mark hierarchical nodes parent relationship as optional if the parent is of the same kind or mandatory if the parent is of a different kind (#3682)
• Revert back to state=open from state=merging if the merge of a proposed change fails.
  This fixes the possibility of leaving a proposed change in an unexpected state. (#5563)
• Fixes an issue with retrieving object from S3 storage backend. (#5573)
• Loosened requirement for group discovery using OIDC and id_token. This will probably be reverted or presented as a configuration option in the future. (#5623)
• Significant improvements to diff calculation performance.

Migration guide

The process to migrate your instance of Infrahub to the latest version may vary depending on your deployment of Infrahub.
However, at a high-level, it will involve getting the latest version of the Infrahub code, and then performing any needed Database Migrations and Schema updates.

Please ensure you have a backup of your Infrahub environment prior to attempting any migration or upgrade activities.

Migration of an Infrahub instance

First, update the Infrahub version running in your environment.

Below are some example ways to get the latest version of Infrahub in your environment.

• For deployments via Docker Compose, update your container version by updating the VERSION environment variable and relaunch:
  • export VERSION="1.1.6"; docker compose pull && docker compose up -d
• For deployments via Kubernetes, utilize the latest version of the Helm chart supplied with this release

Second, once you have gotten the desired version of Infrahub in your environment, please run the following commands.

Note: If you are running Infrahub in Docker/K8s, these commands need to run from a container where Infrahub is installed.

infrahub db migrate
infrahub db update-core-schema

Finally, restart all instances of Infrahub.

Migration of a dev or demo instance

If you are using the dev or demo environments, we have provided invoke commands to aid in the migration to the latest version.
The below examples provide the demo version of the commands, however similar commands can be used for dev as well.

invoke demo.stop
invoke demo.build
invoke demo.migrate
invoke demo.start

If you don't want to keep your data, you can start a clean instance with the following command.

Warning: All data will be lost, please make sure to backup everything you need before running this command.

invoke demo.destroy demo.build demo.start demo.load-infra-schema demo.load-infra-data

The repository https://github.com/opsmill/infrahub-demo-edge has also been updated, it's recommended to pull the latest changes into your fork.

Infrahub - v1.1.5

Release 1.1.5

This release is a bug-fix release to resolve issues found in Infrahub v1.1.4 and prior.

Main changes

The complete list of changes can always be found in the CHANGELOG.md file in the Infrahub Git repository.

Added

• Allow OIDC providers to fall back to id_token for group membership reports if they are not provided within the userinfo URL. This allows for group support using Azure. (#5464)
• Add computed attributes display in schema visualizer to display the jinja2 and python transforms details. (#5515)

Fixed

• Prevent branches in a remote Git repository from being imported if they have conflicts. This can be checked in the repository task logs. (#5085)
• Correct the form to ensure it retrieves all values from the profile accurately. (#5276)
• Fix the multi select update mutation when removing all items. (#5334)
• Fix parent filter rule for relationships in forms to not mark as required if the field is required. (#5418)
• Ensure Transforms are executed with the correct timeout. (#5456)
• Fix unexpected Too many relationships error while retrieving multiple nodes having the same parent. (#5474)
• The name of generated artifacts is now using artifact_name, from the artifact definition, instead of the name of the definition itself. Existing artifacts will be renamed the next time they are generated. (#5484)
• Switch Docker health check from /api/schema/summary to /api/config, to ensure that the health check works when Infrahub is configured to disallow anonymous read access. (#5522)
• Improved format of data and schema integrity error messages on a Proposed Change to include more information.

Migration guide

The process to migrate your instance of Infrahub to the latest version may vary depending on your deployment of Infrahub.
However, at a high-level, it will involve getting the latest version of the Infrahub code, and then performing any needed Database Migrations and Schema updates.

Please ensure you have a backup of your Infrahub environment prior to attempting any migration or upgrade activities.

Migration of an Infrahub instance

First, update the Infrahub version running in your environment.

Below are some example ways to get the latest version of Infrahub in your environment.

• For deployments via Docker Compose, update your container version by updating the VERSION environment variable and relaunch:
  • export VERSION="1.1.5"; docker compose pull && docker compose up -d
• For deployments via Kubernetes, utilize the latest version of the Helm chart supplied with this release

Second, once you have gotten the desired version of Infrahub in your environment, please run the following commands.

Note: If you are running Infrahub in Docker/K8s, these commands need to run from a container where Infrahub is installed.

infrahub db migrate
infrahub db update-core-schema

Finally, restart all instances of Infrahub.

Migration of a dev or demo instance

If you are using the dev or demo environments, we have provided invoke commands to aid in the migration to the latest version.
The below examples provide the demo version of the commands, however similar commands can be used for dev as well.

invoke demo.stop
invoke demo.build
invoke demo.migrate
invoke demo.start

If you don't want to keep your data, you can start a clean instance with the following command.

Warning: All data will be lost, please make sure to backup everything you need before running this command.

invoke demo.destroy demo.build demo.start demo.load-infra-schema demo.load-infra-data

The repository https://github.com/opsmill/infrahub-demo-edge has also been updated, it's recommended to pull the latest changes into your fork.

Infrahub - v1.1.4

Release 1.1.4

This release is a bug-fix release to resolve issues found in Infrahub v1.1.3 and prior.

Main changes

The complete list of changes can always be found in the CHANGELOG.md file in the Infrahub Git repository.

Removed

• Removed configuration option for experimental feature "pull request", since this feature was active in the configuration it has been renamed proposed change and is no longer experimental but always enabled. (#5409)

Added

• Artifacts can now be of type: YAML, XML, markdown, SVG and CSV. (#5452)

Changed

• Updated Infrahub SDK to version 1.6.1.

Fixed

• Fix issue when loading multiple schema files due to load order, schemas are now merged into a single one before importing (#4188)
• Accessibility improvements to homepage: Helper cards now scale based on user's defined font size.
• Task status indicators now poll for updates only when tab is focused.

Migration guide

The process to migrate your instance of Infrahub to the latest version may vary depending on your deployment of Infrahub.
However, at a high-level, it will involve getting the latest version of the Infrahub code, and then performing any needed Database Migrations and Schema updates.

Please ensure you have a backup of your Infrahub environment prior to attempting any migration or upgrade activities.

Migration of an Infrahub instance

First, update the Infrahub version running in your environment.

Below are some example ways to get the latest version of Infrahub in your environment.

• For deployments via Docker Compose, update your container version by updating the VERSION environment variable and relaunch:
  • export VERSION="1.1.4"; docker compose pull && docker compose up -d
• For deployments via Kubernetes, utilize the latest version of the Helm chart supplied with this release

Second, once you have gotten the desired version of Infrahub in your environment, please run the following commands.

Note: If you are running Infrahub in Docker/K8s, these commands need to run from a container where Infrahub is installed.

infrahub db migrate
infrahub db update-core-schema

Finally, restart all instances of Infrahub.

Migration of a dev or demo instance

If you are using the dev or demo environments, we have provided invoke commands to aid in the migration to the latest version.
The below examples provide the demo version of the commands, however similar commands can be used for dev as well.

invoke demo.stop
invoke demo.build
invoke demo.migrate
invoke demo.start

If you don't want to keep your data, you can start a clean instance with the following command.

Warning: All data will be lost, please make sure to backup everything you need before running this command.

invoke demo.destroy demo.build demo.start demo.load-infra-schema demo.load-infra-data

The repository https://github.com/opsmill/infrahub-demo-edge has also been updated, it's recommended to pull the latest changes into your fork.

Infrahub - v1.1.3

Release 1.1.3

This release is a bug-fix release to resolve issues found in Infrahub v1.1.2 and prior.

Main changes

The complete list of changes can always be found in the CHANGELOG.md file in the Infrahub Git repository.

Added

• Add a new link in the object details button to redirect to the tasks list with a filter for the current object

Changed

• Add ID and HFID copy buttons in a new action buttons for the object details (#4648)
  • Remove the ID attribute from the list
  • Get the description from the object if that's possible, if not then from the schema
• Disable action buttons depending on the on going tasks for the different workflows (merge, rebase, validate)
• Display multiple related nodes in the tasks list and details views
• Changed the default value for the s3.default_acl configuration setting to private

Fixed

• Prevent access to REST API endpoints for anonymous user when anonymous access is not allowed (#5312)
• Fix pool exhaustion error for IP resource pools when some allocated nodes were deleted (#5315)
• Fix IP address being displayed in IP prefix pool after deleting the allocated prefix it was part of (#5316)
• Fixed text overflow when there is too many options when selecting a relationship with a hierarchical model (#5431)
• Allow to change any attributes and relationships when using a mutation on CoreAccount (#5455)
• Validate updates to an attribute's kind when loading a new schema (#5460)

Migration guide

The process to migrate your instance of Infrahub to the latest version may vary depending on your deployment of Infrahub.
However, at a high-level, it will involve getting the latest version of the Infrahub code, and then performing any needed Database Migrations and Schema updates.

Please ensure you have a backup of your Infrahub environment prior to attempting any migration or upgrade activities.

Migration of an Infrahub instance

First, update the Infrahub version running in your environment.

Below are some example ways to get the latest version of Infrahub in your environment.

• For deployments via Docker Compose, update your container version by updating the VERSION environment variable and relaunch:
  • export VERSION="1.1.3"; docker compose pull && docker compose up -d
• For deployments via Kubernetes, utilize the latest version of the Helm chart supplied with this release

Second, once you have gotten the desired version of Infrahub in your environment, please run the following commands.

Note: If you are running Infrahub in Docker/K8s, these commands need to run from a container where Infrahub is installed.

infrahub db migrate
infrahub db update-core-schema

Finally, restart all instances of Infrahub.

Migration of a dev or demo instance

If you are using the dev or demo environments, we have provided invoke commands to aid in the migration to the latest version.
The below examples provide the demo version of the commands, however similar commands can be used for dev as well.

invoke demo.stop
invoke demo.build
invoke demo.migrate
invoke demo.start

If you don't want to keep your data, you can start a clean instance with the following command.

Warning: All data will be lost, please make sure to backup everything you need before running this command.

invoke demo.destroy demo.build demo.start demo.load-infra-schema demo.load-infra-data

The repository https://github.com/opsmill/infrahub-demo-edge has also been updated, it's recommended to pull the latest changes into your fork.

Infrahub - v1.1.2

Release 1.1.2

This release is a bug-fix release to resolve issues found in Infrahub v1.1.1 and prior.

Main changes

The complete list of changes can always be found in the CHANGELOG.md file in the Infrahub Git repository.

Null values in uniqueness constraints

Previous to v1.1.2, NULL values were incorrectly ignored in uniqueness constraints;
as of this release, NULL values will be treated properly by the uniqueness logic.

Because the previous logic could have resulted in unintended behavior, upgrading v1.1.2 will perform a database migration for data integrity purposes.

Added

• Added a configuration option for INFRAHUB_PUBLIC_URL, which could be required for SSO depending on how Infrahub is published and accessed within your organization. (#5306)
• Add PermissionManager that takes care of validating permissions when executing a GraphQL query or a requesting a REST endpoint by fetching permissions from backends only once per query. (#5350)
• The query InfrahubTask in GraphQL, introduced a new related_nodes field to retrieve multiple related nodes per task.

Changed

• The fields related_node and related_node_kind on the GraphQL query InfrahubTask have been deprecated, please use related_nodes instead.

Fixed

• Fix schema dropdown option removal in branches other than the default one (#5242)
• Fix an issue that would prevent creating a node on a branch with a computed attribute that referenced another node on that branch (#5385)
• Update how we calculate an incremental diff to skip potentially expensive operations if at all possible
• Update uniqueness checks/constraints logic to consider NULL values instead of ignoring.
  This might cause data integrity issues if you have nodes with NULL values for attributes that are part of their
  the uniqueness constraints of their schema. This change includes a database migration that validates data integrity
  using the new uniqueness check/constraint logic and will fail if any uniqueness issues exist.

Migration guide

The process to migrate your instance of Infrahub to the latest version may vary depending on your deployment of Infrahub.
However, at a high-level, it will involve getting the latest version of the Infrahub code, and then performing any needed Database Migrations and Schema updates.

Please ensure you have a backup of your Infrahub environment prior to attempting any migration or upgrade activities.

Migration of an Infrahub instance

First, update the Infrahub version running in your environment.

Below are some example ways to get the latest version of Infrahub in your environment.

• For deployments via Docker Compose, update your container version by updating the VERSION environment variable and relaunch:
  • export VERSION="1.1.2"; docker compose pull && docker compose up -d
• For deployments via Kubernetes, utilize the latest version of the Helm chart supplied with this release

Second, once you have gotten the desired version of Infrahub in your environment, please run the following commands.

Note: If you are running Infrahub in Docker/K8s, these commands need to run from a container where Infrahub is installed.

infrahub db migrate
infrahub db update-core-schema

Finally, restart all instances of Infrahub.

Migration of a dev or demo instance

If you are using the dev or demo environments, we have provided invoke commands to aid in the migration to the latest version.
The below examples provide the demo version of the commands, however similar commands can be used for dev as well.

invoke demo.stop
invoke demo.build
invoke demo.migrate
invoke demo.start

If you don't want to keep your data, you can start a clean instance with the following command.

Warning: All data will be lost, please make sure to backup everything you need before running this command.

invoke demo.destroy demo.build demo.start demo.load-infra-schema demo.load-infra-data

The repository https://github.com/opsmill/infrahub-demo-edge has also been updated, it's recommended to pull the latest changes into your fork.

Infrahub - v1.1.1

Release 1.1.1

This release is a bug-fix release to resolve issues found in Infrahub v1.1.0 and prior.

Main changes

The complete list of changes can always be found in the CHANGELOG.md file in the Infrahub Git repository.

Fixed

• Raise a better error when trying to resolve an invalid HFID for a relationship (#5360)
• Fix an issue with session management that could lead to the crash of the GraphQL resolver
• Fix query response time when the number of historical value for a given attribute is large
• Fixed an issue that prevented using an IP Namespace on a branch

Migration guide

The process to migrate your instance of Infrahub to the latest version may vary depending on your deployment of Infrahub.
However, at a high-level, it will involve getting the latest version of the Infrahub code, and then performing any needed Database Migrations and Schema updates.

Please ensure you have a backup of your Infrahub environment prior to attempting any migration or upgrade activities.

Migration of an Infrahub instance

First, update the Infrahub version running in your environment.

Below are some example ways to get the latest version of Infrahub in your environment.

• For deployments via Docker Compose, update your container version by updating the VERSION environment variable and relaunch:
  • export VERSION="1.1.1"; docker compose pull && docker compose up -d
• For deployments via Kubernetes, utilize the latest version of the Helm chart supplied with this release

Second, once you have gotten the desired version of Infrahub in your environment, please run the following commands.

Note: If you are running Infrahub in Docker/K8s, these commands need to run from a container where Infrahub is installed.

infrahub db migrate
infrahub db update-core-schema

Finally, restart all instances of Infrahub.

Migration of a dev or demo instance

If you are using the dev or demo environments, we have provided invoke commands to aid in the migration to the latest version.
The below examples provide the demo version of the commands, however similar commands can be used for dev as well.

invoke demo.stop
invoke demo.build
invoke demo.migrate
invoke demo.start

If you don't want to keep your data, you can start a clean instance with the following command.

Warning: All data will be lost, please make sure to backup everything you need before running this command.

invoke demo.destroy demo.build demo.start demo.load-infra-schema demo.load-infra-data

The repository https://github.com/opsmill/infrahub-demo-edge has also been updated, it's recommended to pull the latest changes into your fork.

Infrahub - v1.1.0

Release 1.1.0

This release contains both new features and bug-fixes to resolve issues found in Infrahub v1.0.10 and prior.

Main changes

Infrahub 1.1 brings computed attributes, a new (and highly-requested) feature, as well as many behind-the-scenes changes.

See the detailed changelog in the following sections for more information.

Computed attributes

The computed attributes feature enables the dynamic calculation of attribute values based on user-defined logic.
This functionality is valuable in a number of use cases, not least of which is programmatically generating interface or circuit names.
Several users have requested this capability and we are excited to make it available in Infrahub 1.1.

There are two main ways to configure computed attributes, they can be created using either Jinja2 or Python.

For basic use cases, Jinja2-based computed attributes are now available.
To use this style of computed attribute, the user writes a concise Jinja2 template directly into their Schema definition file.
Then, any changes to a field referenced in the template will update the resultant computed attribute automatically.
There are some limitations with Jinja2-based computed attributes however; for example, only direct relationships can be used (a relationship of a relationship is not accessible).

For more complex use cases, with the need for nested relationships or more detailed logic, Python-based computed attributes are also available.
Python-based computed attributes leverage the exiting Python-based transform feature.
Users can define a transformation within the schema to apply to their field, and the attribute is then generated asynchronously by an Infrahub worker.
When using Python-based computed attributes, note that there can be system performance impact with large or complex Python scripts.

See this table in the documentation for a concise comparison of the two types of computed attributes.

Caveats

• Only URL and Text attribute kinds are supported at the moment.

Documentation

For more information on either style of computed attribute, please see the below documentation.

• https://docs.infrahub.app/guides/computed-attributes
• https://docs.infrahub.app/topics/computed-attributes
• https://docs.infrahub.app/topics/transformation

Infrahub task enhancements

As part of Infrahub 1.0, we added a new tool into the system to assist with task management and control.
In Infrahub 1.1, we have now begun to migrate key backend system tasks over to this tool.

What this means in practice for the user is that now Infrahub tasks will have more robust error reporting and supervision.

Some example tasks run in the background by the updated task worker and framework are:

• Rendering a Jinja template.
• Rendering a transform function.
• Executing a check.
• All Git operations (pull/merge/diff).

All of these and more will benefit from migration to the new task framework, providing additional logging capabilities and overall supervision and control.

Finally, this updated task framework has allowed us to add an indicator at the top right of the Infrahub window to give users task status at a glance.
For example, a section of the indicator will change color when tasks are running.
This indicator also serves as quick access to view in-progress or completed tasks.

Remove shared storage requirements for Git

Previous to Infrahub 1.1, task workers needed access to shared storage such as NFS in order to function.

As of 1.1 this requirement is removed, and users are able to distribute task workers without needing shared storage for local Git repositories.
Each task worker now manages its own copy of any required Git repository.

This change not only simplifies deployment of Infrahub in some scenarios, but increases the overall reliability of the system.

Changelog

The complete list of changes can always be found in the CHANGELOG.md file in the Infrahub Git repository.

Removed

• Remove at parameter from GraphQL mutate functions (#3587)
• Remove the "role" attribute of base schema account node. This attribute was no longer useful as roles are defined as dedicated nodes and are tightly related to permissions.
• Remove the /api/diff/data and /api/diff/schema endpoints that have been replaced by the DiffTree GraphQL query

Added

• Add support for computed attributes. The computed attributes allows you to define a schema attribute as read only and provide logic for how the attribute should be updated. The logic that updates a computed attribute can be a Jinja2 template or a Python Transform. Aside from the initial creation when using a Jinja2 template the updates will be done asynchronously in the background. (#3637)
• Add a "deprecation" property to attribute and relationship schema in order to allow users to identify deprecated fields for nodes and provide a user-friendly message about the deprecation reasons. (#4245)
• Enhanced relationship inputs for hierarchical models with a new way to navigate and select objects directly within the hierarchy. (#4636)
• Add ability to use node HFID to create a related node on a generic relationship (#4649)

Changed

• More efficient logic for retrieving cardinality-one relationships within a GraphQL query (#522)
• Change strings referring to file system paths to pathlib.Path objects (#3545)
• Improved response time of menu endpoint

Fixed

• Fix search anywhere so it looks at Groups (#3173)

• Display the IP Namespace for prefixes and IP addresses in the search anywhere (#3577)

• Use the repository object ID as name for its git working copy directory (#4296)

• Search anywhere now supports IPv6 extended format (#4613)

• • Update action buttons UI in the branch details view
  • Pre-fill the source branch select when creating a proposed change from the branch details view
    (#4678)

• Synchronise git repository clones and updates for task workers in order to remove the need for a shared storage (#4789)

• FIX: Resolved edge cases in 'Search Anywhere' that were causing old results to be displayed. (#4863)

• Remove Profile in registry for renamed schema nodes (#4909)

• Forbid changing the "optional" property of an inherited attribute to not break GraphQL schema generation (#4936)

• Send a request to the backend on logout to delete session cookies and prevent remaining information (#4962)

• Fix query to correctly send the variables in the tasks details view (#5002, #5118)

• Update alerts type on errors with proposed changes and branches (#5293)

• • Verify the tasks related to the proposed changes view to show or hide the tasks accordion in the details view
  • Disable the merge button if there is an ongoing merge
  • Add poll-interval to the proposed changes query to be up to date on the state and disable the merge button if the proposed change is already merged

• Add support for irresolvable conflicts to the diff logic and DiffTree GraphQL query

• Fix a bug that prevented updating a relationship during a merge if ONLY the metadata was updated and not the peer.

• Fix permission check when using multiple backends, if one grants a permission the next ones must not be queried.

• Update logic to check if the changes on a branch include schema changes to use the new diff

• Update the api/diff/artifacts endpoint to use a dedicated query

• Verify if the requested branch exists. If it doesn't, it redirects to the homepage on the default branch.

  This helps avoid query issues, such as empty results (for example, an empty menu) or incorrect queries being sent.

Migration guide

The process to migrate your instance of Infrahub to the latest version may vary depending on your deployment of Infrahub.
However, at a high-level, it will involve getting the latest version of the Infrahub code, and then performing any needed Database Migrations and Schema updates.

Please ensure you have a backup of your Infrahub environment prior to attempting any migration or upgrade activities.

Migration of an Infrahub instance

First, update the Infrahub version running in your environment.

Below are some example ways to get the latest version of Infrahub in your environment.

• For deployments via Docker Compose, update your container version by updating the VERSION environment variable and relaunch:
  • export VERSION="1.1.0"; docker compose pull && docker compose up -d
• For deployments via Kubernetes, utilize the latest version of the Helm chart supplied ...