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

We need to load a different template for 6x than 5x #3368

Closed
tsg opened this issue Jan 13, 2017 · 5 comments
Closed

We need to load a different template for 6x than 5x #3368

tsg opened this issue Jan 13, 2017 · 5 comments
Assignees
Labels

Comments

@tsg
Copy link
Contributor

tsg commented Jan 13, 2017

Elasticsearch 6.x rejects templates that set any _all settings. We do that in our templates, so we'll need to create different templates for 5.x and 6.x.

Marking this as a blocker for 5.3, in case we're releasing 5.3 from the current master.

tsg pushed a commit to tsg/beats that referenced this issue Jan 13, 2017
This is a temporary workaround for elastic#3368. We'll need to add the `_all` setting
only in the 2x/5x versions of the templates. Should fix the builds.
ruflin pushed a commit that referenced this issue Jan 13, 2017
This is a temporary workaround for #3368. We'll need to add the `_all` setting
only in the 2x/5x versions of the templates. Should fix the builds.
@tsg tsg added the needs_backport PR is waiting to be backported to other branches. label Jan 15, 2017
@ruflin
Copy link
Member

ruflin commented Jan 19, 2017

We currently only used norms: false under all. As almost all fields (except for some raw fields) are part of the template, we could set norms:false` for each field in the template. This should have an almost identical outcome and would require only 1 template for 5.x and 6.x.

@tsg
Copy link
Contributor Author

tsg commented Jan 19, 2017

Hmm, I'm not sure it would be the same. In 5.x, _all is an actual field with its own settings, unrelated to the fields it is build from.

@ruflin
Copy link
Member

ruflin commented Jan 19, 2017

@tsg you are right, I mixed up two different things 👎

@tsg tsg added bug and removed blocker needs_backport PR is waiting to be backported to other branches. v5.3.0 labels Feb 7, 2017
@tsg
Copy link
Contributor Author

tsg commented Feb 7, 2017

The (temporary) solution for 5.3 is to add back the _all setting, but only in the 5.3 branch. We still need a proper solution for a future version, probably for 5.4.

tsg pushed a commit to tsg/beats that referenced this issue Feb 7, 2017
This is a temporary solution for elastic#3368, to avoid a breaking change
in 5.x.
monicasarbu pushed a commit that referenced this issue Feb 7, 2017
* Bring back the _all field in 5.x

This is a temporary solution for #3368, to avoid a breaking change
in 5.x.

* use the 5.3 snapshots
@exekias exekias self-assigned this Mar 20, 2017
@exekias
Copy link
Contributor

exekias commented Apr 17, 2017

This was fixed by #3778, master uses a different approach too:

basicStructure.Put("mappings._default_._all.norms.enabled", false)

@exekias exekias closed this as completed Apr 17, 2017
exekias added a commit to exekias/beats that referenced this issue Apr 19, 2017
This is the behavior for the whole Beats 5.X branch but after switching
to `template.go` in master we missed ES 5.X here. This change takes it
back while keeping 6.X compatible.

I already disabled `_all.norms` for ES 6.X in elastic#3368
ruflin pushed a commit that referenced this issue Apr 19, 2017
This is the behavior for the whole Beats 5.X branch but after switching
to `template.go` in master we missed ES 5.X here. This change takes it
back while keeping 6.X compatible.

I already disabled `_all.norms` for ES 6.X in #3368
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants