<p dir="auto">The majority of unique code per resource type in our <code class="notranslate">RESTStorage</code> implementations deals with populating default values on an object and validating the object prior to persistence.  The other 99% of the code is pretty common across all of our resource types and could be generalized.  When we look at our tests, the majority of our <code class="notranslate">rest_test.go</code> files are just ensuring that validation occurs prior to create/update.  There is a lot of duplicate effort where we could just mandate that the framework that calls the <code class="notranslate">RESTStorage</code> guarantees that the object is valid.</p>
<p dir="auto">I would like to suggest that the <code class="notranslate">resthandler.go</code> logic enforces that prior to calling a <code class="notranslate">RESTStorage</code> Create and Update operation, it makes a call to something like the following:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="type Validator interface {
  // ValidateCreate will populate default values on the object, and ensure its valid for persistence
  ValidateCreate(ctx api.Context, obj runtime.Object) error
  // ValidateUpdate will validate the newObj and copy values required from oldObject prior to persistence
ValidateUpdate(ctx api.Context, newObj runtime.Object, oldObj runtime.Object) error
}"><pre class="notranslate"><code class="notranslate">type Validator interface {
  // ValidateCreate will populate default values on the object, and ensure its valid for persistence
  ValidateCreate(ctx api.Context, obj runtime.Object) error
  // ValidateUpdate will validate the newObj and copy values required from oldObject prior to persistence
ValidateUpdate(ctx api.Context, newObj runtime.Object, oldObj runtime.Object) error
}
</code></pre></div>
<p dir="auto">In addition, as we look to the future, there are some additional concepts that I would like the <code class="notranslate">resthandler.go</code> to enforce uniformly across all resources without adding more boilerplate into each <code class="notranslate">RESTStorage</code> implementation.  Specifically, I do not want to invoke any Admission control style logic for invalid input, but I do not want to modify each <code class="notranslate">RESTStorage</code> implementation to have to make an explicit call-out to perform admission control as it just increases more boiler plate code.</p>
<p dir="auto">We're using Kubernetes 1.2.1 on AWS.</p>
<p dir="auto">We've been experiencing duplicate UDP packets. It happens only on a very specific setup:</p>
<ol dir="auto">
<li>A pod (pod1) that exposes some UDP port</li>
<li>A service that directs traffic to that pod</li>
<li>Another pod (pod2) to send UDP packets (we used netcat for this)</li>
<li>The pods must be running on the <strong>same</strong> node</li>
</ol>
<p dir="auto">When pod2 sends a UDP message to pod1 via the <strong>service</strong> pod1 shows it received the message twice.<br>
When we go from pod2 directly to the ip of pod1 the message is received once without duplications..<br>
Also, when sending UDP messages from a pod that is running on another machine we don't get the duplication both to the service and pod ip.</p>
<p dir="auto">We created a repository do make the problem re-produceable here: <a href="https://github.com/nanit/udp-server">https://github.com/nanit/udp-server</a>. It contains:</p>
<ol dir="auto">
<li>A kube directory with both the deployment and service definitions.</li>
<li>An app directory with the Dockerfile we used to run the udp listener (using tcpdump).</li>
</ol>
<p dir="auto">We used netcat in order to send UDP packets to the listener:<br>
<code class="notranslate">echo "some message" | nc -u udp-listen 8088</code></p>
<p dir="auto">When we replaced udp-listen (the service name)  with the explicit ip of the pod we didn't get the duplication.<br>
Also, when sending UDP messages from a pod running on another node we didn't get the duplications.</p>
<p dir="auto">I'll be happy to provide any further info if needed.</p>