Solution Hub

The Solution Hub is the component of IBM Industry Solutions Workbench that brings the capabilities of Solution Designer to OpenShift projects. These OpenShift projects are called k5-projects within IBM Industry Solutions Workbench. It is the place to monitor all your deployments, configured pipelines and the related pipeline runs in your cluster.


product overview

General capabilities

Solution Hub is a monitoring and managing tool for operations teams and administrators that offers the following capabilities:

  • Shows all deployments in each of the deployment targets (k5-projects)
  • Delete a deployment from the cluster
  • Configuration of the deployment targets
  • Manage event topic bindings
  • Shows all pipeline runs of a deployment target

Solution Hub is separated in two layers:

  • Environment - provides a list of all k5-projects in the cluster
  • Project - provides information on a single k5-project and all its deployments

Environment

The Environment layer is the top-level view on all k5-projects. From here you can choose a k5-project to manage.

Projects

The k5-Projects tab on this page displays the following information for each k5-project of IBM Industry Solutions Workbench.

  • Name: Name of the k5-project - displayed as a link to the Project's details
  • Stage: Name of the stage
  • Type: Type of stage of the project, possible values are DEV (for development purposes), TEST (for testing purposes), STAGE (e.g. for pre-production environments) and PROD (for production environments)
  • OpenShift Project: Related OpenShift project displayed as a link to the OpenShift Developer Portal
  • Created by: Name of the project creator (optional column)

Topic Bindings (Environment)

Topic bindings are used to set up a connection to a Kafka topic. Therefore, there must be at least one Message Hub Service Binding configured that sets up a connection to a Kafka cluster.

Whenever you create an Event in Solution Designer you will have to select a Topic Binding that specifies to which topic this event will be published. This Topic Binding will always get stored on the environment level, meaning that you can reuse it in every Service Project you need it. So if you create multiple events in multiple projects that should get published to the same topic, then you can simply choose the same Topic Binding.

Tip:

If you want to use different topics on different stages (e.g., you want to use one topic while you are implementing the project but when deploying the project to a production stage you may want to use another topic), you can still use the same Topic Binding. You just have to create a Project Topic Binding from the Environment Topic Binding for the desired deployment target to overwrite the topic name. The pipeline will then use the specific binding.

Pipeline Runs

The Pipeline Runs tab shows a list of all pipeline runs related with this k5-project. It provides the following information:

  • Name: Name of the pipeline run (with link to OpenShift Web Console)
  • Pipeline Type: Type of the pipeline, possible values are Deploy or Release
  • Status: Run status
  • Task Status: Status of the tasks
  • Started: Time started
  • Duration: Duration of the pipeline run
  • Project: Name of the project (with link to OpenShift Web Console) - this column is not visible by default
  • Pipeline: Name of the pipeline (with link to OpenShift Web Console) - this column is not visible by default
Tip:

The links to the OpenShift Web Console direct to the respective sub-page and require authentication.

Project

The Project layer can be reached by clicking on a k5-project in the Environment layer. It provides the following tabs to manage and monitor your deployments:

Application Deployments

The Application Deployments tab on the Projects overview page displays the following information for each of the application composition project deployed to the k5-project. The table is displayed in two levels. The first level shows all application composition projects with the summarized states. The second level shows the deployed components of a application composition project and their status. Per default, the application deployments will be shown in all states. This can be adjusted by using the filter tabs of the table.

Application composition project level*

  • Application Acronym: The application composition acronym, which is used to group the components (and a link to the instance page)
  • Health Status: Summarized Health Status of the components; possible values are Healthy, Degraded and Missing
  • Sync Status: Summarized Sync Status of the components; possible values are Synced, Out of sync and Unknown
  • Last Sync: Last time when the components has been synched

Component level

  • Component Name: Name of the deployed component (with a external link to Argo CD)
  • Version: Currently deployed version of the component
  • Health Status: Health Status of the component; possible values are Healthy, Degraded and Missing
  • Sync Status: Sync Status of the component; possible values are Synced, Out of sync and Unknown
  • Last Sync: Last time when the component has been synched
Tip:

To undeploy a project use the header or inline Undeploy capability. After confirming the action, the project will be undeployed. All data and pipelines created in the designer will stay the same. This action will take some minutes, so refresh the page after a few minutes. Once the undeploy is done, the project will no longer appear in the Project overview.

Application instance page

The Application instance page shows you details of the deployed Application Composition Projects with a table of the components and addition data of the application.

  • Acronym: The acronym of the component
  • Component Name: Name of the deployed component (with a external link to Argo CD)
  • Version: Currently deployed version of the component
  • Health Status: Health Status of the component; possible values are Healthy, Degraded and Missing
  • Sync Status: Sync Status of the component; possible values are Synced, Out of sync and Unknown
  • Last Sync: Last time when the component has been synched

Service Deployments

The Service Deployments tab on the Projects overview page displays the following information for each of the service projects deployed to the k5-project. Per default, the deployments will be shown in all states. This can be adjusted by using the filter tabs Running or Failed of the table. The table rows offer an inline capability Undeploy to undeploy a deployed project.

  • Solution Acronym: The project's acronym
  • Component Name: Name of the deployed project
  • Pods Available: Ready replicas / Replicas of the deployment
  • Status: Status of the deployment; possible values are running, error and unknown
  • Pipeline Run: Link to the pipeline run that deployed the service
  • Description: Additional information for the project
  • Last Deployment Timestamp: Time when the project has been deployed
Tip:

To undeploy a project use the header or inline Undeploy capability. After confirming the action, the project will be undeployed. All data and pipelines created in the designer will stay the same. This action will take some minutes, so refresh the page after a few minutes. Once the undeploy is done, the project will no longer appear in the Project overview.

k5-Project Configurations

The project configuration is the place to configure the runtime for the deployed projects. See configuring deployment targets for further details on configurations.

Topic bindings (k5-project)

This variant of Topic Binding is used to overwrite the content of the Environment Topic Binding. Let's say you have four stages (DEV, TEST, INT, PROD) and you want to use one topic on the first 3 stages but on PROD you want to use a different topic. By using both types of topic bindings you only have to overwrite the value of topic name in the binding for the PROD stage and the pipelines will do the rest for you.