As CPMSO rolls out a new control-plane node, the etcd member on the newly created master node joins the etcd-cluster initially as a learning not voting member. 

Until the new member catches up with the rest of the etcd-cluster members's WAL ( i.e. becomes voting member), it does not make sense to schedule a corresponding backup pod on this node. 

The approach is being investigated here :- 

• Add labels to all control-plane nodes upon enabling AutomatedBackup feature gate
• These label are being applied by CEO according to the state of each etcd member, whether it is voting or learning 
• This label will be exploited by Backup DaemonSet, to avoid scheduling an etcd-backup-server on any control-plane node, whose etcd member is not voting member

Background discussion https://github.com/openshift/enhancements/pull/1646/files#r1884247846 

cc joelspeed deads@redhat.com tjungblu@redhat.com racedoro@redhat.com