anchor.diff:  kind: VirtualService
   metadata:
     name: reviews
  +spec:
  +  hosts:
  +  - reviews
  +  http:
  +  - match:
  +    - headers:
  +      end-user:
  +        exact: jason
  +    route:
  +    - destination:
  +        host: reviews
  +        subset: v2
  +  - route:
  +    - destination:
  +        host: reviews
  +        subset: v3
  +EOF
  +----
  +
  +[id="ossm-routing-config-v-host_{context}"]
  +== Configuring your virtual host
  +
  +The following sections explain each field in the YAML file and explain how you can create a virtual host in a virtual service.
  +
  +[id="ossm-routing-hosts_{context}"]
  +=== Hosts
  +
  +The `hosts` field lists the virtual service’s user-addressable destination that these routing rules apply to. This is the address or addresses the client uses when sending requests to the service.
  +
  +The virtual service hostname can be an IP address, a DNS name, or, depending on the platform, a short name that resolves to a fully qualified domain name.
  +
  +[source,yaml]
  +----
  +spec:
  +  hosts:
  +  - reviews
  +----
  +
  +[id="ossm-routing-routing-rules_{context}"]
  +=== Routing rules
  +
  +The `http` section contains the virtual service’s routing rules, describing match conditions and actions for routing HTTP/1.1, HTTP2, and gRPC traffic sent to the destination specified in the hosts field. A routing rule consists of the destination where you want the traffic to go and zero or more match conditions, depending on your use case.
  +
  +.Match condition
  +
  +The first routing rule in the example has a condition and begins with the match field. In this example, this routing applies to all requests from the user `jason`. Add the `headers`, `end-user`, and `exact` fields to select the appropriate requests.
  +
  +[source,yaml]
  +----
  +spec:
  +  hosts:
  +  - reviews
  +  http:
  +  - match:
  +    - headers:
  +      end-user:
  +        exact: jason
  +----
  +
  +.Destination
  +
  +The `destination` field in the route section specifies the actual destination for traffic that matches this condition. Unlike the virtual service’s host, the destination’s host must be a real destination that exists in the {ProductName} service registry. This can be a mesh service with proxies or a non-mesh service added using a service entry. In this example, the host name is a Kubernetes service name:
  +
  +[source,yaml]
  +----
   spec:
     hosts:
     - reviews
  
positive.code: [id="ossm-routing_{context}"]
  = Routing and managing traffic
  
  Configure your service mesh by adding your own traffic configuration to {ProductName} with a custom resource definitions in a YAML file. 
  
  [id="ossm-routing-traffic-management-vs_{context}"]
  == Traffic management with virtual services
  
  You can route requests dynamically to multiple versions of a microservice through {ProductName} with a virtual service. With virtual services, you can:
  
  * Address multiple application services through a single virtual service. If your mesh uses Kubernetes, for example, you can configure a virtual service to handle all services in a specific namespace. Mapping a single virtual service to many services is particularly useful in facilitating turning a monolithic application into a composite service built out of distinct microservices without requiring the consumers of the service to adapt to the transition. 
  * Configure traffic rules in combination with gateways to control ingress and egress traffic.
  
  [id="ossm-routing-vs_{context}"]
  
negative.code:     - destination:
        host: reviews
        subset: v2
  ----
  
  [id="ossm-routing-dr_{context}"]
  === Destination rules
  
  Destination rules are applied after virtual service routing rules are evaluated, so they apply to the traffic’s real destination. Virtual services route traffic to a destination. Destination rules configure what happens to traffic at that destination.
  
  [id="ossm-routing-lb_{context}"]
  ==== Load balancing options
  
  By default, {ProductName} uses a round-robin load balancing policy, where each service instance in the instance pool gets a request in turn. {ProductName} also supports the following models, which you can specify in destination rules for requests to a particular service or service subset.
  
  