# Resolving deprecation warnings to allow us to upgrade **URL:** \ **Category:** Elasticsearch\ **Created:** [April 23, 2019, 12:07pm UTC](https://discuss.elastic.co/t/resolving-deprecation-warnings-to-allow-us-to-upgrade/178038 "2019-04-23T12:07:58Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![cowensel](https://avatars.discourse-cdn.com/v4/letter/c/eb9ed0/32.png) [@cowensel](https://discuss.elastic.co/u/cowensel)\ **Post date:** [April 23, 2019, 12:07pm UTC](https://discuss.elastic.co/t/resolving-deprecation-warnings-to-allow-us-to-upgrade/178038/1 "2019-04-23T12:07:58Z")
I am currently going through the Elasticsearch deprecation logs to check what we may need to resolve prior to upgrading our ELK Stack from v6.0.0 where I have found the following but have no clue how to resolve. `[o.e.d.a.a.i.t.p.PutIndexTemplateRequest] Deprecated field [template] used, replaced by [index_patterns]` `Deprecated field [inline] used, expected [source] instead` `[_default_] mapping is deprecated since it is not useful anymore now that indexes cannot have more than one type` `Fielddata access on the _uid field is deprecated, use _id instead` Looking at the fields \_id is currently being used. Index\_patterns is displayed when doing GET \_template Inline is also not being used We have not set a custom template in logstash it uses its default. Can anyone shed any light? ---
**Author:** ![elasticforme](https://avatars.discourse-cdn.com/v4/letter/e/f05b48/32.png) [@elasticforme](https://discuss.elastic.co/u/elasticforme)\ **Post date:** [April 23, 2019, 6:42pm UTC](https://discuss.elastic.co/t/resolving-deprecation-warnings-to-allow-us-to-upgrade/178038/2 "2019-04-23T18:42:39Z")
I have same problem but no answer that I found when I posted. then I got side track Deprecated field [template] used, replaced by [index\_patterns] I can't seems to find what and where this is used and how do I fix. ---
**Author:** ![cowensel](https://avatars.discourse-cdn.com/v4/letter/c/eb9ed0/32.png) [@cowensel](https://discuss.elastic.co/u/cowensel)\ **Post date:** [April 24, 2019, 9:46am UTC](https://discuss.elastic.co/t/resolving-deprecation-warnings-to-allow-us-to-upgrade/178038/3 "2019-04-24T09:46:57Z")
Interestingly I have spun up another ELK node with the same version (v6.0.0) where I got the same errors as my original comment. I proceeded with the upgrade to v6.7.1 on the test ELK node to see if any errors cleared and I am only seeing `[2019-04-24T08:53:16,101][WARN][o.e.d.i.m.MapperService] [HOSTNAME] [_default_] mapping is deprecated since it is not useful anymore now that indexes cannot have more than one type` `> [2019-04-24T08:01:32,614][WARN][o.e.d.r.a.a.i.RestGetMappingAction] [HOSTNAME] [types removal] The parameter include_type_name should be explicitly specified in get mapping requests to prepare for 7.0. In 7.0 include_type_name will default to 'false', which means responses will omit the type name in mapping definitions.` The question is now 'How do I resolve the include\_type\_name error and the _default_ mapping error? ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [April 24, 2019, 10:18am UTC](https://discuss.elastic.co/t/resolving-deprecation-warnings-to-allow-us-to-upgrade/178038/4 "2019-04-24T10:18:07Z")
You can resolve the `[_default_] mapping` warning by removing all usages of this feature from your index mappings and index templates. You can resolve the `include_type_name` thing by passing `include_type_name=false` along with any [get mapping](https://www.elastic.co/guide/en/elasticsearch/reference/6.7/indices-get-mapping.html) requests. ---
**Author:** ![cowensel](https://avatars.discourse-cdn.com/v4/letter/c/eb9ed0/32.png) [@cowensel](https://discuss.elastic.co/u/cowensel)\ **Post date:** [April 24, 2019, 11:26am UTC](https://discuss.elastic.co/t/resolving-deprecation-warnings-to-allow-us-to-upgrade/178038/5 "2019-04-24T11:26:40Z")
Hi David, We do not specify a specific mapping we use the default logstash mapping. How do we remove the `> [_default_] mapping` from being referenced in the output to elasticsearch same with the include\_type\_name ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [April 24, 2019, 11:37am UTC](https://discuss.elastic.co/t/resolving-deprecation-warnings-to-allow-us-to-upgrade/178038/6 "2019-04-24T11:37:16Z")
I'm pretty sure that the warning about the `[_default_]` mapping indicates that there's an index or an index template that's still using it. It might be a template installed by Logstash, of course. If so, I'm not sure how best to go about removing it but you could try asking in the [Logstash forum](https://discuss.elastic.co/c/logstash) about that. > [@cowensel](#): > > same with the include\_type\_name As I said above, to avoid that warning any get mapping request needs `include_type_name=false` [as per the docs](https://www.elastic.co/guide/en/elasticsearch/reference/6.7/indices-get-mapping.html). ---
**Author:** ![elasticforme](https://avatars.discourse-cdn.com/v4/letter/e/f05b48/32.png) [@elasticforme](https://discuss.elastic.co/u/elasticforme)\ **Post date:** [May 1, 2019, 7:58pm UTC](https://discuss.elastic.co/t/resolving-deprecation-warnings-to-allow-us-to-upgrade/178038/7 "2019-05-01T19:58:38Z")
Just upgraded my cluster to 6.7.1 and found exactly which template was putting error. I wasn't using that index anymore so it was easy for me and remove it GET /\_template/ DELETE /\_template/ ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [May 29, 2019, 7:58pm UTC](https://discuss.elastic.co/t/resolving-deprecation-warnings-to-allow-us-to-upgrade/178038/8 "2019-05-29T19:58:53Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.