Change to how we manage schemas
As mentioned a while back, as part of the switch to Ubuntu we will be changing how the LCFG component schemas are managed. We’re now in the process of testing this change. Currently the aim is that we will switch to the new approach at the end of July. Here are the full details…
Currently, the schemas are stored in the source code repository alongside the component code. They are shipped to the LCFG master in a separate sub-package named like lcfg-foo-defaults-s1 with versions controlled by the lcfg/lcfg-defaults.rpms and dice/dice_defaults.rpms package lists. The complete set of schemas is then rsync’ed to the LCFG slaves. This means that a profile uses the same schema file for a component no matter what release (e.g. stable or develop) that it is following.
This approach is difficult on Ubuntu since we can’t easily auto-generate the specific package names that are required (e.g. by appending s1, s2, etc). It also always causes difficulties with porting to new platforms, you end up needing to port all the component packages so that the schemas are available for an updated LCFG master, even if the component is no longer needed on that platform (for example, when we switched from lcfg-boot to lcfg-systemd between SL6 and SL7).
The plan is to change to storing the schemas in the configuration repository alongside the ‘include’ and ‘packages’ directories. There is a new ‘schema’ directory which has sub-directories for lcfg and dice components. This is all release-managed which means that profiles on different releases may see different versions of a schema, i.e. foo-1.def may differ between develop and stable releases without the schema-version changing. For minor tweaks this should make the development and testing process much easier, you can make changes and safely test them on develop without affecting stable profiles. It doesn’t do away with the need for schema-versions though, they are still really useful when making major changes to the resources. I feel it’s also helpful that the schemas will change in-step with the headers, as soon as you have update a schema you can use it in the headers, knowing that it will be in place. Previously we had to update the schema first then change the headers in a subsequent release cycle. Schema changes will also get better oversight as they will be easy to review as part of the weekly release notes.
Will the update of component and schema be truly atomic? eg if I ship an updated component that uses new resource X, and the corresponding updated def file, and in a header make set that resource. At the stable compile time will it all just work? The lcfg server doesn’t need to get its profile first?
The schemas will become part of the release process. The new release is completely synchronised into place before the processing of profiles begins so it will be safe.