Proposal: Initial namespaces proposal

This is based on feedback and discussion that came out of #1017 

There was discussion that the term project may be problematic, so have removed it in favor of namespace.

I think this aligns nicely with the ACL model discussed thus far.

Feedback appreciated.

@erictune @lavalamp @smarterclayton 




> On Sep 5, 2014, at 2:49 PM, Daniel Smith <notifications@github.com> wrote:
> 
> In docs/namespaces.md:
> 
> > +| LIST | GET | /api/{version}/list/{resourceType} | List instances of {resourceType} across namespaces |
> > +
> > +The k8s API server verifies the *Namespace* on resource creation matches the *{ns}* on the path.
> > +
> > +The k8s API server will enable efficient mechanisms to filter model resources based on the *Namespace*.  This may require
> > +the creation of an index on *Namespace* that could support query by namespace with optional label selectors.
> > +
> > +## k8s storage
> > +
> > +A namespace provides a unique identifier space and therefore must be in the storage path of a resource.
> > +
> > +In etcd, we want to continue to still support efficient WATCH across namespaces.
> > +
> > +Resources that persist content in etcd will have storage paths as follows:
> > +
> > +/registry/{resourceType}/{resource.Namespace}/{resource.ID} 
> Why include the namespace at all in etcd then? Just use the globally unique uuid as a key? Set up an index for namespaces with @erictune's proposed indexing thingy?
> 
My argument is that for high scale systems you want your primary key to be the uniqueness constraint you want to impose.  Otherwise you have to enforce uniqueness transactionally or lazily.  Since enforcing uniqueness is a primary requirement but retrieval by UUID is secondary, why not align guaranteeing uniqueness of name inside the namespace with the natural structure of the data store?
> —
> Reply to this email directly or view it on GitHub.