Merge pull request #30 from nicholasjackson/rename_httproutes

Rename HTTPRoutes HTTPRoute

traffic-access-control.md

@@ -22,15 +22,15 @@ as an expression with `matchExpressions`.
 
 Rules are [traffic specs](traffic-specs.md) that define what traffic for
 specific protocols would look like. The kind can be different depending on what
-traffic a target is serving. In the following examples, `HTTPRoutes` is used for
+traffic a target is serving. In the following examples, `HTTPRouteGroup` is used for
 applications serving HTTP based traffic.
 
 To understand how this all fits together, first define the routes for some
 traffic.
 
 ```yaml
 apiVersion: v1beta1
-kind: HTTPRoutes
+kind: HTTPRouteGroup
 metadata:
   name: the-routes
 matches:
@@ -58,8 +58,9 @@ selector:
     app: foo
 port: 8080
 rules:
-- kind: HTTPRoutes
+- kind: HTTPRouteGroup
   name: the-routes
+  namespace: default
   matches:
   - metrics
 ```
@@ -78,7 +79,7 @@ connection as well.
 
 A `IdentityBinding` grants access for a specific identity to the rules in a
 TrafficTarget. It holds a list of subjects (service accounts for now) and a
-reference to the traffic target defining what has been granted.
+reference to the traffic target defining what has been granted. 
 
 ```yaml
 kind: IdentityBinding
@@ -93,6 +94,7 @@ subjects:
 targetRef:
   kind: TrafficTarget
   name: path-specific
+  namespace: default
 ```
 
 This example grants the ability to access the `/metrics` route to any client
@@ -113,9 +115,10 @@ metadata:
 subjects:
 - kind: Group
   name: system:unauthenticated
-roleRef:
+targetRef:
   kind: TrafficTarget
   name: path-specific
+  namespace: default
 ```
 
 This example allows any unauthenticated client access to the rules defined in
@@ -154,7 +157,7 @@ protected label.
 
 A `ClusterIdentityBinding` grants access for a specific identity, originating in
 a specific namespace, to a ClusterTrafficTarget associated with pods in any
-namespace.
+namespace. 
 
 ```yaml
 kind: ClusterIdentityBinding
@@ -169,6 +172,7 @@ subjects:
 targetRef:
   kind: ClusterTrafficTarget
   name: metrics-scrape
+  namespace: default
 ```
 
 Continuing with the Prometheus example from above, it is possible to have a

traffic-specs.md

@@ -12,14 +12,14 @@ to define the traffic in a protocol specific fashion.
 
 ## Specification
 
-### HTTPRoutes
+### HTTPRouteGroup
 
 This resource is used to describe HTTP/1 and HTTP/2 traffic. It enumerates the
 routes that can be served by an application.
 
 ```yaml
 apiVersion: specs.smi-spec.io/v1alpha1
-kind: HTTPRoutes
+kind: HTTPRouteGroup
 metadata:
   name: the-routes
 matches:
@@ -51,7 +51,7 @@ an HTTP request. This is where `filters` come in:
 
 ```yaml
 apiVersion: v1beta1
-kind: HTTPRoutes
+kind: HTTPRouteGroup
 metadata:
   name: the-routes
   namespace: default
@@ -94,7 +94,7 @@ automatically generate the list of routes from code.
 ## Out of scope
 
 * gRPC - there should be a gRPC specific traffic spec. As part of the first
-  version, this has been left out as HTTPRoutes can be used in the interim.
+  version, this has been left out as HTTPRouteGroup can be used in the interim.
 
 * Arbitrary header filtering - there should be a way to filter based on headers.
   This has been left out for now, but the specification should be expanded to