|  | 
|  | 1 | +--- | 
|  | 2 | +title: Manage data with Object Files | 
|  | 3 | +--- | 
|  | 4 | + | 
|  | 5 | +# Manage data with Object files | 
|  | 6 | + | 
|  | 7 | +## Introduction | 
|  | 8 | + | 
|  | 9 | +An Object file is a YAML file that allows you to manage data to be loaded in Infrahub based on your own custom schema. It provides a declarative way to define and manage resources in your Infrahub instance. | 
|  | 10 | + | 
|  | 11 | +Object files work well for models that don't change too often and/or that need to be tracked in Git. Examples include: Groups, tags, Users, etc. | 
|  | 12 | +Below is an example of an Object file that defines tags (`BuiltinTag`). | 
|  | 13 | + | 
|  | 14 | +```yaml | 
|  | 15 | +--- | 
|  | 16 | +apiVersion: infrahub.app/v1 | 
|  | 17 | +kind: Object | 
|  | 18 | +spec: | 
|  | 19 | +  kind: BuiltinTag | 
|  | 20 | +  data: | 
|  | 21 | +    - name: Blue | 
|  | 22 | +    - name: Yellow | 
|  | 23 | +    - name: Red | 
|  | 24 | +``` | 
|  | 25 | +
 | 
|  | 26 | +Object files are meant to be used in an idempotent way and as such they work better for models with a Human Friendly ID (HFID) defined. An HFID is a unique identifier that makes it easier to reference objects across different files and operations. | 
|  | 27 | +
 | 
|  | 28 | +## Load Object files into Infrahub | 
|  | 29 | +
 | 
|  | 30 | +Object files can be loaded into Infrahub using the `infrahub object load` command. | 
|  | 31 | + | 
|  | 32 | +```bash | 
|  | 33 | +infrahub object load <path_to_object_file> | 
|  | 34 | +``` | 
|  | 35 | + | 
|  | 36 | +Multiple object files can be loaded at once by specifying the path to multiple files or by specifying a directory. | 
|  | 37 | + | 
|  | 38 | +The `object load` command will create/update the objects using an `Upsert` operation. All objects previously loaded will NOT be deleted in the Infrahub instance. | 
|  | 39 | +Also, if some objects present in different files are identical and dependent on each other, the `object load` command will NOT calculate the dependencies between the objects and as such it's the responsibility of the users to execute the command in the right order. | 
|  | 40 | + | 
|  | 41 | +### Validate the format of object files | 
|  | 42 | + | 
|  | 43 | +The object file can be validated using the `infrahub object validate` command. | 
|  | 44 | + | 
|  | 45 | +```bash | 
|  | 46 | +infrahub object validate <path_to_object_file> | 
|  | 47 | +``` | 
|  | 48 | + | 
|  | 49 | +## Object file format | 
|  | 50 | + | 
|  | 51 | +All object files must start with the following format, all other formats will be automatically ignored. | 
|  | 52 | +Each file is intended for one specific top level kind, but one file can include multiple nested objects of any kind. | 
|  | 53 | +The kind of the top level object must be defined in spec/kind. | 
|  | 54 | + | 
|  | 55 | +```yaml | 
|  | 56 | +--- | 
|  | 57 | +apiVersion: infrahub.app/v1 | 
|  | 58 | +kind: Object | 
|  | 59 | +spec: | 
|  | 60 | +  kind: <NamespaceName> | 
|  | 61 | +  data: | 
|  | 62 | +    - [...] | 
|  | 63 | +``` | 
|  | 64 | + | 
|  | 65 | +> Multiple documents in a single YAML file are also supported, each document will be loaded separately. Documents are separated by `---` | 
|  | 66 | + | 
|  | 67 | +### Relationship of cardinality one | 
|  | 68 | + | 
|  | 69 | +A relationship of cardinality one can either reference an existing node via its HFID or create a new node if it doesn't exist. | 
|  | 70 | +In the example below, both `site` and `primary_ip` are relationships of cardinality one. | 
|  | 71 | + | 
|  | 72 | +```yaml | 
|  | 73 | +--- | 
|  | 74 | +apiVersion: infrahub.app/v1 | 
|  | 75 | +kind: Object | 
|  | 76 | +spec: | 
|  | 77 | +  kind: InfraDevice | 
|  | 78 | +  data: | 
|  | 79 | +    - name: edge01 | 
|  | 80 | +      site: "Paris"         # Reference existing node via its HFID | 
|  | 81 | +      primary_ip:           # Nested object, will be created if it doesn't exist | 
|  | 82 | +        data: | 
|  | 83 | +            address: "192.168.1.1" | 
|  | 84 | +``` | 
|  | 85 | + | 
|  | 86 | +### Relationship of cardinality many | 
|  | 87 | + | 
|  | 88 | +A relationship of cardinality many can reference existing nodes via their HFID or define nested objects. | 
|  | 89 | + | 
|  | 90 | +#### Existing nodes referenced by their HFID | 
|  | 91 | + | 
|  | 92 | +Existing nodes can be referenced by their HFID in string format or in list format. | 
|  | 93 | +In the example below, both `best_friends` and `tags` are relationships of cardinality many. | 
|  | 94 | + | 
|  | 95 | +> An HFID is composed of a single value, it's possible to use a string instead of a list | 
|  | 96 | + | 
|  | 97 | +```yaml | 
|  | 98 | +--- | 
|  | 99 | +apiVersion: infrahub.app/v1 | 
|  | 100 | +kind: Object | 
|  | 101 | +spec: | 
|  | 102 | +  kind: TestingPerson | 
|  | 103 | +  data: | 
|  | 104 | +    - name: Mike Johnson | 
|  | 105 | +      height: 175 | 
|  | 106 | +      best_friends: # Relationship of cardinality many that references existing nodes based on their HFID | 
|  | 107 | +        - [Jane Smith, Max] | 
|  | 108 | +        - [Sarah Williams, Charlie] | 
|  | 109 | +      tags: | 
|  | 110 | +        - Veterinarian    # Existing Node referenced by its HFID in string format | 
|  | 111 | +        - [Breeder]       # Existing Node referenced by its HFID in list format | 
|  | 112 | +``` | 
|  | 113 | + | 
|  | 114 | +#### Nested objects | 
|  | 115 | + | 
|  | 116 | +When defining nested objects, the node will be automatically created if it doesn't exist and if the relationship between the parent object and the nested object exists, it will be automatically inserted. | 
|  | 117 | +For example, in the example below, the `owner` of a `TestingDog` doesn't need to be specified because it will be automatically inserted. | 
|  | 118 | + | 
|  | 119 | +Two different syntax are supported: | 
|  | 120 | + | 
|  | 121 | +- A dictionary with multiple values under data | 
|  | 122 | +- A list of objects | 
|  | 123 | + | 
|  | 124 | +##### Nested objects as a dictionary | 
|  | 125 | + | 
|  | 126 | +In the example below, `tags` is a relationship of cardinality many that is defined as a dictionary with multiple values under data. | 
|  | 127 | + | 
|  | 128 | +> The kind is optional here because there is only one option possible (not a generic) | 
|  | 129 | + | 
|  | 130 | +```yaml | 
|  | 131 | +--- | 
|  | 132 | +apiVersion: infrahub.app/v1 | 
|  | 133 | +kind: Object | 
|  | 134 | +spec: | 
|  | 135 | +  kind: TestingPerson | 
|  | 136 | +  data: | 
|  | 137 | +    - name: Alex Thompson | 
|  | 138 | +      tags: | 
|  | 139 | +        data: | 
|  | 140 | +          - name: dog-lover | 
|  | 141 | +            description: "Dog Lover" | 
|  | 142 | +          - name: veterinarian | 
|  | 143 | +            description: "Veterinarian" | 
|  | 144 | +``` | 
|  | 145 | + | 
|  | 146 | +This format works well when all objects are of the same kind and when all objects are using the same properties. | 
|  | 147 | +For more complex cases, the list of objects format is more flexible. | 
|  | 148 | + | 
|  | 149 | +##### Nested objects as a list of objects | 
|  | 150 | + | 
|  | 151 | +In the example below, `animals` is a relationship of cardinality many that is defined as a list of objects. | 
|  | 152 | +Each object must contain a `data` key and each object can also define a specific `kind`. | 
|  | 153 | + | 
|  | 154 | +> If the kind is not specified, it will be inferred from schema | 
|  | 155 | + | 
|  | 156 | +```yaml | 
|  | 157 | +--- | 
|  | 158 | +apiVersion: infrahub.app/v1 | 
|  | 159 | +kind: Object | 
|  | 160 | +spec: | 
|  | 161 | +  kind: TestingPerson | 
|  | 162 | +  data: | 
|  | 163 | +    - name: Alex Thompson | 
|  | 164 | +      height: 180 | 
|  | 165 | +      animals: | 
|  | 166 | +        - kind: TestingDog | 
|  | 167 | +          data: | 
|  | 168 | +            name: Max | 
|  | 169 | +            weight: 25 | 
|  | 170 | +            breed: Golden Retriever | 
|  | 171 | +            color: "#FFD700" | 
|  | 172 | +        - kind: TestingCat | 
|  | 173 | +          data: | 
|  | 174 | +            name: Mimi | 
|  | 175 | +            breed: Persian | 
|  | 176 | +``` | 
|  | 177 | + | 
|  | 178 | +### Support for metadata | 
|  | 179 | + | 
|  | 180 | +Metadata support is planned for future releases. Currently, the Object file does not support metadata on attributes or relationships. | 
|  | 181 | + | 
|  | 182 | +## Troubleshooting | 
|  | 183 | + | 
|  | 184 | +### Common issues | 
|  | 185 | + | 
|  | 186 | +1. **Objects not being created**: Ensure that the YAML syntax is correct and that the file follows the required format. | 
|  | 187 | +2. **Dependency errors**: When objects depend on each other, load them in the correct order (dependencies first). | 
|  | 188 | +3. **Validation errors**: Use the `infrahub object validate` command to check for syntax errors before loading. | 
|  | 189 | + | 
|  | 190 | +### Best practices | 
|  | 191 | + | 
|  | 192 | +1. Use Human Friendly IDs (HFIDs) for all objects to ensure consistent referencing. | 
|  | 193 | +2. Keep object files organized by model type or purpose. | 
|  | 194 | +3. Validate object files before loading them into production environments. | 
|  | 195 | +4. Use comments in your YAML files to document complex relationships or dependencies. | 
0 commit comments