Multiple calls to fablib.get_slice(name) in the same interpreter yield different objects

[nbastin]

I'm not sure this is an intentional design choice, but it does create a bunch of problems for tools because then all downstream objects are also unique (leading to Node objects - and probably a lot of other objects - from multiple instances of the same slice being unique objects that don't share identity).

[kthare10]

This is intentional. Each call to get_slice triggers a fresh query to the Control Framework's Graph Model (i.e., the orchestrator). A new slice object is created with the updated graph model in Fablib.

Fablib relies on the Control Framework for the source of truth and does not persist objects. Hope this helps clarify!

[nbastin]

The problem is that in the cases I'm referring to, the old object still exists. So now I can have two objects (or more) with inconsistent state (which thus breaks the idea that the CF is the source of truth). At the very least it would be nice if get_slice referenced a dictionary of weakrefs, so that you would hold the slice object you gave to a caller for as long as the caller does.