anchor.diff:  
   The `MessagingInfra` resource would be managed by the enmasse-operator, which will do a reconciliation of deployments, services etc. The router-operator should be used to deploy and manage the dispatch router to simplify the interface. Depending on the maturity of the broker-operator, it should be used to deploy the brokers.
   
  -The `MessagingConfig` resource will be managed by a controller in enmasse-operator. The controller will create vhost policies in the shared router infra for each namespace with a config, and apply restrictions as specified in the messaging plan.
  +The `MessagingTenant` resource will be managed by a controller in enmasse-operator. The controller will create vhost policies in the shared router infra for each namespace with a config, and apply restrictions as specified in the messaging plan.
   
   The `Address` resource for `shared` infra will be managed by a controller in enmasse-operator. The controller will watch all addresses across all namespaces, and apply the needed address configuration to brokers and routers using AMQP management.
   
  
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: * (Optional phase 2): Take broker anti-affinity into consideration during placement
  * (Optional phase 2): Take available broker memory for queue into account during placement
  
  ==== Task 6: Implement messaging-endpoint controller in controller-manager (medium)
  
  * Watch MessagingEndpoint CR
  * Find MessagingInfra where this is placed (based on referenced MessagingPlan)
  