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

BREAKING CHANGE! New default template for ES 5.0 #398

Closed
wants to merge 7 commits into from

Conversation

untergeek
Copy link
Contributor

Do not use this with older versions of Elasticsearch. It will not work.

This template has been tested with the alpha1 release of Elasticsearch 5.0.0

fixes #386

Do not use this with older versions of Elasticsearch.  It will not work.

fixes logstash-plugins#386
@@ -1,7 +1,7 @@
Gem::Specification.new do |s|

s.name = 'logstash-output-elasticsearch'
s.version = '2.5.4'
s.version = '3.0.0'
Copy link
Contributor

Choose a reason for hiding this comment

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

Lets actually make it 5.0.0 so we immediately know what we're dealing with when a user reports an issue. normally, we want plugins to have their own version life cycle and follow semver, but this may be a special case where it warrants to track ES 5.0. Otherwise it may lead to a lot of confusing users and us

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right. I set it to 3.0.0 before we discussed it, then didn't change it after.

@@ -1,7 +1,7 @@
Gem::Specification.new do |s|

s.name = 'logstash-output-elasticsearch'
s.version = '2.5.4'
s.version = '5.0.0'
Copy link
Contributor

Choose a reason for hiding this comment

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

is this final 5.0.0 version? should we put an alpha or dev here for now?

Copy link
Contributor

Choose a reason for hiding this comment

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

or 5.0.0-SNAPSHOT

Copy link
Contributor Author

Choose a reason for hiding this comment

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

set it to alpha1 to match the ES release level.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I set it to alpha1 to match the ES version.

@@ -5,88 +5,37 @@
},
"mappings" : {
"_default_" : {
"_all" : {"enabled" : true, "omit_norms" : true},
Copy link

Choose a reason for hiding this comment

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

Should we keep disabling norms? With the new syntax, this would be "_all" : {"norms" : false}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If I recall correctly, when I tested a new 5.0 compatible template (rather than just hoping the existing template would be adapted on the fly) it didn't work with "norms" : false. I got some error or other.

Copy link

Choose a reason for hiding this comment

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

Hmm this must be a bug. :( I just tried locally and it worked for me, do you have steps that I can follow to reproduce?

@jpountz
Copy link

jpountz commented Mar 23, 2016

This looks great.

@pickypg
Copy link
Contributor

pickypg commented Mar 24, 2016

I like that it no longer has the boilerplate dynamic templates for the base types, as it's effectively implied (including with doc values) starting in 2.x. Now that this requires 5.0, it makes total sense!

@untergeek
Copy link
Contributor Author

We are going to re-do this with an improved version of the current template that will be backward compatible. @jpountz has done some awesome things that will automagically translate old templates into new mappings. We will still prune the old "helper" mappings for building your own numeric types, and since doc_values is default, we'll remove the hard-mappings there as well.

@untergeek
Copy link
Contributor Author

I PUT the template to the 5.0.0 alpha RC1 release and inserted a single document:

curl -XPUT localhost:9200/logstash-2016.03.30/logs/1 -d '
> { "@timestamp" : "2016-03-30T17:45:00.000Z", "message" : "This is a message field" }
> '
{"_index":"logstash-2016.03.30","_type":"logs","_id":"1","_version":1,"_shards":{"total":2,"successful":1,"failed":0},"created":true}

When I pulled the mapping, this is what I see:

{
  "logstash-2016.03.30" : {
    "mappings" : {
      "logs" : {
        "_all" : {
          "enabled" : true,
          "norms" : false
        },
        "dynamic_templates" : [ {
          "message_field" : {
            "match" : "message",
            "match_mapping_type" : "string",
            "mapping" : {
              "fielddata" : {
                "format" : "disabled"
              },
              "index" : "analyzed",
              "omit_norms" : true,
              "type" : "string"
            }
          }
        }, {
          "string_fields" : {
            "match" : "*",
            "match_mapping_type" : "string",
            "mapping" : {
              "fielddata" : {
                "format" : "disabled"
              },
              "fields" : {
                "raw" : {
                  "ignore_above" : 256,
                  "index" : "not_analyzed",
                  "type" : "string"
                }
              },
              "index" : "analyzed",
              "omit_norms" : true,
              "type" : "string"
            }
          }
        } ],
        "properties" : {
          "@timestamp" : {
            "type" : "date",
            "format" : "strict_date_optional_time||epoch_millis"
          },
          "@version" : {
            "type" : "keyword"
          },
          "geoip" : {
            "dynamic" : "true",
            "properties" : {
              "ip" : {
                "type" : "ip"
              },
              "latitude" : {
                "type" : "float"
              },
              "location" : {
                "type" : "geo_point"
              },
              "longitude" : {
                "type" : "float"
              }
            }
          },
          "message" : {
            "type" : "text",
            "norms" : false,
            "fielddata" : false
          }
        }
      },
      "_default_" : {
        "_all" : {
          "enabled" : true,
          "norms" : false
        },
        "dynamic_templates" : [ {
          "message_field" : {
            "match" : "message",
            "match_mapping_type" : "string",
            "mapping" : {
              "fielddata" : {
                "format" : "disabled"
              },
              "index" : "analyzed",
              "omit_norms" : true,
              "type" : "string"
            }
          }
        }, {
          "string_fields" : {
            "match" : "*",
            "match_mapping_type" : "string",
            "mapping" : {
              "fielddata" : {
                "format" : "disabled"
              },
              "fields" : {
                "raw" : {
                  "ignore_above" : 256,
                  "index" : "not_analyzed",
                  "type" : "string"
                }
              },
              "index" : "analyzed",
              "omit_norms" : true,
              "type" : "string"
            }
          }
        } ],
        "properties" : {
          "@timestamp" : {
            "type" : "date",
            "format" : "strict_date_optional_time||epoch_millis"
          },
          "@version" : {
            "type" : "keyword"
          },
          "geoip" : {
            "dynamic" : "true",
            "properties" : {
              "ip" : {
                "type" : "ip"
              },
              "latitude" : {
                "type" : "float"
              },
              "location" : {
                "type" : "geo_point"
              },
              "longitude" : {
                "type" : "float"
              }
            }
          }
        }
      }
    }
  }
}

@suyograo
Copy link
Contributor

LGTM

@suyograo
Copy link
Contributor

@untergeek copied this to #402 caused i had a lot of merge conflicts.

@untergeek
Copy link
Contributor Author

Closing this in favor of #402 then.

@untergeek untergeek closed this Mar 30, 2016
@untergeek untergeek deleted the feature/386 branch March 30, 2016 18:20
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.

Mapping changes in Elasticsearch 5.0 for string field type
5 participants