This message was deleted.
# general
s
This message was deleted.
a
are you able to change it through UI?
c
yes but that is not the way we would like to do manual way. we would like to automate it setting it via api requests
but let me double check again to set them via UI now
quickly
a
if you are able to do it console, you can look what request is console issueing. then compare it with the curl command that you are running
console is doing an API request too
c
yeah, how can I check the curl command UI issues?
a
through developer tools in chrome
c
alright gonna check that. and any idea on why our requests seem in history section?
ups, just tried again but setting it in UI manually also does not work. after I set, it says it successfully set but then I see no retention policy set
a
it's possible that the retention policy isn't correct. you should check the coordinator logs.
s
I think @Abhishek Agarwal is correct the format for the rules you have should be:
Copy code
[
  { 
    "type":"dropBeforeByPeriod",  
    "period":"P4M",
    "tieredReplicants":{
      "hot":2,
      "_default_tier":2
     },
  },
  { "type":"loadForever" } 
]
That said, the rule seem a bit odd. It will process the first rule that matches each segment in consideration and processes the rules in order. If you are trying to only hold 4 months of data, a more straightforward set of rules would look like:
Copy code
[
  { 
    "type":"loadByPeriod",  
    "period":"P4M",
    "tieredReplicants":{
      "hot":2,
      "_default_tier":2
     },
  },
  { "type":"dropForever" } 
]
In this way, newly ingested segments with new timestamps will have 2 copies in hot and 2 copies in __default_tier._ When the segments age is more than 4 months, the segments will be dropped.
c
Hey @Sergio Ferragut, Thank you so much for your reply. My problem is more no matter what retention policy I apply, it just does not set even though it gives me success statu after API request.
That was just an example actually. And I tested it before, it was working I was able to see only segments in last 4 month
but then something happened and now I cant set any of the rules
it keeps going to history section , rather than actually setting it
g
I just checked the code for this and the only scenario I see where the history would be updated, but the actual rules would not be updated, is if your clock somehow went backwards (The rules with the latest timestamp are the ones that are active, and if your clock goes backwards, it's possible that the latest timestamp corresponds to an earlier set of rules.)
Is it possible this is the case you're in?
You could check the
druid_rules
table in your metadata store, as well, to see what's in there and verify it makes sense
a
I recently learned that somehow druid_rules can have entries that have
null
payload. do you see something like that in your
druid_rules
table in the metadata store?
if you called the API to set retention rules with an empty payload, then your cluster can end up in a bad state.