Design for Integrated Console

OVERVIEW

The purpose is to have one console, that can be used to create the enmasse address spaces, iot spaces, as well as kafta, brokers, and routers. There will be a new project for the slim integrated console, that will delegate to each component, to create, delete, list instances. The integrated console will only provide the ability to view a list of each instance, and the ability to create, delete (edit)? them.

DESIGN

Repository Strutcture

If we used https://github.com/EnMasseProject/console, it should be for the EnMasseConsole, not the integrated console. Therefore, suggesting https://github.com/EnMasseProject/integrated-console. Another option is being a consolidated console it could be in the repo that contains many of the AMQ projects https://github.com/rh-messaging.
Structure.
The integrated-console repository should contain directories: console-ui (PF4 react), console-service (go), and console-mock-service.

Console Server:

API:

• GET /v1/components => list all amq components
  • name
  • create-url
  • description (for first screen of create)
  • instances-count (could move the count into its own call. But the header always needs the instances & count
• GET /v1/instances?name=xxx?component=xxx&sort_by=&order_by=asc&offset=10&limit=5 => list of instances, filter by name, paging.
  • In the markup, the ordering is confusing. Widgets appear in both the filter, and the table?
  • do we want multi-column sort?
• GET /v1/instances/123 => specific instance
  • name
  • created by
  • component
  • type
  • status (alive / dead, not throughput)
  • component console url
  • time created
  • statistics (addresses, queues, connections / AMQP Addresses, senders, receivers / topics,senders,consumergroups / addresses, connections), ordered by priority
• DELETE /v1/instances/123

FEATURES

• Authentication: Authenticate against openshift
  • oath to get a token to be used for any communication.
  • click through to existing AMQ Online Console (and navigate back)
  • ensures users can only see resources that they have permissions to. And if you can view a resource, you can get the stats etc.
• console server would need to be run under a service account for permissions
• update mechanism (amqp/http), used by prometheus etc. for polling. The other option is websockets, but not as common.
• wraps the kubernetes calls, to provide a well defined api.
• message throughput graphs (later)
• be able to make a stub console server (mock out kubernetes)

Each Component console (EnMasse, Kafta, …):

• Will provide HTML and Javascript to support the create workflow.
  • THis will populate the fields of the CRD resource.
    • configuration page, that updates object: url/configure
    • review page, url/review
    • POST
  • create instance
  • delete instance
  • throughput info for graph?
• CRD resource updated by the component.
• When the console is instanciated in Openshift it will define its CRD with its version.
• For each instance of its component that it creates, it will create/update

Example CRD created by Enmasse Console on deploy

apiVersion: apiextensions.k8s.io/v1beta1 
kind: CustomResourceDefinition
metadata:
  name: addressspaceinstances.enmasseconsole.messaging.io (or kaftainstances.kaftaconsole.messaging.io)
spec:
  group: enmasseconsole.messaging.io
  version: v1 
  scope: Cluster
  names:
    plural: addressspaceinstances
    singular: addressspaceinstance 
    kind: AddressSpaceInstance
    shortNames:
    - asi

Example Custom Object, created on new address space.

apiVersion: enmasseconsole.messaging.io/v1" 
kind: AddressSpaceInstance
metadata:
  name: address-space-instances
component-create-url: "http://..."
display-name: "address space"
display-description: ...
instance-count: 2
instances:
- name: AddSpacer01
  created-by: "annoymous_test1"
  type: "standard"
  status: "alive"
  component-console-url: "http://.../objectid"
  component-delete-url:
  component-edit-url:
  time-created:
  statistics: ["addresses:192", ...] ordered by priority
- name: AddSpace02
  created-by:...
  ...

[k-wall]

I like the prometheus idea, but maybe it would be best if the design didn’t mandate it. If each component submitted a statistics plugin to the console-server its implement could find and emit the statistics in the way that suits it. For components that use prometheus, they could periodically call out to it and then periodically emit the results… They would be free to use an different implementation.

Re watchable component resources. I think it would be too inflexible to try and impose standard form. Users could be bringing their own components and plugging them in to the console.

[k-wall]

We decided to defer statistics for a later phase and take an alternative approach for retrieving the resources (i.e. use the Kubernetes API directly from the UI, rather than effectively proxying it in a console server. I opened a new issue to replace this one #2408.