Add initial resources.md for discussion

The first draft of a Kubernetes resource model.
We differ about the presumption of invalidity.

Another tack: why not try to make sense of what the user provides?  If they
give a limit, but no request, then why not derive the request  from the
limit?  What do we lose?


On Thu, Jul 24, 2014 at 10:39 PM, Tim Hockin <notifications@github.com>
wrote:

> In docs/resources.md:
>
> > +2. _As above, but with numbers restricted to integers._
> > +  * _pro: mapping to integers is more obvious_
> > +  * _con: humans have to rewrite values like 0.3 as 300m._
> > +3. _Eschew suffixes, and require full integers._
> > +  * _pro: simpler parsing code; no floating point values_
> > +  * _con: much harder for users:  is 12000000000 equal to 12e9 or 1.2e9?_
> > +4. _Express fractional values in milli-units, so they can be described as integers.  For example, 0.35 CPU seconds/second would be expressed as `cpu: 350`._
> > +  * _pro: no floating point values; simple comparison semantics._
> > +  * _con: increased likelihood of user error: they have to know which resource types are expressed in milli-units, and which not._
> > +
> > +_We currently propose option 1, but welcome discussion on this point.]_
> > +
> > +### Resource quantities
> > +There are several kinds of resource quantities that can be expressed within the context of a _resource specification_:
> > +
> > +* _request_: the amount of the resource being requested. Scheduler algorithms will use this to test feasibility (whether a pod will fit onto a node).  If omitted, _request_ defaults to a value determined by the implementation unless _limit_ is explicitly specified, in which case _request_ is set to _limit_. If a pod uses more resources than its _request_, any associated SLOs are voided - e.g., the pod may be throttled (compressible resource types), or the attempted use may be denied.
>
> Why do we want to allow the user to set limit and not request? I think the
> spec gets simpler if we just say that fields are cumulative in their effect.
>
> absent request, absent limit => choose sane defaults for me
> present request, absent limit => limit = request
> absent request, present limit = error
>
> It's not a huge deal, I just don't see why we should go out of the way to
> handle obviously invalid input.
>
> --
> Reply to this email directly or view it on GitHub
> <https://github.com/GoogleCloudPlatform/kubernetes/pull/617/files#r15386977>
> .
>