<p dir="auto">TL;DR : I think this can be done in the <strong>density tests</strong>, we just need to vary them so that there are <strong>collisions</strong> (dupe pods) being submitted.</p>
<p dir="auto">... In a real kube system, there is a likliehood that 10 or 20 RC's might be created simultaneously.</p>
<p dir="auto">We should ensure that the if we submit, say 100 concurrent pod creation requests,</p>
<ul dir="auto">
<li>(consistency) The systems state is consistent such that <em>duplicate</em> pods aren't created, and at least some requests are <em>rejected</em>.</li>
<li>(availability) every unique submission is eventually created.</li>
</ul>
<p dir="auto"><em>Problem</em></p>
<p dir="auto">There is alot of jargon in the scheduler code, some examples:</p>
<ul dir="auto">
<li><code class="notranslate">hardPodAffinityWeight</code> == RequiredDuringSchedulingScheduling</li>
<li><code class="notranslate">softPod...</code> ==  "PreferredDuringScheduling pod affinity."</li>
<li>Symmetry, a major part of the affinity algorithm implementation, is also undocumented in docs/devel/scheduler.</li>
</ul>
<p dir="auto">Reading podaffinity along side the scheduler docs + the code gives a good picture.</p>
<p dir="auto"><em>Solution</em></p>
<p dir="auto">Since the affinity, symmetry, hard/soft pod stuff is now in the production code, lets migrate out of the proposal (or maybe duplicate if proposals are meant to live forever), and Lets converge podaffinity proposal into the first class docs/devel/scheduler* area.</p>
<p dir="auto">cc @kubernetes/sig-scheduling</p>