Support multiple levels of config validation

[icefury71]

Ideally, we wish to have levels of validation such as:

• strict
• basic (default)

In this case, strict validation will imply all the stringent checks are done (eg: #6644, #6300 ). basic might be closer to what we're doing today to allow for backwards compatibility of table and schema configs.

CC @mcvsubbu @mayankshriv

[mcvsubbu]

A nice way of doing this (from user standpoint) is to start with validation set to level 0. Each time you add new validations, bump it up by 1. Let folks set the validation level to whatever they want.

Now, this may not look very good in the code, but then we cannot keep making incompatible changes forever. Recent validation checks have already cost us a lot of Engineering hours in terms of moving with a release and then back-tracking stuff.

[icefury71]

I feel if we leave the validation levels unbounded - the validation code will be rendered unreadable. I prefer to keep it to a few levels only (eg: strict, medium, basic). We can be judicious in what validation belongs to which of these 3 buckets.

[mcvsubbu]

Perhaps so, but we need to stop making incompatible changes at some point. The cost of retrofitting all tables to conditions that are not really applicable to that setup is just too much.

[Jackie-Jiang]

Shall we list down all the validations we have now? I feel all (or at least most) of them are must have for pinot to properly work

[mcvsubbu]

Shall we list down all the validations we have now? I feel all (or at least most) of them are must have for pinot to properly work

Lol! Pinot has been working for years now :)

[mcvsubbu]

Perhaps we should list all the checks that we WANT to perform, and then make sure that they get done in one go, so that we can have one (maybe two) levels of validation. This thing of doing part by part costs a lot in eng hours if a test fails some use case.

[Jackie-Jiang]

@mcvsubbu Several validations we added recently are for new features. E.g. Text and json index only works on string columns; upsert does not work with star-tree index; star-tree index won't work with MV columns etc. By saying must have, I mean if the config fails the validation, the table won't work as expected.
We should list down all the validations, and mark them either must follow or suggested but still work