Rename our resources to have ServiceCatalog prefix #1054
Conversation
k8s-ci-robot
added
the
cncf-cla: yes
| @@ -148,26 +149,27 @@ func TestInstallTypesErrors(t *testing.T) { | |||
| //make sure we don't poll on resource that was failed on install | |||
| func TestInstallTypesPolling(t *testing.T) { | |||
There was a problem hiding this comment.
@arschles I don't understand this test. I don't see how it ever worked, but apparently it must. The part that confuses me is the use of getCallCount and comparing it to len(thirdPartyResources). That just seems really odd since we're going to Get() each resource at least once during the install (once before we install and then at least once after) and we never reset the getCallCount so it seems like it should always generate an error 1/2 way thru the installation of the resources.
|
@smarterclayton will this pass API review? |
|
@MHBauer I've been trying but to be honest I don't know how. "make purge-generated" doesn't do it like I would expect. |
duglin
force-pushed
the
rename
branch
4 times, most recently
from
14c2135
to
7123d6b
Compare
duglin
force-pushed
the
rename
branch
5 times, most recently
from
a2ea3f7
to
da12fa0
Compare
|
@kibbles-n-bytes I can't seem to see where the error in the travis output is - do you see it? |
duglin
changed the title
duglin
force-pushed
the
rename
branch
7 times, most recently
from
41e42a5
to
2ccbaa9
Compare
|
ok this one is ready for review. I'd appreciate a quick one because the potential for conflicts/rebasing is pretty darn high. |
|
rebased now that we're on kube 1.7 api machinery - wasn't nearly as bad as I expected. |
Signed-off-by: Doug Davis <dug@us.ibm.com>
Signed-off-by: Doug Davis <dug@us.ibm.com>
|
I don't see a problem with the prefix. For some of them, I think it could be shortened to just Service and that would be acceptable. For instance, I don't know that anyone in the Kubernetes community could argue that the idea of a "ServiceClass" (like PriorityClass, StorageClass, etc) "belongs" to the service catalog work. And likewise, the idea of Binding a service class to a user also belongs this this work. While I could maybe imagine a ServiceInstance existing in another API group, I think it's more likely to see things like "ProxyService" or "MirroredService". So I think if this SIG wanted to, it could legitimately claim ownership of ServiceInstance, ServiceClass, and ServiceBinding. To a user, that may also be clearer and less to type. The chance of conflict seems low enough that you can make that leap. |
|
We're going to want a release shortly after this so that people don't pull an image that doesn't work as it doesn't match the code. |
|
I also think |
|
Oops, total fail re: Label |
|
Looking forward to finalizing the names of these resources |
…s-retired#1054)" This reverts commit 4e47ec1.
Please check to see if I went too far on the resources I changed.
I tried to limit it to just the ones that might be visible as top-level resources.