The following change introduced in the OpenShift Ansible playbook openshift/openshift-ansible#5264 breaks the current integration by default as subdomain origins do not match CORS allowed origins configured on the master server.

I'd like to be able to configure a namespace selector, so that only pods from namespaces with matching labels are displayed.

Our OpenShift cluster spans over multiple networkzones and network traffic between the network zones is disallowed (this includes SDN traffic). Altough I might have rights for pods in DEV and PROD the Hawtio-online in DEV only ever has access to DEV pods and the PROD hawtio-online will never have access to DEV. Having pods listed that are not accessible is a usability issue and also causes some hickups in the browser. For example Chrome waits long time showing "Waiting on available socket ..." when opening the console of a pod ("Connect") , probably until some of the blocked connections time out.

I'm trying create a PR for this. I managed to locate where the selector needs to be injected: https://github.com/vinzent/hawtio-online/commit/0085f7130785b9b7a11a5a5c2fcb80f46cb83510 . Now I would appreciate some pointers on where I could put the configuration. I tried to use _.get(window, "hawtconfig.namespaceSelector", {}) (https://github.com/vinzent/hawtio-online/commit/26241b13f3b175b14ea077b02b5b5aa6931498f5) - but hawtconfig isn't available in that context.

Relevant PR's for this issue:

• hawtio/hawtio-core#44 - Add new hawtconfig.json property: online.projectSelector
• hawtio/hawtio-kubernetes-api#15 - Server side label selector feature
• #72 - Allow to filter projects with a label selector (depends on the other 2)

If I'm not mistaken, currently hawtio-online hardcodes the Jolokia port to 8778 and assumes it's available at /jolokia. However, for instance Artemis broker exposes the Jolokia endpoint with the following port and the path /console/jolokia by default:

      ports:
        - containerPort: 8161
          name: console-jolokia
          protocol: TCP

The main focus here is to recognise Artemis brokers on OpenShift but it would be also flexible that hawtio-online can pick up arbitrary port numbers and Jolokia paths given they are specified in the application deployment spec.

Sometimes an idle Integration view gets 401 unauthorized errors in the background and thus shows us the login prompt like the following. However, in the context of hawtio-online giving an username/password in the prompt shouldn't resolve the error. We should rather just close the view and reconnect to the pod from the Online view again. Thus it should be better that the prompt simply says we get an unauthorized error in the background and close the view with a single OK button, asking the user to reconnect to the pod again.

See https://docs.openshift.com/container-platform/3.9/architecture/additional_concepts/authentication.html#oauth-server-metadata.

Is it possible to replace hawtio-kubernetes-api with kubernetes-client/javascript and even if possible is it worth doing so? Instead of keeping the homebrewed k8s library it seems valuable to rely on the more actively maintained/popular library.

I guess the biggest challenge is where OpenShift authentication is used.

Does it make sense to provide a script to automate most of the steps described in https://github.com/hawtio/hawtio-online#openshift-4 so that users can just run it to do the job?

@astefanutti WDYT?

Depends on nodeshift-archived/license-reporter#304.

See:

• http://openshift.github.io/openshift-origin-design/web-console/project-details/select-route
• https://trello.com/c/CFNncxCB/1111-let-user-select-which-route-to-show-for-an-application

Original issue: openshift/origin-web-console#1926

The following are broken links:

• get started with the CLI
• service-signing-certificate
• OAuth Clients

Part of #89, required before removing the existing resources at the project root.

This might be a duplicate of #31 but the idea is to enable integration with SSO/identity providers the user has brought on a k8s cluster for their own apps. I think why currently it's hard to support vanilla k8s #23 for hawtio-online is its tight integration with OpenShift's OAuth mechanism and thus its being part of the OpenShift infra components. Unlike other monitoring components such as Prometheus and Grafana, hawtio-online should ideally be part of user applications and thus share the same authentication mechanism with them.

We have Hawtio-online running in OKD4 with istio sidecar injected so it can access the rest of the mesh which uses strict mTLS.
Services discovery work well and it discovered all the services.
However we cannot connect to any Jolokia and we can see lots of errors in logs like below:

upstream prematurely closed connection while reading response header from upstream, client: 127.0.0.6, server: localhost, request: "POST /management/namespaces/X/pods/https:X-0:8443/jolokia/ HTTP/1.1", subrequest: "/proxy/https:10.1.0.211:8443/jolokia/", upstream: "https://10.1.0.211:8443/jolokia/", host: "hawtio.X", referrer: "https://hawtio.X/online/online/discover"

From above I am judging that Jolokia is trying to access pod using pod IP which doesn't work out of the box in our case.

Solution to the problem is creating headless service, which then allows accessing individual pods by ip.
It might be worth documenting above so others don't have to waste time.

Also worth considering changing the hawtio operator to actually automatically create headless services if some parameter is set to true in operator config.

Thanks.

I want to run oc apply -f deployment-cluster-os4.yml multiple times. But a second run will trigger 2 additional deployments of the DeplyomentConfig.

Root cause

The ImageChange trigger injects the image reference into .spec.template.spec.containers[].image .

If you run oc apply -f deployment-cluster-os4.yml a second time, the image reference is reset to hawtio/online triggering the 2nd deployment. That will be canceled immediately due to the ImageChange trigger replacing the image reference again - triggering a 3rd deployment.

Solution

If one wants to run oc apply -f deployment-cluster-os4.yml in a declarative way, you need to remove the DeploymentConfig .spec.template.spec.containers[].image=hawtio/online key/value.

Environment

OpenShift 3.11 (probably same issue also on OpenShift 4, but not tested), Fuse 7.6

To be checked when kubernetes/kubernetes#61076 is fixed.

Reading nginx-gateway.conf I understand that apiserver communication is routed this way: user -> browser -> hawtio-online nginx proxy -> kube-apiserver

Proxying of apiserver requests enables a deployer of hawtio-online (or Fuse Console 7.x) to eaves drop any apiserver bearer token.

You just need some user with more privileges than you (think of: cluster-admin) to login to your hawtio-online console. If you prepared to log the header you now are able to do requests as that user.

Why is it technically required to proxy the apiserver requests?

Why can't the browser app connect directly to the apiserver instead?

I have a number of services running on a Kubernetes cluster. One of them have camel routes which I need to monitor. I am using hawtio online for it. But whenever I restart my service pod, Hawtio shows internal server error. I need to redeploy hawtio online to get it working again. Do anyone know the reason and solution for this issue? Also where is the default location of log files?

Only the OpenShift part is required.

hi, I deploy hawtio console as K8S. But i can't login with K8S serviceaccount.

####Here is my operate:

./scripts/generate-serving.sh
kubectl apply -k deploy/k8s/namespace

####My K8S resources already generate

The problem :

I can't to logout or login, please help me ...

Let's include Artemis plugin through the intermediary NPM package artemis-plugin-npm so that Hawtio Online can manage Artemis brokers on OpenShift.

Related hawtio/hawtio-integration#103

In development, when running hawtio-online locally it shows pods that are running on OpenShift 4.x, but connecting to one of them it gets "Connection lost" errors in a new window and fails.
https://github.com/hawtio/hawtio-online#run

I see hawtio-online-integration closes the vertical nav by default. I think it makes more sense for hawtio-online doing the same behaviour as it should only show the "Online" plugin effectively.

Depends on #4.

It's been more than a year since the last release. Let's cut another release. It will include new features including Kubernetes support.

For better security and stability.

For GitHub actions, you can use:

• https://github.com/container-tools/kind-action
• https://github.com/container-tools/microshift-action

Follow-up on #23.

From #88 (review):

The major area I see that remains is smoothing the user experience, in terms of configuration and documentation.

For the configuration, I can think of:

• Having a Kustomize configuration for vanilla Kubernetes
• Having an extra overlay for OpenShift (and maybe removing the existing resources at the project root)
• Deciding how to handle HTTPS serving or not:
  • We can go for documenting manual generation of the serving certificate
  • Or for relying on https://cert-manager.io/

For the documentation, I can think of:

• Updating the README to reflect that PR work
• Adding a section on how to create a ServiceAccount and retrieve its token to be used in the form login

Already done:

• Having a Kustomize configuration for vanilla Kubernetes
• Having an extra overlay for OpenShift

To do:

• Removing the existing resources at the project root
• Deciding how to handle HTTPS serving or not
• Updating the README to reflect that PR work
• Adding a section on how to create a ServiceAccount and retrieve its token to be used in the form login