Deployment Modes and resource definition UUIDs

Ignition
1

stating assumptions here prior to testing, perhaps for discussion about intent vs behavior

  • it appears default core resource.json files don't contain UUIDs
  • it appears manually duplicating resource definitions across deployment modes in in Web UI generates unique UUIDs
    • but perhaps with no author/timestamp/signature
  • presumably identical UUIDs across deployment modes are fine (e.g. copy a mode in the file system)
    • unsure if gateway will modify on startup/scan
  • presumably omitting UUIDs from resource definitions is fine
    • unsure if gateway will generate on startup/scan
  • i generally like to track resource.json since they're useful for author/timestamp/signature (e.g., when a resource is "saved" with no changes) but perhaps they're less useful in deployment modes

longstanding curiousity - why is lastModificationSignature not lastModification.signature (guessing just historical precedent)

2

Which resources are you not seeing with UUIDs? Every named resource should be getting a UUID on creation.

Correct.

The UUID attribute is not related to the signature tracking/last modification stuff.

Between deployment modes is probably fine, but I wouldn't recommend it. Each resource in each location (across deployment modes) should have a unique UUID.

It depends on exactly which resource type. Different subsystems "opt in" to whether they care about the UUID; the only thing the UUID is used for at present is to track renames more intelligently, because some things need to care about that.
For instance, if you rename an internal historian, that means a file on disk that contains stored history needs to get moved. Without the UUID matching on both sides, we would see the rename as though my-old-historian got deleted and a brand new my-new-historian got created. Per the documentation on the NamedResourceHandler that does the bookkeeping automatically, if you don't have a UUID key on a resource that cares about renames, then your resource is just ignored and treated as if it doesn't exist. And no attempt will be made to modify your resource to add a UUID key until something else in the system touches it.

You should still track resource.json files, even though the lastModificationSignature is a perennial annoyance. Anything else is not 'safe'.

1 Like
3 
core/ignition/system-properties/resource.json
core/ignition/security-properties/resource.json
core/ignition/security-levels/resource.json

(i happen to be overriding these, haven't looked elsewhere)

4

FWIW, identical uuids seem much more likely when using the external mode, as that basically requires a manual copy/paste from somewhere

1 Like
5

Those are fine - they're not 'named' resources, so there's no way to "re" name them. Thus, no UUID.

Yeah, that's fair. But again, probably not a problem in practice - nothing inside Ignition can update external.

1 Like
6

ah i see your point (singleton?), but they do get UUIDs when overridden/duplicated into custom deployment modes

7

Got it, yeah, that's probably just a minor bug in the duplicate logic.

1 Like