Tldr: In the coming weeks, configuration for puff will transition to being managed on a per-project basis with the goal of enabling autonomous and flexible partner contributions and clearer API boundaries. This is an initial announcement of the upcoming migration, another announcement will be made before the migration CL is submitted. We will receive acknowledgement from key stakeholders before submitting the migration CL.

Starlark will be used to generate Protocol Buffer configuration payloads in puff config repos (program) and model.yaml will be deleted from overlay-puff-private. A few resources to get started:

• Starlark language guide: Starlark is a Python-like configuration-management language, this guide gives a quick introduction.
• chromiumos/config README: Steps for partners and Googlers to check out their repos and contribute changes.
• fake test data project: Working example of the new config ecosystem.

Changes will be made in the following repos:

• puff program repo: Contains Starlark files, generated protobuf payloads, and backwards-compatible JSON payloads.
• overlay-puff-private: chromeos-config-bsp ebuild sets CROS_WORKON_PROJECT to new puff repos (program). model.yaml is deleted.

Why are we doing this migration?

A few benefits:

• Clearer API boundaries to manage builds and hardware.
• Enable autonomous partner config contributions, enforced via CQ coverage.
• Allow partners to develop proprietary features without leaking IP.
• Final generated config payloads are checked in allowing for clear behavior and diffing.
• Improved analytics on hardware and software characteristics.

Will I need to change my ChromeOS platform code?

No. For the time being, the protobuf payloads will be translated backwards into JSON payloads conforming to cros_config_schema.yaml. From the platform point-of-view, the configuration will not change.

Will this break my builds?

No. During the migration, we will ensure that configuration generated by the new repos is the same as the configuration generated by model.yaml. Standard CQ coverage will apply to the migration CLs and stakeholders will be added as reviewers. Migration will be done in a single submission that can be reverted.

How will I cherry pick changes to branches?

If your project has not yet created branches, you will only need to cherry pick changes to the generated payloads in the new config repos. If your project has created branches, you will need to cherry pick the ebuild change to read the new config repos as well. The Boxster team will be available to assist in the cherry pick process.

We understand that getting used to the new configuration management ecosystem may take some time, and are committed to providing the best experience possible for partners and Googlers.