anchor.diff:          tolerations:
           resources:
           priorityClassName:
  -     
  -    ... # Other broker settings - ensure 
  -```
  -
  -When deployed, the above would have the minimum impact of creating 3 routers and 1 brokers. The brokers may be configured according to the address spaces they need to support.
  +status:
  +  phase: Active
  +  conditions:
  +  - type: RoutersCreated
  +    status: True
  +  - type: Ready
  +    status: True
  +```
  +
  +The brokers in a pool may be configured according to the address spaces they need to support.
   
   ==== MessagingPlan
   
  -An `AddressSpacePlan` currently refers to router and broker credits to control the 'quota' of address spaces. With shared infra, the numbers would either have to change their meaning, or one could reithink and extend the schema.
  -
  -For instance, namespace limits can be expressed in more specific terms that map to the routers per vhost policies:
  +The `MessagingPlan` defines limits that map to a particular namespaces' share of the infrastructure:
  +
  +For instance, routers per vhost policies:
   
   * connections
   * links per connection
   
  -In addition, operator limits such as number of addresses can be specified:
  +To broker settings:
  +
  +* transactional capability
  +* queue memory usage
  +
  +To operator limits:
   
   * number of addresses
   
  -Moreover, a split into requests and limits similar to Kubernetes resources is used to allow the operator to calculate the cost of applying plans vs. infrastructure capacity when creating the plan, as well as the cost of applying the plan.
  -
  -The `MessagingPlan` would then look like this:
  -
  -```
  -apiVersion: admin.enmasse.io/v1beta1
  +A split into requests and limits similar to Kubernetes resources is used to allow the operator to calculate the cost of applying plans vs. infrastructure capacity when creating the plan, as well as the cost of applying the plan.
  +
  +The `MessagingPlan` schema may look like the following:
  +
  +```
  +apiVersion: enmasse.io/v1
   kind: MessagingPlan
   metadata:
     name: small
   spec:
  -  messagingInfraRef: shared1 // Plans may refer to the same infra - this means namespaces using this plan will run on the same infra
  +  # Allows specifying a selector for namespaces that should be configured using this plan.
  +  namespaceSelector: 
  +    matchLabels:
  +      type: messaging
     capabilities:
       - transactions
     resources:
  
positive.code:   name: myendpoint
    namespace: myapp
  spec:
    cert:
      selfsigned: {}
      openshift: {}
      provided:
        secret:
          name: mycert # Get cert from secret
    
    # Optional approach to grant admin access to an endpoint using mTLS
    authentication:
      clientCaSecret:
        name: clientsecret
        namespace: myapp
  
    # Only one of 'internal', 'route' and 'loadbalancer' may be specified for each endpoint
    internal: # Expose as a ClusterIP service for applications on cluster
      ports:
  
negative.code: 
  == Design overview
  
  The new API will consist of the following types at the infrastructure level:
  
  * `MessagingInfra`: used to define an instance of shared infrastructure. The `MessagingInfra` will define everything related to router and broker configuration that applies to all tenants. Routers and brokers will be created and owned by this resource in the same namespace as MessagingInfra is defined.
  
  * `MessagingPlan`: Conceptually replaces the `AddressSpacePlan`, but can be optional or enforced. Is not referencing `AddressPlan`s.
  
  * `AddressPlan`: Defines resources requested for an address using this plan. Referencing an AddressPlan may be optional but can be enforced. Resources are specified in terms of queue memory usage and depth, number of paritions, and type-specific settings such as DLQ and expiry queue.
  
  * `AuthenticationService`: Gaining ability to use selectors to configure to which namespaces it should be applied.
  
  
  At the tenant level, the API will change to simplify the user experience:
  
  A restriction of 1 instance of messaging per Kubernetes namespace is mandated. New CRDs for configuring messaging endpoints, connectors and plan/authservice config is defined. The AddressSpace resource is replaced by `MessagingTenant`, `MessagingEndpoint` and `MessagingConnector` resources:
  
  * `MessagingTenant`: a singleton per namespace, is introduced to contain the messaging configuration of a namespace. Auto-created when initial `Address` is created. May be used to override the default `MessagingPlan` and `AuthenticationService` of a tenant.
  
  * `MessagingConnector`: similar to existing connector spec in AddressSpace. 1 instance configures 1 connector.
  
  * `MessagingEndpoint`: allows configuring endpoints to access messaging infrastructure. Cluster-local endpoint is created by default on initial `Address` creation.
  
  * `Address`: similar to existing type. Name is no longer prefixed, `.spec.address` is optional. `.spec.plan` is optional if permitted by plan config. Addition per-type sub-objects such as `.spec.queue` or `.spec.topic` may be specified to override plan properties (if allowed by plan).
  
  * `MessagingRole` and `MessagingRoleBinding`: manage authentication and authorization. Not defined in this proposal and is orthogonal to the use of shared infra.
  
  
  The `MessagingPlan`, `AddressPlan` and `AuthenticationService` resources may additionally be referenced by their namespace. This allows having a service operator persona that does not manage or have access to the messaging infrastructure, but manages the plans and authentication service configurations offered to messaging tenants.
  
  === Service operator
  
  