<p dir="auto">API server with etcd v2 supports creating a large object (n*100 KB) , but not updating it. The cause is:</p>
<p dir="auto">k8s storage layer <a href="https://github.com/kubernetes/kubernetes/blob/master/pkg/storage/etcd/etcd_helper.go#L528-L529">sets</a> both PrevValue (the original value of the object as we know) and PrevIndex in the update request sent to etcd v2. They are set as query <a href="https://github.com/coreos/etcd/blob/master/client/keys.go#L559">paratemeters</a>. etcd v2.2.1 server drops the connection if the parameter size is larger than 1052KB. Hence, the update request fails if the object is large. However, because a creation request doesn't set the query parameters, it will succeed.</p>
<p dir="auto">The problem does not exist in the etcd v3 storage, because it only compare the previous revision, not the value. <a href="https://github.com/kubernetes/kubernetes/blob/master/pkg/storage/etcd3/store.go#L270-L272">code</a>.</p>
<p dir="auto">Action items:</p>
<ul dir="auto">
<li>
<p dir="auto">To fix the issue with v2 etcd, we can set only the PrevIndex, but not the PrevValue <a href="https://github.com/kubernetes/kubernetes/blob/master/pkg/storage/etcd/etcd_helper.go#L528-L529">here</a>. I think PrevIndex is enough to prevent race.</p>
</li>
<li>
<p dir="auto">API server should gate the size of the objects. If the backend is etcd, the threshold should be &lt; 1MB, according to this <a href="https://github.com/coreos/etcd/issues/2992#issuecomment-112477807" data-hovercard-type="issue" data-hovercard-url="/etcd-io/etcd/issues/2992/hovercard">comment</a>. Not sure what's the threshold for etcd3.</p>
</li>
</ul>
<p dir="auto">@kubernetes/sig-api-machinery <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/lavalamp/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/lavalamp">@lavalamp</a> <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/hongchaodeng/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/hongchaodeng">@hongchaodeng</a> <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/xiang90/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/xiang90">@xiang90</a></p>
<p dir="auto">Today in <a class="team-mention js-team-mention notranslate" data-error-text="Failed to load team members" data-id="1910056" data-permission-text="Team members are private" data-url="/orgs/kubernetes/teams/sig-testing/members" data-hovercard-type="team" data-hovercard-url="/orgs/kubernetes/teams/sig-testing/hovercard" href="https://github.com/orgs/kubernetes/teams/sig-testing">@kubernetes/sig-testing</a> we discussed the idea of improving the examples over time with a new policy, based on.</p>
<ul dir="auto">
<li>a few, domain driven examples that are artfully curated by developers, i.e., less than 4.</li>
<li>covering all features in the examples : rather than duplicating the core features using non idiomatic kube techniques.</li>
<li>converting the existing examples which don't actually "tell a story" into a <code class="notranslate">blueprints/</code> directory which might be put into contrib.
<ul dir="auto">
<li>That way, if the mongodb community wants to curate their recipes upstream, they can easily do so, without us having to support then in the e2es.</li>
</ul>
</li>
</ul>
<p dir="auto">I think this should be done slowly.  For now, I think its great for us to keep maintaining the examples/, as many people continue to use them.  We can work with the @kubernetes/sig-big-data @kubernetes/sig-api-machinery  and @kubernetes/sig-auth and other sigs to make sure the pedagogical elements are all addressed.</p>