pranavgupta1234
commented
5 years ago After giving a bit more thought about this issue I think just before invoking worker threads for doing compilation, inside load_target_inventory(...) where we are currently doing two step validation :
- valid_target_obj : for validation of basic compile structure
- validate_matching_target_name
Now we can add one more step which includes validation of our currently supported types or just modify the schema of inside valid_target_obj to put the necessary constraint. Just a sample draft for above change https://github.com/deepmind/kapitan/pull/285
Currently the schema for validation of inventory structure does not incorporate constraint on output_type, instead they are handled at compilation phase. I think if we incorporate this at schema level then the error can be shown much before and this can make Kapitan more responsive and fast.
I have the modified schema ready for this which will put constraint on output_type to be only yaml or json(in case input_type is jsonnet or kadet) and allow all output_type for jinja2(it doesn't matter if one specifies it in current implemetation as well).
By looking, it seems like current schema is defined on abstraction for validation of basic structure only and not for any specific type of key that's why I am not sure about making this change or not.