Any views expressed within media held on this service are those of the contributors, should not be taken as approved or endorsed by the University, and do not necessarily reflect the views of the University in respect of any particular issue.

LCFG Project

LCFG Project

Recent Activity for the LCFG project

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.

2 replies to “Change to how we manage schemas”

  1. neilb says:

    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?

  2. squinney says:

    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.

Leave a reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>


Report this page

To report inappropriate content on this page, please use the form below. Upon receiving your report, we will be in touch as per the Take Down Policy of the service.

Please note that personal data collected through this form is used and stored for the purposes of processing this report and communication with you.

If you are unable to report a concern about content via this form please contact the Service Owner.

Please enter an email address you wish to be contacted on. Please describe the unacceptable content in sufficient detail to allow us to locate it, and why you consider it to be unacceptable.
By submitting this report, you accept that it is accurate and that fraudulent or nuisance complaints may result in action by the University.