ref(specs): matches -> routes in HTTPRouteGroup

[michelleN]

This PR changes spec.matches to spec.routes in HTTPRouteGroup.
This change makes the spec a little clearer and easier to
understand. This change will also to more easily talk about
routes in the Traffic Split spec as well.

As part of this refactor, I also removed the matches key from the
TCPRoute spec and the UDPRoute spec as I haven't seen a use for it.
Please let me know if there are any objections.

This PR also updates the directory structure of the draft branch
to make it clearer what file is being used to develop a specific API.

Signed-off-by: Michelle Noorali [email protected]

[trstringer]

It looks like ports was moved from matches to the root of spec. Can you clarify the different use-cases for the change?

[michelleN]

@trstringer The use case for defining TCPRoute has not changed. If you want to allow a source workload to communicate via tcp to a destination workload on certain ports, you would define a TrafficTarget which would reference a TCPRoute that contains a list of ports you'd want to allow. The matches key in the original TCPRoute spec doesn't seem to serve a specific purpose so I took it out. Please let me know if you think it makes sense to keep it in there given this example below.

Example:

kind: TrafficTarget
metadata:
  name: policies-for-destination-workload
  namespace: default
spec:
  destination:
    kind: ServiceAccount
    name: destination-workload
    namespace: default
  rules:
  - kind: TCPRoute
    name: the-routes
  sources:
  - kind: ServiceAccount
    name: source-workload
    namespace: default
---

kind: TCPRoute
metadata:
  name: the-routes
spec:
  ports:
  - 8080
  - 8081

[trstringer]

That makes total sense! Thanks for the explanation, and after reading that I also agree.

[stefanprodan]

LGTM

Thanks @michelleN this makes the API more readable 🏅

[bridgetkromhout]

LGTM!