As reported by jpacker@redhat.com:

If I create a ClusterPool with spec.size: 0 and then create ClusterClaim in that namespace, the following happens:

• A ClusterDeployment is created. It shouldn't be.
• The ClusterDeployment is deleted right after it finishes installing, leaving the ClusterClaim orphaned.

The ClusterDeployment gets created by the clusterpool_controller because:

• We get no claimed or unclaimed CDs here.
• Assuming spec.maxSize is unset or nonzero, availableCapacity is set to a positive number here.
• We get one pending claim here.
• Due to the above, reserveSize is set to -1 here.
• Assuming spec.maxConcurrent is unset or nonzero, availableCurrent is set to a positive number here.
• drift is set to -1 here.
• In this case statement, we don't break because availableCapacity is positive; and toAdd is set to 1 because drift is -1 and both availableCapacity and availableCurrent are positive. So we call addClusters with 1.

Done: Claiming from a zero-size pool doesn't create a ClusterDeployment.

(TODO: Okay, but what should it do? Should the claim fail somehow? Or should it just hang out in Pending state until the pool size is changed? I.e. is this different from the pool being at the limit of MaxSize? Arguably yes, because you can get capacity back in that case by deleting claims; whereas with size: 0 you can't get capacity without editing the pool. But then, what happens if things are swimming along and you edit the pool down to size zero? Any pending claims should fail? or wait? Feedback welcome.)

See this slack thread for (much!) more information.