The notion of "canonical facts" is unique to Red Hat Insights. However,
the idea of transmitting a set of facts about a system upon connection
is generic enough that it can still exist as an option in yggd. This
commit renames the "canonical-facts" flag, config value and related
variables to "facts-file" to more accurate reflect what it expects (a
file) and to be generic enough to accept any set of "facts" about the
system.
Notably, this commit does not rename the "canonical_facts" JSON field
in the "connection-status" message; that field name is part of the
agreed JSON schema in the message protocol, so changing that field would
require breaking the protocol. The protocol does have a mechanism for
such a situation; the "version" field of a message can be incremented.
However, for now, I left the field unmodified.
The notion of "canonical facts" is unique to Red Hat Insights. However, the idea of transmitting a set of facts about a system upon connection is generic enough that it can still exist as an option in yggd. This commit renames the "canonical-facts" flag, config value and related variables to "facts-file" to more accurate reflect what it expects (a file) and to be generic enough to accept any set of "facts" about the system.
Notably, this commit does not rename the "canonical_facts" JSON field in the "connection-status" message; that field name is part of the agreed JSON schema in the message protocol, so changing that field would require breaking the protocol. The protocol does have a mechanism for such a situation; the "version" field of a message can be incremented. However, for now, I left the field unmodified.