We should investigate solutions to whether decoupling control plane and data plane upgrades where Karpenter manages the data plane nodes.

Outcomes we want out of this spike:

1. Do we as the service provider want to provide this decoupling as a advantageous feature specific to ROSA? (Bala mentions that AKS and EKS Karpenter do not decouple).

There's two options that  come out of the above question:

1. If we want to decouple, investigate the engineering work to implement the decoupling.
   1. Estimate the t-shirt size of doing this, and apply it to the overall epic. 
2. If we don't want to decouple, how would we implement Change Management for upgrading the Karpenter managed data plane?
   1. Estimate the t-shirt size of doing this, and apply it to the overall epic.

Initial thoughts on this are that it is completely feasible to decouple just based on understanding a bit about the HCP architecture and the karpenter integration. HyperShift itself already supports decoupling control and data using CAPI Nodepools, so I believe this will just be tube connecting; it will just require an unestimated amount of engineering work.