Rename HTTPRoutes HTTPRoute

[nicholasjackson]

When creating a CRD for the HTTPRoutes this causes a pluralization problem for example...

---
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:  
  name: httproutess.smi-spec.io
spec:  
  group: smi-spec.io
  version: v1alpha1
  scope: Namespaced 
  names:    
    kind: HTTPRoute
    shortNames: 
      - htr
    plural: httproutess
    singular: httproutes

as opposed to

---
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:  
  name: httproutes.smi-spec.io
spec:  
  group: smi-spec.io
  version: v1alpha1
  scope: Namespaced 
  names:    
    kind: HTTPRoute
    shortNames: 
      - htr
    plural: httproutes
    singular: httproute

[grampelberg]

Well that's a bummer. Is there a better word we can use? It is a container of multiple routes, so HTTPRoute isn't quite right. (I can be convinced that I'm bikeshedding right now).

Also, I'd assumed the group would be spec.smi-spec.io so that we can version the individual groups separately moving forward.

ps htr is the best short name ever.

[nicholasjackson]

I agree it is not great, I was struggling myself, how about HTTPRouteList?

You are right on the namespace, I was just trying to get the codegening to work with our CRD build, will update that tomorrow once we get a few things figured out.

[slack]

Hah, Nic, we are on the same page. Was staring at this issue and had:
HTTPRouteList, HTTPRouteMatcher, HTTPRouteGroup

[grampelberg]

I'm a big +1 to HTTPRouteGroup. @slack is your super power naming things? HTTPRouteList WFM as well.

[msftclas]

All CLA requirements met.

[nicholasjackson]

Ok how is this?

[grampelberg]

I like it, just one little comment/question, otherwise, merge away!

[grampelberg]

Both target and binding aren't namespaced (in my head at least).

[nicholasjackson]

Aha good catch, so the reason I added that is when we are building the CRD and are actually writing the code to read the TrafficTarget, the KubeAPI client requires the object namespace as a parameter.

Originally I added namespace to the TargetRef so that you could do the lookup, then reverted that as IdentityBindings would always be in the same location as TrafficTargets. However, that assumption does not apply for ClusterIdentityBinding.

I think we need to add namespace to the ref then?

---
kind: IdentityBinding
apiVersion: smi-spec.io/v1alpha1
metadata:
  name: account-specific
  namespace: default
subjects:
- kind: ServiceAccount
  name: service-b
  namespace: default
targetRef:
  kind: TrafficTarget
  name: foo 
  namespace: default

[grampelberg]

It looks like RoleBinding and ClusterRoleBinding don't need the namespace. I suspect that is because you can only targetRef the cluster or non-cluster resource. I think that targetRef is a custom object there though (and not a ObjectReference). You're in the code so I'll defer to you though.

[nicholasjackson]

I think we need namespace on everything, it will just make things easier when coding the CRDs no assumptions. I have added this in the latest commit. We can always change things later to make things easier.