anchor.diff:  
   == Design overview
   
  -A new `MessagingInfra` type will be created and used to define an instance of shared infrastructure. The `MessagingInfra` will define everything related to router and broker configuration that applies to all tenants.
  -
  -A new `MessagingPlan` type will be created, and will conceptually replace the `AddressSpacePlan`, but be limited to shared infra configuration.
  -
  -AddressSpace resource will be deprecated, and 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 `MessagingConfig`, `MessagingEndpoint` and `MessagingConnector` resources.
  -
  -The `MessagingConfig` type, which will be a singleton per namespace, is introduced to contain the messaging configuration of a namespace.
  -
  -The `Address` and `AddressPlan` types will remain, but the schema will be extended to support options required by the shared infrastructure.
  -
  -The `qdr-operator` and `activemq-artemis-operator` operators will be used for managing routers and brokers.
  -
  -The `cert-manager` operator will be used to manage certificates, both internal and external.
  +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.
  -
  -MessagingUser and Address will no longer needed to be prefixed with address space name!
   
   === Service operator
   
  
positive.code: 
  * Autolink states
  * Linkroute states
  * Link states
  
  The data will be stored in memory available to the messaging config and address controller loops.
  
  ===== Controllers
  
  
negative.code: 
  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 `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.
  
  