Allow users to define cluster-scoped BuildTemplates

[imjasonh]

Some cluster operators might want to provide and manage predefined build templates, available across all namespaces.

We should create a ClusterBuildTemplate resource type which is available cluster-wide.

Questions

• If a user creates a BuildTemplate in their namespace with a conflicting name with an existing ClusterBuildTemplate should we allow that or reject it?
• If we allow it, a Build would have to specify template.name: 'some-namespace/the-template' to specify the namespaced template.
• If we disallow it, creating a new ClusterBuildTemplate would have to look for a conflicting name across all namespaces.

I'm not familiar enough with Kubernetes API ClusterFoo idioms to know which is more consistent, hoping for pointers from those with more experience.

[nader-ziada]

/assign @pivotal-nader-ziada

[nader-ziada]

I will work with the following assumptions:

1. We should reject a BuildTemplate with a conflicting name.
2. The create ClusterBuildTemplate also should check existing namespaces and give an error on conflict.

This is more in line with the general pattern of Resources not allowed in both Cluster and Namespace scopes

[cppforlife]

wouldnt that be a racy check?

…

Sent from my iPhone

On Aug 20, 2018, at 9:58 AM, Nader Ziada ***@***.***> wrote: I will work with the following assumptions: We should reject a BuildTemplate with a conflicting name. The create ClusterBuildTemplate also should check existing namespaces and give an error on conflict. This is more in line with the general pattern of Resources not allowed in both Cluster and Namespace scopes — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[nader-ziada]

@cppforlife is there a better way to check? I was thinking it would read the list from the cache.

[cppforlife]

@pivotal-nader-ziada no idea, i was thinking there would be more established way of doing this in kubernetes apis.

i was just looking at how ClusterRole vs Role in kube rbac is referenced (https://kubernetes.io/docs/reference/access-authn-authz/rbac/). looks like they use roleRef that contains kind key which could be ClusterRole or Role. (though they also have apiGroup).

may be adding templateKind: ClusterBuildTemplate | BuildTemplate (default) next to template (which currently specifies name) is better instead of trying to do name check trickery. alternatively can add templateRef that could be used mutually exclusively with template for more advanced cases?

[nader-ziada]

@cppforlife Thanks, I like the idea of adding the templateKind

[evankanderson]

Yes, kubernetes style is to make each resource collection independent. I'd suggest having a kind and/or separate `buildTemplate`/`clusterBuildTemplate` fields (only one of which can be set at a time) rather than trying to prevent a naming collision between cluster-level and namespace level build templates.

…

On Mon, Aug 20, 2018 at 12:11 PM Nader Ziada ***@***.***> wrote: @cppforlife <https://github.com/cppforlife> Thanks, I like the idea of adding the templateKind — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#302 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHlyN42K3z3HO2kXGhyb2qL6JQau9QCuks5uSwnGgaJpZM4WAIvJ> .

-- Evan Anderson <argent@google.com>

[nader-ziada]

Agreed, working on adding a template kind field to the build type instead of checking existing names as per @cppforlife and @evankanderson suggestion