<p dir="auto">There are pitfalls when using the watch + list pattern. Many of our controllers use this pattern, and we expect many future pieces of code to use this pattern. Therefore, we'd like to provide a framework/example which lets you fill out three functions (list, watch, and process) to get a shiny new bug-free (at least the list+watch part) controller.</p>
<p dir="auto">This can be modeled after/mostly copied from the scheduler.</p>
<p dir="auto">Filing this so we can revisit.<br>
<a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/satnam6502/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/satnam6502">@satnam6502</a></p>
<p dir="auto">Service names (and apparently Namespace names in the client, but not the server) are restricted to DNS 952 labels (24 characters).  Most other API Objects have names that are DNS 1123 subdomains (much longer).</p>
<p dir="auto">In doing tests it is useful to generate random names, and this is a bit annoying for services.</p>
<p dir="auto">Can we expand service names?</p>
<ol dir="auto">
<li>DNS 1035 labels (longer)</li>
<li>DNS 1035 subdomains (longer and allow dots)</li>
<li>DNS 1123 labels (longer, allow leading digit)</li>
<li>DNS 1123 subdomains (longer, allow leading digit and dots)</li>
</ol>
<p dir="auto">(4) would be most consistent with other objects.</p>
<p dir="auto">If we do (2) or (4) we need to convert dots to underscores in env-var names, which could cause a collision (e.g. foo-bar and foo.bar).  Maybe double underscore for dots?</p>
<p dir="auto">If we do (3) or (4) we need to handle leading digits in env-vars.  Maybe a prefixed underscore?</p>
<p dir="auto">(1) seems least controversial, but is still different than everything else.</p>