这是indexloc提供的服务,不要输入任何密码
Skip to content
This repository was archived by the owner on Feb 13, 2025. It is now read-only.

Conversation

@bom-d-van
Copy link
Contributor

@bom-d-van bom-d-van commented May 27, 2018

With this patch bosun could connect to elasticsearch servers with different versions. Supported version are: 2.x, 5.x, 6.x. This is a breaking change, requiring users to update their configuration files to explicitly specify elasticsearch version with 2, 5, or 6, otherwise it would just panic (fail fast).

No compile and test errors on my machine, but I haven't test it against real elastic search servers. Publish it here to check out the community's opinions and the possibility of merging onto master. :)

Relevant tickets: #2240, #1982

@bom-d-van bom-d-van force-pushed the master branch 3 times, most recently from ffe0e99 to e693bfa Compare May 27, 2018 20:12
@bom-d-van bom-d-van changed the title Support multiple versions elasticsearch at runtime Support connecting to multiple versions elasticsearch at runtime May 27, 2018
@bom-d-van
Copy link
Contributor Author

Hi, the changes has been tested (thanks @pradeepbbl). And it seems working fine. Also updated doc for how to update config files.

@stepashka
Copy link

Hey @kylebrandt, @captncraig!
Any objections to this change? Is there something else we need to implement before this gets merged?
Thanks,
Anna

@kylebrandt
Copy link
Member

There was some refactoring that has been done that will require this to be updated (how miniprofiler is done).

I'm not entirely clear on how the config is a broking change based on the documentation - is it only the Version field or is there more to it?

Since the vendoring is so big, and 2.x is EOL (see https://www.elastic.co/support/eol) can we yank that?

Supporting Multiple ES version will be nice and make upgrading easier on users.

@bom-d-van
Copy link
Contributor Author

bom-d-van commented Sep 20, 2018

Hi @kylebrandt

There was some refactoring that has been done that will require this to be updated (how miniprofiler is done).

No problem. I could rebase master and update it one more time.

I'm not entirely clear on how the config is a broking change based on the documentation - is it only the Version field or is there more to it?

Because before this change, bosun could only talk to one version of es server but now with multiple version support if we default it to any of the versions (2/5/6), it might break the other two when the es query is run because of wrong version of es client. Users would wonder what breaks it, also arguably harder to debug.

Therefore I explicitly panic the program on start up so users know that they have to update the configuration after upgrading the program.

@bom-d-van
Copy link
Contributor Author

A bit late but really happy maintainers finally come to this PR.

@bom-d-van
Copy link
Contributor Author

Pushed the update and all seems working (no compile or test errors). Didn't drop v2 support yet because I am not sure if all maintainers are onboard with it.

@kylebrandt
Copy link
Member

@stepashka Does Booking still care about Bosun support ES 2.x?

@stepashka
Copy link

stepashka commented Sep 20, 2018

Thank you for checking, @kylebrandt! :)

Yes, we still have a couple of ES 2.* clusters :(

case expr.ESV6:
cfg = parseESConfig6(value)
default:
panic(fmt.Errorf("conf: invalid elastic version: %s (supported versions are: v2, v5, v6)", value.Version))
Copy link
Member

Choose a reason for hiding this comment

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

slog.Fatal is more appropriate (exit with error code, no stack trace). panic is more for programming errors and not user configuration errors.

case expr.ESV6:
cfg = parseESConfig6(ElasticConf(sc.AnnotateConf))
default:
panic(fmt.Errorf("conf: invalid elastic version: %s (supported versions are: v2, v5, v6)", sc.AnnotateConf.Version))
Copy link
Member

Choose a reason for hiding this comment

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

same here with panic vs fatal

@kylebrandt
Copy link
Member

Can bump the middle the number of Version in version.go since this will be a breaking change.

"fmt"

"bosun.org/cmd/bosun/expr"
"github.com/bosun-monitor/bosun/slog"
Copy link
Member

Choose a reason for hiding this comment

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

import here needs to be bosun.org/bosun/slog

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Typo? You mean to write "bosun.org/slog", right?

Copy link
Member

Choose a reason for hiding this comment

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

oops yes

@kylebrandt
Copy link
Member

kylebrandt commented Sep 21, 2018

I noticed that the Fatal call doesn't happen until you call an elastic expression. If we are going to have that, I think it should be in cmd/bosun/conf/system.go loadSystemConfig so it happens at start.

@bom-d-van
Copy link
Contributor Author

Nice catch. I decided to do the pre-check in main because the get APIs don't return errors and loadSystemConfig does.

cfg = parseESConfig6(value)
default:
panic(fmt.Errorf("conf: invalid elastic version: %s (supported versions are: v2, v5, v6)", value.Version))
slog.Fatal(fmt.Errorf("conf: invalid elastic version: %s (supported versions are: v2, v5, v6)", value.Version))
Copy link
Member

Choose a reason for hiding this comment

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

For this and the annotate error we should include:

  • If it is for annotate or elastic, and also in the case of elastic which prefix it is (i.e. "default" or another named instance).
  • I think since this is a breaking change, we should add a case for an empty version and return an error message saying that is a required parameter (including the info from the above bullet point)

case "":
slog.Fatal(fmt.Errorf("conf: [AnnotateConf]: Version is required (supported versions are: v2, v5, v6)"))
default:
slog.Fatal(fmt.Errorf("conf: [AnnotateConf]: invalid elastic version: %s (supported versions are: v2, v5, v6)", value.Version))
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@kylebrandt how about this for the error message?

Copy link
Member

@kylebrandt kylebrandt Sep 24, 2018

Choose a reason for hiding this comment

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

Good, I would just change Version is required a field (supported values for Version are: "v2", "v5", and "v6")

Because: "Version" is a pretty generic word, so clarify that is a field, and since the values are strings, putting them in quotes maybe helps prevent a future Toml error.

@kylebrandt
Copy link
Member

The last thing on my list is optional (and kind of annoying request).

That is basically to create a new PR with two commits:

  • The vendor Commit
  • The non-vendor changes

The reason is that:

  1. It could be rebased, but then when rebased on master these commits will show up old in the commit log (unless you do some extra git trickery with timestamps.
  2. If I just squash it all into one then it is a giant commit due to the vendoring

I'm saying it is optional because I really appreciate your hard work and patience. So if you don't have the time for copying around all the files or git magic to rewrite timestamps with a rebase, then I am fine accepting option 2 and just squashing it all into one.

@bom-d-van
Copy link
Contributor Author

bom-d-van commented Sep 24, 2018

@kylebrandt No worries, I have pushed the changes and created another PR. Hope it's done as expected. :)

@bom-d-van
Copy link
Contributor Author

Really thank you for the review too. It's lots of work and nice suggestions!

@kylebrandt
Copy link
Member

done via #2316

@kylebrandt kylebrandt closed this Jan 14, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants