-
Notifications
You must be signed in to change notification settings - Fork 6
set up base for migrating infield locations from APM to CDM #2159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
doctrino
left a comment
There was a problem hiding this 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: |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
# 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
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
Key Relationships
rootLocationExternalId(string reference)dataExplorationConfig(DirectRelationReference)disciplinesanddataExplorationConfigfrom the same FeatureConfigurationMigration Selection Logic
Only one APM Config is migrated per run:
externalId="APP_CONFIG_V2"externalId="default-config"APIs Used
Test & implementation