# OpenAPI Community Meeting Scratchpad ## Flags ```bash # current flags ytt --files-inspect # prints involved files ytt --data-values-inspect # prints values files ytt --data-values-inspect -ojson # prints values as json # New flags ytt --data-values-schema-inspect # prints ytt schema (as ytt schema with annotations) ytt --data-values-schema-inspect -o openapi # prints data values schema in openapi format ytt --data-values-schema-inspect -o openapi-full # prints data values schema in openapi format with headers ``` Other flags that were considered: ```bash ytt --data-values-schema-inspect -o openapi # prints data values schema in openapi format ytt --data-values-schema-inspect -o openapi-schema # prints data values schema in openapi format with headers ytt --data-values-inspect -o openapi ytt --data-values-schema-inspect -o openapi ytt --data-values-schema-inspect -o openapiv3 ytt --schema-inspect-openapi # prints data values schema in openapi format ytt --schema-inspect-openapi-metadata # prints data values schema in openapi format with headers ytt --schema-generate-openapi # prints data values schema in openapi format ytt --schema-openapi-create ytt --schema-create-openapi ytt --data-values-schema-generate-openapi ``` ## OpenAPI headers & Inserting an OpenAPI Schema into a kapp-controller Package CR Using the OpenAPI Schema **with headers**: Pros: - Better documentation - kubectl api returns a Document k get --raw /openapi/v2|ytt -f- - Industry tools use OpenAPI Document with headers (helm's [jsonschema](https://helm.sh/docs/topics/charts/#schema-files), and Cue) - command to subsitute it into Package is simplier. - `ytt -f package.yml --data-values-file openapi.yml` - vs: `ytt -f package.yml --data-value-file openapiSchema=openapi.yml` and must `yaml.decode` inside template. Cons: - Need a way to set `info.version` of the document - Unsure if users actually need headers - More stuff in the file - More difficult for people who may not use ytt to insert the `components.schemas` into another document ## Data Values Schema only vs. Data Values Schema **and** Data Values Using Data Values Schema only: Pros: - we recommend that configuration authors only supply a Data Values Schema and should not also need a Data Values file. - implementation is simpler since the schema and the data values are calculated in two different places - Smaller surface area of feature since it only applies to one file type - `--data-values-inspect` already merges Data Values Schema and Data Values together, having a separate command that only considers data value schemas would mean less overlap Cons: - The output of the OpenAPI document doesn't necessarily tell you what values will be used (if you have a data values file too) how do we infer schema from any input? Data values overlays from flags `ytt -f data-vals-schema --data-values-env --data-values-schema-inspect -o openapi.`