Name: InstanceObject

An Instance can represent a compute side entity which directly (Containers,VMs) or indirectly (Service Groups) deals with volumes and files.
Every instance should have an unique identifier defined by the client and it should be unique within SM server. For example, you can prepend the type/namespace identifier of an endpoint with a non-tintri manager (like vCenter, HyperV etc) id to make it unique.
Persistence: Objects are persisted atomically and durably (available across controller).

Data Structure
{
   "typeId": "com.tintri.api.rest.v310.dto.domain.beans.generic.InstanceObject",
   "id": <String>,
   "name": <String>,
   "displayAttributes": InstanceDisplayAttributes,
   "files": [FileObject],
   "volumes": [VolumeObject],
}

Elements
NameTypeDescription
displayAttributesInstanceDisplayAttributesThe display attributes field contains values that have no functional impact, but can be displayed with the object in TGC. The field can be left blank, or included with any fields the integration would like to set. Eventually this should be deprecated, since these fields are only needed in TGC.
filesxsd:list[FileObject]Files assosciated with the instance but independent of instance's volumes.
Optional, can be null. If present, all files should be of same DataProtocol.
The same file cannot be used twice in the same InstanceObject.
volumesxsd:list[VolumeObject]Volumes assosciated with the instance.
Optional, can be null. If present, all volumes' files should be of same DataProtocol.
The same file cannot be used twice in the same InstanceObject.

Attributes
NameTypeDescription
idxsd:stringId of the instance.
Validated for:
Cannot be null.
Starts with the type of the endpoint in which it is created. Every endpoint created will have a type. Consult that api DTO/endpoints for details.
Cannot be more than 159 characters as required by filesystem.
namexsd:stringName of the object. Validated for:
not being null or empty string.
Max length ?