Support Page

[rhuss]

Initial ideas:

• Download button for collecting relevant logs which can be used by the user to gather infos and send it to support
• Dedicated screen section with
  • Version numbers
  • Uptime (?)
  • Restarts
  • Number of integrations .... (tbd)

[paoloantinori]

The idea behind this feature is to provide any useful help to GSS and Sustaining engineers to debug possible problems.

The functionality had briefly appeared in JBoss Fuse 6 and proved to help.

The feature was showing a page were the user could choose among a set of predefined actions to extract debug information from any of the managed nodes in JBoss Fuse, and automatically attach them to GSS support case.

I think for the time being, we are suggesting a simplified workflow where we just allow the user to choose which information to extract, and just produce a .zip file that he's going to download on his own desktop. Leaving the step of attaching it to a case as a manual step for the user.

The old system was exposing the whole set of choices to the user. His options were:

• logs
• heapdump
• all (collection of many output from Karaf command line invocations)

The reasoning of what we have to offer here will be a technical discussion, but from a UX point of view I think we have to classify the options in a similar manner and possibly reasoning about privacy data and why a customer could have good reason not to share diagnostic information with us.

Anyhow, since the delivery of this information to Red Hat is a 2 steps operation, with the file downloaded on the user desktop, maybe we could describe a suggested workflow, where we tell the user they can mask all the sensitive information in the downloaded logs before forwarding them to us.

Another differentiator between the options could be to point out which are those that require a running pod and which that don't. For example to take a threaddump, the pod must be running, while for logs that is not a strict requirement

For the technical aspects of which information we want to share, it's really depending on the platform:

• Openshift status of the cluster
• Openshift administrative configuration (user, permissions and so on)
• logs
• heapdump if the pod is running
• threadump if the pod is running
• database dump
• connections state
• integrations definition

Nothing on this list is either definitive or strictly required, but the more have, the better we can help to diagnostic issues.

[rhuss]

I think for the time being, we are suggesting a simplified workflow where we just allow the user to choose which information to extract, and just produce a .zip file that he's going to download on his own desktop. Leaving the step of attaching it to a case as a manual step for the user.

Yes, I think this should be sufficient as the initial step.

Anyhow, since the delivery of this information to Red Hat is a 2 steps operation, with the file downloaded on the user desktop, maybe we could describe a suggested workflow, where we tell the user they can mask all the sensitive information in the downloaded logs before forwarding them to us.

One idea was to allow the user to select what to export, and whether the export should contain e.g. the connection passwords (off by default).

Agreed with your list, the more the better. Some are easy to retrieve (e.g. like the logs via a call to the OpenShift API), other a bit more involved (like thread or heap dumps). I would start simple (logs) and then add to this. A UX discussion is required how and what download options should be presented.

Plus some information (like versions) should be directly visible on this support page.