Skip to content

Conversation

@erikangelsen-cognite
Copy link
Contributor

@erikangelsen-cognite erikangelsen-cognite commented Nov 3, 2025

InField V2 Config Migration Architecture

https://cognitedata.atlassian.net/browse/FO-2086

Overview

This migration transforms the old APM Config structure into the new InField V2 configuration format, splitting location-specific and shared configuration into separate resources.

Architecture Diagram

┌─────────────────────────────────────────────────────────────┐
│                    Old APM Config                           │
│  ┌──────────────────────────────────────────────────────┐  │
│  │  APMConfig (externalId: "APP_CONFIG_V2" or           │  │
│  │              "default-config")                        │  │
│  │  ┌────────────────────────────────────────────────┐  │  │
│  │  │  FeatureConfiguration                           │  │  │
│  │  │  ├─ rootLocationConfigurations: [loc1, loc2...]│  │  │
│  │  │  ├─ observations                                │  │  │
│  │  │  ├─ activities                                  │  │  │
│  │  │  ├─ documents                                   │  │  │
│  │  │  ├─ notifications                               │  │  │
│  │  │  ├─ assetPageConfiguration                      │  │  │
│  │  │  └─ disciplines                                 │  │  │
│  │  └────────────────────────────────────────────────┘  │  │
│  └──────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────┘
                            │
                            │ Migration
                            ▼
┌─────────────────────────────────────────────────────────────┐
│                   New InField V2 Config                      │
│                                                              │
│  ┌────────────────────────────────────────────────────────┐ │
│  │  DataExplorationConfig (1 per config)                 │ │
│  │  ├─ observations                                      │ │
│  │  ├─ activities                                        │ │
│  │  ├─ documents                                         │ │
│  │  ├─ notifications                                    │ │
│  │  └─ assets                                           │ │
│  └────────────────────────────────────────────────────────┘ │
│                           ▲                                 │
│                           │ DirectRelationReference         │
│                           │                                 │
│  ┌────────────────────────────────────────────────────────┐ │
│  │  InFieldLocationConfig (1 per location)                │ │
│  │  ├─ rootLocationExternalId ───────────┐               │ │
│  │  ├─ featureToggles                     │               │ │
│  │  ├─ appInstanceSpace                   │               │ │
│  │  ├─ accessManagement                  │               │ │
│  │  ├─ disciplines                        │               │ │
│  │  ├─ dataFilters                        │               │ │
│  │  └─ dataExplorationConfig ─────────────┼───────────────┘ │
│  └────────────────────────────────────────────────────────┘ │
│                           │                                 │
│                           │ References via externalId       │
│                           ▼                                 │
│  ┌────────────────────────────────────────────────────────┐ │
│  │  LocationFilter (Fusion) (1 per location)                        │ │
│  │  ├─ name                                              │ │
│  │  ├─ description                                       │ │
│  │  ├─ instanceSpaces                                    │ │
│  │  └─ dataModels                                        │ │
│  └────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘

Key Relationships

  1. InFieldLocationConfig → LocationFilter (Fusion): Via rootLocationExternalId (string reference)
  2. InFieldLocationConfig → DataExplorationConfig: Via dataExplorationConfig (DirectRelationReference)
  3. All locations share: disciplines and dataExplorationConfig from the same FeatureConfiguration

Migration Selection Logic

Only one APM Config is migrated per run:

  • Priority 1: Config with externalId = "APP_CONFIG_V2"
  • Priority 2: Config with externalId = "default-config"
  • Otherwise: No migration is performed

APIs Used

  • Location Filters API: For creating/updating LocationFilter resources
  • Data Modeling Instances API: For creating/updating InFieldLocationConfig and DataExplorationConfig nodes

Test & implementation

  • All migrations have units tests.
  • Successfull migrations done in projects: aws-dub-dev and infield-dev project.

Copy link
Collaborator

@doctrino doctrino left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before I review this any further. Can you describe the overall flow. What is APMConfig in v1 of Infield turned into? From the code it looks like a location filter + a special new config. Is this so?

Furthermore, I think it is sensible that we instead of doing this ad-hoc introduction of InfieV2 config classes, we add support for it in Toolkit in the same way we did for the v1 config. What do you think?

for config in apm_config:
new_config = self._create_infield_v2_config(config)
new_config_nodes.append(new_config)
if not config.feature_configuration or not config.feature_configuration.root_location_configurations:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should at least give a warning rather than silently skipping it.


results = DeployResults([], "deploy", dry_run=dry_run)

# Special handling for InfieldV2ConfigCreator which creates two different resource types
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this true, do you expect APM_Config to turn into location filter(s) and a special Infield v2 configuration?

location_filter.data_models = data_models

# TODO: Add more field migrations here as they are implemented
# - views
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

View selection.
If customer har created Asset or Maintenance order extentions, they must be listed here.
How do we migrate this? Or set it up at initial config creation when using toolkit?

@doctrino doctrino mentioned this pull request Nov 5, 2025
2 tasks
doctrino added a commit that referenced this pull request Nov 6, 2025
# Description

**Context** Cognite Toolkit have `pydantic` classes for all resources we
support. This class is used to validate user input and give good error
messages if they mistype.

This PR add the `InfieldCDMv1YAML` class that will be used when
supporting the new infield configuration format.

I built the `InfieldLocationConfigYAML` based on the
`InfeildLocationConfig` in the `InField` system model, and I used the
#2159 for all the `JSONObjects`.

<img width="1436" height="1004" alt="image"
src="https://github.com/user-attachments/assets/0568b58c-9e91-45e5-9d7f-79fe6432bf81"
/>


## Changelog

- [ ] Patch
- [x] Skip
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants