I propose we introduce a new top level field in the Hardware CR, instance. An Instance would be data that changes more frequently than the physical characteristics of a machine. This data would generally correspond to information the current operating system on the Hardware uses to configure and identify itself. Or information that is used in the provisioning process of the Hardware. This is in contrast to the facts about Hardware which would/should describe the physical characteristics of a machine and change very infrequently. These facts would move to a field named, attributes. As part of this we should move all state fields to the status part of the CRD.
Why
Currently the v1alpha1 API for Hardware holds facts and some instance data and state about a machine. This means that when state is defined (CAPT uses this, for example), some things like GitOps for Hardware becomes tricky and sometimes infeasible. While state for a Hardware object, or any CR object, is not implicitly bad, this state most often should be in the "status" of an object, not in the "spec".
Examples
The following are example of what could be in "spec" for each category.
I propose we introduce a new top level field in the Hardware CR, instance. An Instance would be data that changes more frequently than the physical characteristics of a machine. This data would generally correspond to information the current operating system on the Hardware uses to configure and identify itself. Or information that is used in the provisioning process of the Hardware. This is in contrast to the facts about Hardware which would/should describe the physical characteristics of a machine and change very infrequently. These facts would move to a field named, attributes. As part of this we should move all state fields to the status part of the CRD.
Why
Currently the v1alpha1 API for Hardware holds facts and some instance data and state about a machine. This means that when state is defined (CAPT uses this, for example), some things like GitOps for Hardware becomes tricky and sometimes infeasible. While state for a Hardware object, or any CR object, is not implicitly bad, this state most often should be in the "status" of an object, not in the "spec".
Examples
The following are example of what could be in "spec" for each category.
Instance data
Attribute data