Each object is identified by a UUID and a fully qualified name (FQ name).
- Each object has a parent object (except for top level objects e.g. global-system-config, domain, virtual-machine, etc.)
- E.g. a domain object is parent of project objects
- An object can have any number of child objects
- E.g. a project object can have one or more virtual-network objects and/or one or more network-policy objects as children
- An object can refer to other objects (and conversely, can be referred to by other objects). We say that if an object Obj1 has reference to Obj2, then it means Obj2 has ‘back-reference’ from Obj1.
- E.g. a virtual-network object can refer to one or more network-policy objects. A network-policy object can be referred to by one or more virtual-network objects.
- There can be metadata attached to the reference between two objects.
- E.g. a reference from virtual-network object to network-ipam object can have one or more subnets as metadata on the link
An object can have any number of property elements. These elements can be of simple types (integer, boolean, string) or complex types that contain other data types.
There are APIs to create/delete/update/read/list these objects. The list API can take various filters. Read and list APIs can also take the list of fields to be returned.
It is possible to atomically update a specific field in the object without affecting any other fields. Similarly, it is possible to atomically add or delete a reference without affecting anything else.