[13:59:55] <cdanis>	 marostegui: do you have any preferences on the question at https://gerrit.wikimedia.org/r/c/operations/software/conftool/+/534819/3/conftool/extensions/dbconfig/__init__.py#46
[14:03:11] <jynus>	 I would agree with joe, but I don't see is as a huge isse
[14:03:33] <cdanis>	 ok, is an easy change to make
[14:03:48] <jynus>	 I think it is ok to have true/false when there is a change it may be multi-valued in the future
[14:04:27] <jynus>	 also it may make sense if it is similar to other endpoints
[14:04:48] <jynus>	 I do not feel strongly in any case
[14:04:57] <cdanis>	 set-foo/unset-foo are more like pool/depool
[14:22:28] <cdanis>	 jynus: would we ever (even hypothetically) have multiple candidate masters for a given section?
[14:23:53] <jynus>	 very improvable in my opinion, I think if the master was down and the candidate was also down, we would revert to an operator decision
[14:23:59] <jynus>	 or
[14:24:09] <jynus>	 "choose among the ones left"
[14:24:35] <jynus>	 I think techinically it could make sense to have some kind of tier list
[14:24:53] <jynus>	 in 5+ years time?
[14:24:57] <cdanis>	 heh heh
[14:25:56] <jynus>	 if you wanted to work more and future-proof things
[14:26:32] <jynus>	 I would see some arbrtrary tags as useful #candidate #unreliable etc
[14:26:58] <cdanis>	 tags are an interesting thought
[14:27:02] <jynus>	 but there are way more important things first
[14:27:10] <cdanis>	 agreed
[14:28:09] <jynus>	 what should be supported is to have 0 candidates
[14:28:16] <jynus>	 e.g. after a switchover
[14:28:31] <jynus>	 (reduced redundancy)