It seems useful for a steward to feature a PROBE-RESOURCE which returns a property list. This PROBE-RESOURCE method can be used to detect if a resource no longer exists and can be used by the UPDATE-INSTANCE-FROM-RESOURCE methods, so that updating instances can be implemented generically.
It does not seem useful for resources to have a mandatory NAME, DISPLAYNAME and description. A NAME or a DESIGNATOR could be useful when describing a software stack but requiring them prevents the IMPORT-RESOURCE to work properly. Hence resource DESIGNATORS seem to be indpendant from the resource themselve but are probably attached to the software stack itself.
Some stewards create resources identified by a name provided by the user. The steward must be aware if the resource namespace is global or is scoped to a tenant/project.
When we import a resource, we know the state and the identifier of the resource so that constructors should be able to set these values directly.
The FIND-RESOURCE feature can use a STEWARD as a repository and use custom FILTERS to select resources of a given type matching some criterias.
The docker image blueprint contains all the details about building a docker image, so that the details are capsulated away from the DOCKER-IMAGE itself.
Working on objects that have multiple names and not unique identifiers requires extra care.
~~~ console % docker image rm “sha256:3459897320cfdb7481333856a0900bf09acbb47566cab56d5a2c03f41508f271” Error response from daemon: conflict: unable to delete 3459897320cf (must be forced) - image is referenced in multiple repositories Exit Status > 0 ~~~
It seems like we need a special category of resources or artefacts which can be tagged or labelled, so that we can have a consistent approach. Maybe consider tags and artefacts distinct things?
Infrastructure stacks are by nature heterogeneous collections, how to handle reading and writing them?
WWW http://kevinmahoney.co.uk/articles/heterogeneous-collections/