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 


@smarterclayton that is correct 

> On Sep 4, 2014, at 9:56 PM, Clayton Coleman <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} 
> I think this is trying to make it possible to do a recursive watch on /pods for the scheduler as efficiently as possible in etcd. Namespaces segment for typical access but the scheduler should be able to (assuming the policy allows it) watch globally)
> 
> —
> Reply to this email directly or view it on GitHub.