while thinking over the openQA design, I realized it's a bit weird that 'flavors' don't exist as formal db objects with associated settings, like 'machines' do. We have quite a few cases where we have multiple products for the same flavor but different arches, and all or most of the settings are the same. it might be an optimization for fifloader to allow flavors to be defined in the data with associated settings, to cut down on repetition. this would be an fifloader-invented top level item type, like Profiles are.

Products would inherit all settings of their associated flavor, but still have their own settings if necessary, and if a setting is defined at both Flavor and Product level, product wins.