Variables should support virtualization

[Sulochan Acharya]

Either through a separate attribute, or the variables association itself, it should be feasible to plug in a REST backend that retrieves data on demand from another service.

It may make sense to use the existing values payload for this indirection, making this much like a symbolic link.

[Jim Baker (jimbaker)]

Recent work on resolution_order simplifies this; such support simply needs to look like a read-only Map that is part of the overall ChainMap used in variable resolution.

One additional concern is that such lookup could be relatively expensive if done on demand, but they also seem to be cacheable much like other aspects of the object graph.

[Tomi Juvonen (tomi-juvonen-q)]

If I would like to have tenant/project specific API on "planned host maintenance state" of a specific host(id), it should not matter if it is expensive. Actually this API could be used by tenant after querying his servers via Nova API to query any more specific host(id) state information that is not in "Nova DB" (but perhaps in Craton).

In host fault situation if the same would be used, it would be too expensive (slow). Anyhow in this situation, I would not expect Craton to be involved, but actions done directly from "monitoring" (actually in OPNFV Doctor we can use what ever monitoring SW and we implement "inspector" component like Vitrage that get the raw alarm from monitors and as this "inspector" is then the one first to know the problem and it knows the cloud topology (host, vms, tenants...), it can act on it very fast (mark host down, trigger notif/alarm, call evacuation or some external flow).) Tenant need to know about fault in milliseconds not to compromise any subscriber action like ongoing phone call.