The clustermember controller will repeatedly attempt to promote a learner member and ignore the error for the expected case when the learner is not yet in sync with the leader's log.
https://github.com/openshift/cluster-etcd-operator/blob/c9977ae3bd788a9e9a595001c5bc24995f9d0175/pkg/operator/clustermembercontroller/clustermembercontroller.go#L275-L288

Learner members only support endpoint status (`etcdctl endpoint status`) and serializable read (`etcdctl get --consistency="s" ...`) calls and reject all other calls including the promotion attempts.

The etcd client for the clustermember controller does not exclude learner members from its endpoints so the calls to promote a member could be sent to the learner itself which can result in "etcdserver: rpc not supported for learner" errors.

This happens most commonly early on during bootstrap when there are 2 members (1 voting and 1 learner) present and the promotion calls end up being sent to the learner member.

Seen here in CI:
https://search.ci.openshift.org/?search=etcdserver%3A+rpc+not+supported+for+learner&maxAge=48h&context=1&type=bug%2Bjunit&name=&excludeName=&maxMatches=5&maxBytes=20971520&groupBy=job

https://prow.ci.openshift.org/view/gs/origin-ci-test/logs/periodic-ci-openshift-windows-machine-config-operator-release-4.11-vsphere-e2e-periodic/1524177785738760192


While the promotion calls are retried and eventually succeed, they should never be sent to learner members in the first place.

The apparent fix here seems to be to exclude all learner member endpoints from the cached etcd client used by the clustermember controller.