Date math in index name error in 8.1.3

Per the doc, I'm trying to create an index with the date in it's name:

PUT /%3Call-dns-%7Bnow%2Fd%7D%-0000013E?pretty
{
  "aliases": {
    "all-dns": {
      "is_write_index": true
    }
  }
}

But I'm getting this error:

{
"error" : "Incorrect HTTP method for uri [/%3Call-dns-%7Bnow/d%7D%25-0000013E?pretty=&pretty=true] and method [PUT], allowed: [POST]",
"status" : 405
}
Changing the method to POST is no better:

{
  "error" : "no handler found for uri [/%3Call-dns-%7Bnow/d%7D%25-0000013E?pretty=&pretty=true] and method [POST]"
}

This used to work, because I just changed the name in prior commands devtools.

Think you are missing the last % before the 3E

PUT /%3Call-dns-%7Bnow%2Fd%7D-000001%3E?pretty

Still not working, I don't know if I lost the % posting or what, but re-testing:

@rugenl Screen shot BAH! please post the actual text so I can try!

Mine on 8.2.0 (should be same in 8.1.3)

PUT /%3Call-dns-%7Bnow%2Fd%7D-000001%3E?pretty
{
  "aliases": {
    "all-dns": {
      "is_write_index": true
    }
  }
}

response

{
  "acknowledged" : true,
  "shards_acknowledged" : true,
  "index" : "all-dns-2022.05.19-000001"
}

Something weird in your url...

When I purposely use wrong method my url prints this... note no / where yours is

"error" : "Incorrect HTTP method for uri [/%3Call-dns-%7Bnow%2Fd%7D-000001%3E?pretty=&pretty=true]

Stay tuned, same syntax that fails in 8.1.3 works in 7.17.1.

I knew we used this many times before and was pretty sure I started with an example that had worked in the past.

@rugenl

Interesting I reproduced the error in 8.1.3

PUT /%3Call-dns-%7Bnow%2Fd%7D-000001%3E?pretty
{
  "aliases": {
    "all-dns": {
      "is_write_index": true
    }
  }
}

results

{
  "error" : "Incorrect HTTP method for uri [/%3Call-dns-%7Bnow/d%7D-000001%3E?pretty=&pretty=true] and method [PUT], allowed: [POST]",
  "status" : 405
}

Note it has that extra / in it

in 8.2.0 It works fine.. so looks like there is a bug in 8.1.3 that is fixed in 8.2.0

You can certainly create manually with the following syntax or upgrade to 8.2.0

PUT all-dns-2022.05.19-000001?pretty
{
  "aliases": {
    "all-dns": {
      "is_write_index": true
    }
  }
}

Known issue: [Console] Cannot issue request with date-math format · Issue #128701 · elastic/kibana · GitHub

That format is a ILM red herring, all indices will have 2022.05.19, not the current date at rollover.

Good Find on the issue.

Unclear what you mean.

Using the date math {now/d} will put the current date at rollover in the index name at each rollover event. If you use a literal date for the first index, that date will be used in all future indices.

Hmmm I will need to validate for myself as I was not aware of that / not my understanding ... unfortunately to validate I need to wait for a UTC date rollover to trigger the date portion in 20 hours (pretty sure I have manually bootstrapped many indices with the literal... but perhaps I am wrong or something has changed) either way now I have to know :slight_smile: Thanks for pointing out.

It burned me early in ILM, it's been awhile, it's possible it's fixed, but I think it needs the {date/d} in the "provided_name" field in the index to know a date isn't a constant.

1 Like

@rugenl Yes You Are Correct you must use the {now/d} syntax...

So for anyone reading this your date driven rollover must be defined with the correct syntax

In Kibana -> Dev Tools you can use the non encoded syntax (in some versions)

PUT /<my-index-{now/d}-000001>?pretty
{
  "aliases": {
    "my-index-write-alias": {
      "is_write_index": true
    }
  }
}

If you are posting through a REST endpoint you will need to encode

PUT /%3Cmy-index-%7Bnow%2Fd%7D-000001%3E?pretty
{
  "aliases": {
    "my-index-write-alias": {
      "is_write_index": true
    }
  }
}

BTW @rugenl I realized I was thinking of the non date form with the of the beats aliases

PUT /filebeat-7.17.3-000001/?pretty
{
  "aliases": {
    "filebeat-7.17.3: {
      "is_write_index": true
    }
  }
}

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.