Custom menu via /api/config with project links as defaults

[tiffon]

Fix #44.

• Configurable top-level links
• Attempts to download /api/config, errors cause fall-back to default
• Supports one level of nesting
• Supports a label and url for each link
• Groups support a label and items where items is an array of links
• All links open to external tabs
• Does not currently support a "selected" state for links

Default menu config:

• About Jaeger
  • GitHub
  • Docs
  • Twitter
  • Discussion Group
  • Gitter.im
  • Blog
• Create a ticket

Screenshot updated

[coveralls]

Coverage increased (+0.4%) to 57.143% when pulling fdf3576 on issue-44-configurable-header-links into f77ea5b on master.

[yurishkuro]

Nice!

• Could you please add a section to the README about how people can use a custom config without rebuilding the UI? We talked about ENV variable. Or does this have to happen in jaeger-query?
• Can we alter the "Jaeger UI" title? For example, I would like to add a datacenter name to it.
• It seems odd that the primary parts of the menu (Search/Deps/Search box) are flushed to the right, while auxiliary menu items are on the left. Usually it's the other way around.

[saminzadeh]

Great work.

I'm a bit impartial about the "Create Ticket" as a default config. What do you guys think? If you provide your own, will it override existing or merge the two?

[saminzadeh]

Could you please add a section to the README about how people can use a custom config without rebuilding the UI? We talked about ENV variable. Or does this have to happen in jaeger-query?

I think thats a good idea, the build process can create an .env file and put a JSON list of the config so its technically static. Just like the GA Analytics key. If we need it to be dynamic without rebuilding, then the /config endpoint makes sense.

[black-adder]

I'm a bit impartial about the "Create Ticket" as a default config. What do you guys think? If you provide your own, will it override existing or merge the two?

I think for external users, it makes sense for them to ping their own tracing/infra team first before opening a ticket against us so even if we agree to have the "create ticket" option, I don't think it should be so prominent in the UI.

[tiffon]

• Could you please add a section to the README about how people can use a custom config without rebuilding the UI? We talked about ENV variable. Or does this have to happen in jaeger-query?

@yurishkuro It needs to happen in jaeger-query. I'll add info to the README when it's implemented.

• Can we alter the "Jaeger UI" title? For example, I would like to add a datacenter name to it.

@yurishkuro That will need to be provided as part of the config that is loaded. Would providing something like the following at the /api/config endpoint work?

{
	"menu": [etc...],
	"name": "Jaeger - Some DC"
}

• It seems odd that the primary parts of the menu (Search/Deps/Search box) are flushed to the right, while auxiliary menu items are on the left. Usually it's the other way around.

@yurishkuro I'll move them around.

I'm a bit impartial about the "Create Ticket" as a default config. What do you guys think? If you provide your own, will it override existing or merge the two?

@saminzadeh Right now, if the user provides their own config, it will fully replace the current config; they're not merged.

I think thats a good idea, the build process can create an .env file and put a JSON list of the config so its technically static. Just like the GA Analytics key. If we need it to be dynamic without rebuilding, then the /config endpoint makes sense.

@saminzadeh We discussed using a /api/config endpoint, the payload can be defined via an env var for the query-service which would point to a config file. It can default to either {} or 404. If we default it to the former, I need to make a small change...

I think for external users, it makes sense for them to ping their own tracing/infra team first before opening a ticket against us so even if we agree to have the "create ticket" option, I don't think it should be so prominent in the UI.

@black-adder Currently there is only one level of promience, pretty much everything is the same. So, if we want to deemphasize the create ticket links, we should take them out.

@yurishkuro Any thoughts on taking out the create ticket links?

[saminzadeh]

We discussed using a /api/config endpoint, the payload can be defined via an env var for the query-service which would point to a config file.

@tiffon If the payload is stored in the .env file, why not just have create-react-app build with it so its available as a static JSON object in the UI code?

[tiffon]

If the payload is stored in the .env file, why not just have create-react-app build with it so its available as a static JSON object in the UI code?

@saminzadeh The current thinking is to parameterize the jaeger query-service so a custom /api/config can be served. This will allow users to customize the menu and whatever else ends up in the config without needing to rebuild the UI. @yurishkuro suggested the jaeger query-service can consume an environment variable which points to a custom config JSON or YAML file.

[yurishkuro]

Any thoughts on taking out the create ticket links?

I would take them out, completely agree with Won's comment. Internally we'll have Create Ticket link that goes to Phab.

[saminzadeh]

@saminzadeh The current thinking is to parameterize the jaeger query-service so a custom /api/config can be served. This will allow users to customize the menu and whatever else ends up in the config without needing to rebuild the UI. @yurishkuro suggested the jaeger query-service can consume an environment variable which points to a custom config JSON or YAML file.

Make sense but if we don't plan on supporting changing the config dynamically through an endpoint, we should use the env file since query service builds it anyways right?

jaeger-query$: echo 'MENU={ "name": "Root", "menu": [..] }' > ui/my-custom-ui-config.env
jaeger-query$: cd ui && npm run build # create-react-app reads .env file on build and injects it

If we plan on making a config endpoint in the query service, might as well move all options there including the Google analytics key (which is currently done through .env file)

HTTP PUT /config
{ "uiMenu": { "name": "Root", "menu": [..] } }

It would make sense via GET /config

My point is, we should pick one for all UI config options

[tiffon]

@saminzadeh We are planning to support dynamic config through the endpoint.

It would be GET /api/config because anything other than /api is served as a static files off the disk whereas the config needs to check the env-var and possibly serve some other static file.

Moving the Google Analytics key to the config is a great suggestion, nice 👍

[saminzadeh]

We are planning to support dynamic config through the endpoint.

Ok, in that case your approach sounds good.

[tiffon]

I've taken out the create ticket links and moved the custom links to the right side of the nav.

[tiffon]

@saminzadeh Will look into moving the google analytics to the config in a separate ticket.

Right now the GA integration is not working, I think it might be related to the upgrading react-router. Secondly, moving it to the config will kill GA integration (once it's working again) until the query-service supports the config endpoint.

[coveralls]

Coverage increased (+0.4%) to 57.143% when pulling 4e2e98b on issue-44-configurable-header-links into f77ea5b on master.

[coveralls]

Coverage increased (+0.3%) to 56.941% when pulling c2b800a on issue-44-configurable-header-links into 5162309 on master.

[saminzadeh]

LGTM

[tiffon]

@yurishkuro This change implies a change in the query service. It can function without the change, but I need to make sure it will handle the default response of the query service, properly, once the change is in place.

What will the default response be from the query service? We discussed it being {}.

[yurishkuro]

it can be that, or a 404

[saminzadeh]

I would avoid a 404 (browser shows it as an error in the console, kinda annoys me). I'm more a fan of returning some default object, maybe version number and other useful information then having the config be a property on that main object even if people don't set it up.

ex:

{
  version: "xx",
  commit: "xxx",
  menu: null
}

[coveralls]

Coverage increased (+0.6%) to 56.659% when pulling a945c3b on issue-44-configurable-header-links into 5139c7f on master.