Project is Namespace

[derekwaynecarr]

The PR introduces the following changes:

1. A project is now a virtual resource mapped to a Kubernetes Namespace.
2. A project display name is stored as an annotation to the Namespace.

Existence of a Project/Namespace prior to it's usage will be done in a separate PR.

There are some tweaks needed to upstream fake_namespaces.go in order to make better tests, but this still provides sufficient test coverage.

Enforcing creation of the Project prior to sticking content in its namespace will be done in a subsequent PR once the Admission Control stuff in Origin is settled.

/cc @smarterclayton @deads2k @jwforres

[derekwaynecarr]

I also updated the cli to not show a Namespace column when rendering a Project, since a Project has no Namespace anymore.

[smarterclayton]

To "not"?

----- Original Message -----

I also updated the cli to now show a Namespace column when rendering a
Project, since a Project has no Namespace anymore.

---

Reply to this email directly or view it on GitHub:
#1038 (comment)

[derekwaynecarr]

To not, sorry.

----- Original Message -----
From: "Clayton Coleman" notifications@github.com
To: "openshift/origin" origin@noreply.github.com
Cc: "Derek Carr" decarr@redhat.com
Sent: Monday, February 16, 2015 4:23:13 PM
Subject: Re: [origin] Project is Namespace (#1038)

To "not"?

----- Original Message -----

I also updated the cli to now show a Namespace column when rendering a
Project, since a Project has no Namespace anymore.

---

Reply to this email directly or view it on GitHub:
#1038 (comment)

---

Reply to this email directly or view it on GitHub:
#1038 (comment)

[derekwaynecarr]

Sent note to mailing list notifying users of planned change.

[jwforres]

So the returned JSON for the virtual project resource will have displayName on an annotation instead of directly on the object correct? If so the UI code needs updating as well.

[derekwaynecarr]

The display name appears in Project.DisplayName like it did previously. It also appears in Project.Annotations["displayName"] in this PR as well.

[jwforres]

Are we deprecating it from being directly on displayName?

[derekwaynecarr]

No

[smarterclayton]

Don't use camel case, I'm not sure I can win that argument with brian.

----- Original Message -----

The display name appears in Project.DisplayName like it did previously. It
also appears in Project.Annotations["displayName"] in this PR as well.

---

Reply to this email directly or view it on GitHub:
#1038 (comment)

[derekwaynecarr]

@smarterclayton - I forgot that battle was still ongoing, will update this PR.

[jwforres]

Remove the change to bindata.go, shouldn't be necessary

[derekwaynecarr]

@jwforres - I removed the change to bindata.go, we need to figure out why its reporting as needed on my local machine longer term or standardize its build in a container.

@smarterclayton - moved to use "displayname" as annotation.

any other objections/concerns?

[derekwaynecarr]

Random travis flake in integration tests in unrelated area.

[smarterclayton]

Another reason this has to be this way is that we have to run on kube directly - we should make a note somewhere that it's illegal to reference a kube registry from an openshift storage object.

[smarterclayton]

Can you add an integration test for this?

[derekwaynecarr]

@smarterclayton - yes, will work on putting one together now.

[derekwaynecarr]

@smarterclayton - added integration test to commit.

[smarterclayton]

LGTM [merge]

[openshift-bot]

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_openshift3/947/) (Image: devenv-fedora_819)

[openshift-bot]

Evaluated for origin up to ae85eae