--- tags: UI --- # Airship UI CR Management CR :: Represents the State of an Object The notes below tries to discuss the value of creating an interctive generic mechanism into cr's. Guided vs Nut and bolts * State might through lifecycles that are driven by the metadata 1. The ability to manipulate Metadata to drive state changes on the cr's * change labels * change annotations 1. instance vs the Intention * What is declared vs What is in the cluster * Almost an audit type thing? * why do i need this capability * Why is my cluster misbehaving * Why is my function misbehaving * State of the _________________________ ## What CR's do we care about - CRD Object definition - CR is an instance of that objetc definition. Example For BMH CRD that represents a Baremetal Host or a Virtual Machine (vino) CRD -> Extra info CRD + CRD Explainer * 1 BMH CR for each physical machine in the cluster * 1 BMH per VINO VM in the cluster ... For the instance kubectl get crd ? - baremetalmachines - clusters - ... kubectl api-versions ? kubectl get baremetalmachines ... For the intentions (go pkgs) airshipctl .. bundle? Give baremetalmachines .... ## What about caring for versions ?