anchor.diff:        linksPerConnection: 2
   ```
   
  -This would be easier to understand and reason about than fractions. It is also easier to relate the impact of those limits to the shared infra, and allow the limits to be enforced. It would allow a shared infra to support messaging plans with different limits in place. 
  +This is easier to understand and reason about than fractions used in `AddressSpacePlan`s. It is also easier to relate the impact of those limits to the shared infra, and allow the limits to be enforced. It would allow a shared infra to support messaging plans with different limits in place. 
   
   For routers and brokers, the shared infra has some potential for auto-scaling. It would be the responsibility of the enmasse-operator to scale the infrastructure within the bounds set by the `MessagingInfra`, which could be based on cpu and memory usage, or the limits defined in the messaging plans.
   
   For plans with the `transactions` capability, the operator will ensure that addresses for that namespace are always link-routed and put on the same broker (and HA replicas).
   
  -==== MessagingConfig
  -
  -The messaging tenant will create a singleton instance of `MessagingConfig` in a namespace to configure messaging. Creating the MessagingConfig may be optional: the operator can create it with defaults if endpoints are created for instance.
  -
  -```
  -kind: MessagingConfig
  +NOTE: If no `MessagingPlan` instances are defined, the system will still work. However, there will be no limits configured for particular vhosts.
  +
  +==== MessagingTenant
  +
  +The messaging tenant will create a singleton instance of `MessagingTenant` in a namespace to
  +configure messaging. The MessagingTenant is created by the EnMasse operator when the initial Address
  +is created. If the MessagingTenant already exists, the infra, plan and authentication services that
  +are specified will be used _only if_ those have selectors for that namespace.
  +
  +```
  +kind: MessagingTenant
   metadata:
     name: default # Singletons can be enforced using openapi validation!
   spec:
  +  infra:
  +    name: shared
  +    namespace: custom
     plan:
       name: myplan
  -    namespace: custom # Default is enmasse-infra
  +    namespace: custom
     authenticationService:
       name: myservice
  -    namespace: custom # Default is enmasse-infra
  -status:
  -  message: "Unknown authenticationservice 'myservice'
  +    namespace: custom
   ```
   
   ==== MessagingEndpoint
   
  -A MessagingEndpoint configures access to the messaging infrastructure via different mechanisms. It is also the place where tenants put any custom certificates that should be used, or configure how an endpoint should be exposed. An endpoint can either be exposed internally (as a ClusterIP service), as a loadbalancer service (LoadBalancer service) or as an OpenShift route. Multiple endpoints may be created to expose service in multiple ways. All addresses in a namespace are exposed through all endpoints.
  +A MessagingEndpoint configures access to the messaging infrastructure via different mechanisms. It
  +is also the place where tenants can explicitly configure certificates to be used, or configure how an endpoint should be exposed.
  +
  +An endpoint can either be exposed internally (as a ClusterIP service), as a loadbalancer service
  +(LoadBalancer service) or as an OpenShift route. Multiple endpoints may be created per namespace.
  +
  +All addresses in a namespace are exposed through all endpoints.
   
   ```
   kind: MessagingEndpoint
  
positive.code: 
  * Minimize management traffic with router and broker
  * Add safeguards for getting out of bad states (with proper error reporting to be able to investigate bugs later)
  * Shared infras should be able to operate independently
  
  ===== Configuration
  
  The configuration can be broken down into different lifecycle 'levels':
  
  * Infra - configuration that is applied at all routers and brokers (based on the MessagingInfra config)
  * Namespace - configuration that is applied for each namespace (based on MessagingConfig, MessagingPlan, MessagingEndpoint and MessagingConnector)
  * Address - configuration that is applied for each address (based on Address and AddressPlan)
  
  For the routers, each level will involve the following configuration:
  
  * Infra: Connectors to broker. Global router settings such as threads, internal certs. Pod template settings. Changes modify the router CR and require a rolling router restart (until DISPATCH-1519 is implemented)
  * Namespace: Vhost policies, endpoints, external connectors. Changes are applied using AMQP management to avoid router restart.
  * Address: Address waypoints, autolinks, linkroutes. Changes are applied using AMQP management to avoid router restart
  
  For the brokers:
  
  * Infra: Global broker settings such as JVM size, global max size, storage size, global policies. Changes modify a Broker CR and requires a broker restart.
  * Address level: queues and topics, per address limits. Configured using AMQP management to avoid broker restart.
  
  The operator will maintain open connections to all routers and brokers. The connection will be periodically closed to enforce a resync so that configuration does not drift.
  
negative.code: 
  A components state encapsulates the configuration state of a broker or router in memory. Whenever a router or broker is connected, a corresponding router/broker state object is initialized with configuration retrieved from querying the router/broker. If disconnected, the state object is initialized with current state, and desired state is applied.
  
  The state object has methods to apply configuration (i.e. applyAddress, applyMessagingEndpoint, applyMessagingTenant etc.). These methods compare the actual configuration of the underlying component to the desired configuration (transformed into autolinks etc.). If the applied configuration is different to the internal state, the underlying component is updated using AMQP management.
  
  In addition, each state object has a goroutine which periodically polls its underlying router/broker for all status information and caches it for use by controllers to update the status of their respective resources.
  
  ===== Certificate management
  
  Communication between components in the shared infrastructure should be secured using TLS. The messaging-infra-controller needs to create a CA per messaging-infra instance, as well as handle certificate rotation for the internal certificates on expiry.
  
  ==== Task 3: Implement messaging-tenant controller in controller-manager (medium)
  
  The messaging-tenant controller manages the MessagingTenant CR
  
  * Watch MessagingTenant CRs
  * Use label selectors of MessagingInfra to locate the infra for namespace
  * Lookup infra state representation
  * For each router:
  ** Apply vhost settings+limits, authentication service information
  