Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Infra UI] Honour space when querying TSVB API #36765

Merged
merged 4 commits into from
May 22, 2019
Merged

[Infra UI] Honour space when querying TSVB API #36765

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
049a9d1
Honour active space for requests to TSVB api.
skh May 21, 2019
c4edc2b
Add privilege necessary to make TSVB requests.
skh May 21, 2019
667e8fb
Announce our dependency on TSVB.
skh May 21, 2019
dca85b0
Merge branch 'master' into infraui-tsvb-honour-space
skh May 21, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion x-pack/plugins/infra/index.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,7 @@ export function infra(kibana: any) {
id: APP_ID,
configPrefix: 'xpack.infra',
publicDir: resolve(__dirname, 'public'),
require: ['kibana', 'elasticsearch'],
require: ['kibana', 'elasticsearch', 'metrics'],
Copy link
Contributor Author

@skh skh May 21, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please note that I don't really know if this is necessary or not, i.e. if there could ever be a situation with the TSVB API not being available anyway when we are. It works without this change now, but requiring it feels cleaner.

uiExports: {
app: {
description: i18n.translate('xpack.infra.infrastructureDescription', {
Expand Down
4 changes: 2 additions & 2 deletions x-pack/plugins/infra/server/kibana.index.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -42,15 +42,15 @@ export const initServerWithKibana = (kbnServer: KbnServer) => {
api: ['infra'],
savedObject: {
all: ['infrastructure-ui-source'],
read: [],
read: ['index-pattern'],
},
ui: ['show', 'configureSource', 'save'],
},
read: {
api: ['infra'],
savedObject: {
all: [],
read: ['infrastructure-ui-source'],
read: ['infrastructure-ui-source', 'index-pattern'],
},
ui: ['show'],
},
Expand Down
11 changes: 10 additions & 1 deletion x-pack/plugins/infra/server/lib/adapters/framework/kibana_framework_adapter.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -149,8 +149,17 @@ export class InfraKibanaBackendFrameworkAdapter implements InfraBackendFramework
) {
const internalRequest = req[internalInfraFrameworkRequest];
const server = internalRequest.server;

let url = '/api/metrics/vis/data';
if (server.plugins.spaces) {
const spaceId = server.plugins.spaces.getSpaceId(internalRequest);
if (spaceId !== 'default') {
url = `/s/${spaceId}${url}`;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the drive-by review, I saw it come across in slack: I don't fully understand this code, but can you use internalRequest.getBasePath() instead of deriving a space-aware URL yourself?

If that works, this should become something like

let url = `${internalRequest.getBasePath()}/api/metrics/vis/data`;

and then you can remove the check for the spaces plugin altogether.

Alternatively, if it's possible to make this request client-side, then you can get space-aware URLs for free there too. This would have the benefit of "just working" when you migrate to the New Platform too, as I don't expect they'll want to expose server.inject to plugins anymore.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are very valid comments, thank you.

The issue here is that server.inject seems to inject the request below any base path that might be configured, so adding the full base path (random thing + space, if applicable) does not work.

The request is server-side because we're hiding the functionality behind a GraphQL endpoint.

I agree this is something we need to tackle for the new platform, but that's beyond the scope of this bugfix.

@simianhacker what do you think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for clarifying @skh, I hadn't considered the server base path being stripped out of the server.inject handling.

I totally understand that refactoring is out of scope for this PR 👍

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume after the Platform refactor/upgrade we will need to re-evaluate how the internal requests work. I'm sure the platform team will provide guidance on how they expect this to work.

}
}

const request = {
url: '/api/metrics/vis/data',
url,
method: 'POST',
headers: internalRequest.headers,
payload: {
Expand Down