The one place for your designs
To enable design management, you'll need to meet the requirements. If you need help, reach out to our support team for assistance.
Schema versioning
Everything dealing with parameters in the current validate functions is checking for a structure to exist inside those parameters and then reading from that endpoint. All parameters are static. Therefore, all such checks can move into classmethods which the validate method then can call if wanted. The classmethods’ actual purpose is a new top level call on job submission to check that the passed parameters are all valid. All such parameters come direct from the job submission allowing for multinode split etc. to happen first.
Current validate functions combine the checks of static parameter data with the generation of dynamic data which often combines the job parameters, device parameters and other dynamic data into useful constructs for the job at runtime. If the checks of static parameters from the job submission were moved into classmethods, then the validate could also use those methods to build the dynamic data as it does currently. The validate function does not need to have so many conditionals to check for particular structures in the parameters: it simply accesses those structures. The parser would take care of whether the structural elements are valid for the constructed pipeline and the same parsing could be used to document that structure. The structure created from the classmethods is an outline of the fully initialised pipeline, but accesses the same classes in the same sequence. This will require changes in the populate functions.
Need a schema-version field in the YAML submission format and ensure that this is Required in the YAML.
No support for conversion on the fly at this stage or supporting versions below the minimum requirement.
Add a changelog for the schema and a link to the documentation on the changes to the current version.
Each jinja2 template specifies a minimum schema version, including base.jinja for changes which affect multiple templates. The submission API calculates the highest schema version requirement for each individual submission and asserts that the submitted YAML must match or exceed this value.
Migrated from https://projects.linaro.org/browse/LAVA-657 and https://projects.linaro.org/browse/LAVA-709