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.

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

Support Kibana Spaces #8045

Merged
merged 12 commits into from
Oct 3, 2018
Merged

Conversation

ycombinator
Copy link
Contributor

@ycombinator ycombinator commented Aug 21, 2018

Resolves #7942.

Kibana is implementing a new feature called Spaces, in which Kibana saved objects (such as dashboards) and advanced settings can be restricted to a user-defined namespace. Spaces are identified by a unique ID, e.g. my-space. There is also a notion of a Default space which corresponds to how Kibana worked up until the Spaces feature was introduced.

Beats have the ability to import dashboards into Kibana as well as export dashboards out of Kibana. With Spaces, dashboards may belong to a specific space. So Beats must learn to accept an optional Space ID and operate against it when importing or exporting dashboards. This PR teaches Beats to do just that.

Concretely, if a user wishes to import or export dashboards from a specific space, say with ID = my-space, they must either:

  • Edit <beat>.yml and set setup.kibana.space.id: my-space, or
  • Run <beat> setup or <beat> export dashboard along with the -E setup.kibana.space.id=my-space option.

Similarly, if a Beat developer wishes to export dashboards from a specific space, say with ID = my-space, they must run:

go run dev-tools/cmd/dashboards/export_dashboards.go -space-id my-space [other options]

@ycombinator
Copy link
Contributor Author

Note that there is currently a bug in the Kibana Spaces implementation which allows a non-existent space ID to be specified without causing any errors: elastic/kibana#21408 (comment). Once this bug is resolved, I'd like to re-test this PR with a non-existent space ID to make sure we fail with a good error message.

@ruflin
Copy link
Member

ruflin commented Aug 22, 2018

I think it would be worth to add a system test for this to make sure it works. There are already tests loading dashboards which could be copied and adjusted.

Copy link
Member

@ruflin ruflin left a comment

Choose a reason for hiding this comment

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

I suggest to add the system tests directly as part of this PR? Code looks good but would be nice if we have automated tests around it so we also know in case functionality breaks in the Kibana side.

@ycombinator
Copy link
Contributor Author

ycombinator commented Aug 23, 2018 via email

@@ -48,11 +49,14 @@ func makeURL(url, path string, params url.Values) string {
return strings.Join([]string{url, path, "?", params.Encode()}, "")
}

func Export(client *http.Client, conn string, dashboard string, out string) error {
func Export(client *http.Client, conn string, spaceID string, dashboard string, out string) error {

Choose a reason for hiding this comment

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

exported function Export should have comment or be unexported

@ycombinator ycombinator changed the title Support Kibana Spaces via setup.kibana.space.id setting Support Kibana Spaces Aug 27, 2018
@alexfrancoeur
Copy link

@ycombinator @ruflin I'm pretty familiar with the Kibana dev environment but this is the first time I've been asked to be a reviewer for any beats changes 😄 What's the best way to go about testing this PR? Does this seem about right? Also, does make start the beat? How would I test with <beat> setup?

mkdir -p ${GOPATH}/src/github.com/elastic
cd ${GOPATH}/src/github.com/elastic
git clone https://github.com/elastic/beats.git
git checkout -b ycombinator-support-kibana-spaces master
git pull git://github.com/ycombinator/beats.git support-kibana-spaces
cd beats/packetbeat
make

Sorry for the n00b questions

@ycombinator
Copy link
Contributor Author

ycombinator commented Aug 28, 2018

@alexfrancoeur Ahhhh, sorry about that, but the steps you outlined are 👌. After the last step (make), you can then proceed to test this PR as follows.

  1. Edit packetbeat.yml and find the setup.kibana section. Under that, you should see a space.id setting, commented out. Uncomment it and set it's value to some space ID in Kibana (note that we currently have this bug that's relevant to this step: [Spaces] - Accessing non-existent Spaces kibana#22385)

  2. (If you are on a Mac) Also in packetbeat.yml, set packetbeat.interfaces.device: lo0 (because the default value of any for that setting doesn't work on Macs).

  3. Run the command to import Packetbeat dashboards into Kibana:

    ./packetbeat setup --dashboards -E setup.dashboards.directory=_meta/kibana.generated/
    

    If successful, you should see the following output:

    Loading dashboards (Kibana must be running and reachable)
    Loaded dashboards
    
  4. As an alternative to step 1, you should be able to specify -E setup.kibana.space.id=XXXX with the command in step 3.

Copy link
Member

@ruflin ruflin left a comment

Choose a reason for hiding this comment

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

Code changes overall look good to me.

Is CI not happy yet because the Kibana PR is not merged yet? Please ping me as soon as Kibana PR is in so I can manually test this against master.

@ycombinator
Copy link
Contributor Author

ycombinator commented Aug 29, 2018

@ruflin Yeah, CI is failing on this PR at the moment because the Kibana Spaces PR (elastic/kibana#21408) hasn't been merged into master yet. I checked with @legrego about the Kibana Spaces PR and it's expected to get reviewed and then merged about 2-6 weeks from now.

So I'm going to leave this PR here as-is until then and resolve any conflicts, etc. all at once after the Kibana Spaces PR has landed in master.

@ruflin
Copy link
Member

ruflin commented Aug 30, 2018

@legrego I would strongly prefer if we could get this rather sooner then later into master so we have enough time on our side to test the feature and integrate with it.

@legrego
Copy link
Member

legrego commented Aug 30, 2018

@ruflin

@legrego I would strongly prefer if we could get this rather sooner then later into master so we have enough time on our side to test the feature and integrate with it.

Understood. We'd love to get it in as soon as possible, but we are also trying to be realistic with our timeline. It's a large PR that will likely have a long review cycle, but we will do everything we can to get it into master in a reasonable timeframe.

In the meantime, is there anything we can do to facilitate testing?

@ruflin
Copy link
Member

ruflin commented Aug 31, 2018

@legrego Thanks for the details. I think so far we are covered as we manually test against the feature branch.

@ycombinator
Copy link
Contributor Author

Now that the Kibana Spaces PR is merged, I've rebased this PR on master.

@ycombinator ycombinator force-pushed the support-kibana-spaces branch 2 times, most recently from 4e38414 to 0f6feb8 Compare October 1, 2018 15:33
@ycombinator
Copy link
Contributor Author

CI is failing because the latest snapshot of Kibana being used by system tests is actually 3+ days old and therefore does not yet contain Spaces in it.

@ycombinator
Copy link
Contributor Author

Jenkins, test this.

1 similar comment
@ycombinator
Copy link
Contributor Author

Jenkins, test this.

@ycombinator
Copy link
Contributor Author

@ruflin CI is green now, after Kibana Spaces PR was merged into master and a few more changes to this PR around system tests. Ready for your review again. Thanks.

Copy link
Member

@ruflin ruflin left a comment

Choose a reason for hiding this comment

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

Did not test it locally but code and system tests LGTM.

}

headers = {
"kbn-xsrf": "1"
Copy link
Member

Choose a reason for hiding this comment

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

out of curiosity: Why is this needed?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@ycombinator ycombinator merged commit 2a04e2c into elastic:master Oct 3, 2018
ycombinator added a commit that referenced this pull request Oct 4, 2018
Cherry-pick of PR #8045 to 6.x branch. Original message: 

Resolves #7942.

Kibana is implementing a new feature called Spaces, in which Kibana saved objects (such as dashboards) and advanced settings can be restricted to a user-defined namespace. Spaces are identified by a unique ID, e.g. `my-space`. There is also a notion of a Default space which corresponds to how Kibana worked up until the Spaces feature was introduced.

Beats have the ability to import dashboards into Kibana as well as export dashboards out of Kibana. With Spaces, dashboards may belong to a specific space. So Beats must learn to accept an optional Space ID and operate against it when importing or exporting dashboards. This PR teaches Beats to do just that.

Concretely, if a user wishes to import or export dashboards from a specific space, say with ID = `my-space`, they must either:

* Edit `<beat>.yml` and set `setup.kibana.space.id: my-space`, _or_
* Run `<beat> setup` or `<beat> export dashboard` along with the `-E setup.kibana.space.id=my-space` option.

Similarly, if a Beat _developer_ wishes to export dashboards from a specific space, say with ID = `my-space`, they must run:

```sh
go run dev-tools/cmd/dashboards/export_dashboards.go -space-id my-space [other options]
```
@ycombinator ycombinator deleted the support-kibana-spaces branch December 25, 2019 11:12
immon added a commit that referenced this pull request Feb 26, 2020
leweafan pushed a commit to leweafan/beats that referenced this pull request Apr 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants