Document 7.5 Operator: Updates for acceptor config and console access

In 7:4:

A service and route for the console
A service and route for the all protocol port
We didn’t give users access to any of the other acceptors - the ports are exposed but there is no service/route.
You couldn’t go directly to AMQP only, Core only, etc.

In 7.5:

• You can define acceptors one by one. Each one will automatically get a service and route in the Broker pod.
• Accessing the console will be the same as before. Each broker pod that you start has a specific service and route for its own web console. However, these are now automatically created.
• Username and password still come from environment variables. If you don’t specify these in your custom resource, they are auto-generated, in which case you would have to go into your environment variables to see what they are in order to log into the console.
• One caveat, that is not yet resolved: by default, both clustering and the scaledown controller require an acceptor on the broker on port 61616. Previously, this was always exposed via the all protocols port. Now, we need to think about telling users what it means if they don’t create this, or create and acceptor internally without exposing it to users.
• Previously, only clustering and the scaledown controller created connectors (a means for outbound connections) on your broker. Now, we are giving users the ability to create these for themselves, but without an understanding of use cases.
• Previously, you enabled SSL in a blanket fashion. Now, you can have a combination of SSL and non-SSL connections. For example, all internal traffic might use a non-SSL connection, while external traffic uses an SSL connection.

#acceptors:

1. • name: all-protocol
     #protocols: all
     #port: 61616

1. • name: my
2. protocols: amqp
3. port: 5672

#connectors:

1. • name: first-c
     #host: localhost
     #port: 22222
   • name: second-c
     #host: 127.0.0.1
     #port: 33333