What RDO Blackberries Are and Why They Matter
RDO blackberries refer to packages, tests, or integration work in the RDO ecosystem that are not yet released but are under active development. In this evergreen explainer, you will learn what RDO is, how blackberries fit into Red Hat’s upstream first, downstream release model, and how teams use them to test future OpenStack capabilities. You will also see concrete examples of what to expect, how to follow progress, and how to decide whether to use blackberries in lab or production environments.
How RDO and OpenStack Releases Work Together
RDO is a community-driven project that delivers OpenStack operating system distributions for Red Hat Enterprise Linux (RHEL). It follows Red Hat’s upstream first policy, consuming OpenStack source releases and packaging them for RHEL, with predictable release cadences that align with vendor and customer needs. The stack includes OpenStack components, supporting middleware, and tooling such as Packstack, TripleO, and overcloud deployment workflows. RDO packages are maintained in the CentOS OpenStack Storage (RDO) SIG and related build systems, which coordinate with the broader OpenStack Release Project.
Release Trains and Milestones
OpenStack operates a six-month release train with well-defined milestones for each cycle. RDO tracks these milestones to time packaging, testing, and integration. Each release train defines branch names, freeze dates, and feature goals. Because blackberries target future trains, they sit ahead of the current stable branch in the git repository and are not published to standard repositories.
Packaging and Integration Mechanics
Packages in RDO are built from upstream source tarballs with minimal, well justified patches. The build pipeline runs through CentOS CI, Koji, and sometimes a dedicated proposed-updates repository before promotion to the main RDO repository. Blackberries represent packages that have been built but not yet promoted. They may include new OpenStack services, API changes, or supporting library updates that depend on newer versions of Python, QEMU, or other base components.
What Blackberries Represent in RDO
In RDO terminology, blackberries are candidate artifacts for the next release train that are under active evaluation. They are effectively a staging area for packages that might ship in an upcoming OpenStack release, provided they pass quality, compatibility, and security gates. Because these artifacts are not intended for production use, they are published separately and often require explicit enabling or manual installation.
Blackberries vs Stable and Proposed-Updates
- Stable: Released, tested packages in the standard RDO repositories that receive only critical updates.
- Proposed-updates: Packages that have passed most checks and may land in the next minor update for the current train.
- Blackberries: Packages aimed at the next major release train, higher risk, more likely to contain regressions or API changes.
Typical Contents and Examples
Blackberries commonly include new OpenStack services, major library bumps, or changes that depend on other components not yet in stable repositories. For example, an upcoming cycle might introduce a new networking driver, a revised messaging schema, or an updated Python requirement that conflicts with packages in the stable tree. Because these changes can affect many other packages, blackberries are tested in isolated environments before any consideration for promotion.
How to Follow Blackberry Progress
To stay informed, track RDO SIG meetings, mailing list discussions, and the project’s GitLab and Pagure repositories. The RDO releases repository, CI dashboards, and proposed-updates branches provide visibility into when blackberries are built, which components they touch, and whether they advance to proposed-updates or remain experimental. Issues and merge requests in upstream OpenStack projects are also strong signals about what may appear in blackberries.
Key Signals and Milestones
| Milestone or Artifact | What It Indicates | Source Type |
|---|---|---|
| New OpenStack X.Y release tarball upstream | Foundation for next RDO blackberry builds | Upstream Release |
| Blackberry builds in RDO CI | Artifacts built but not yet promoted | CI Pipeline |
| Pass of gate checks (unit, tempest, multinode) | Potential progression to proposed-updates | Test Results |
| Landing in stable repository | Blackberry promoted to supported release | Repository Promotion |
Risks, Limitations, and Operational Guidance
Blackberries are by definition unstable and should not be used in production. Risks include API incompatibilities, performance regressions, missing dependencies, and interactions with other packages that are not part of the blackberry set. If you need to evaluate new features early, use isolated lab environments, containers, or virtual machines, and avoid mixing blackberry packages with stable repository configurations. Keep backups and rollback plans, and clearly document any deviations from supported configurations.
When to Consider Blackberries
- Feature evaluation: Validate new capabilities against your workloads in a controlled lab.
- Upstream collaboration: Test compatibility and provide feedback to OpenStack and RDO maintainers.
- Migration planning: Begin preparing application and automation changes for future releases.
Do not enable blackberry repositories on systems that require stability, compliance certifications, or predictable patching. Treat blackberries as experimental artifacts that may be removed or replaced without notice.
Interactions With Other RDO Components
Because RDO packages are interdependent, a blackberry in one component can require changes in others. Dependency chains involving libraries, messaging protocols, and driver interfaces mean that blackberries often come with a set of companion packages. Tools like ttripleo, openstack-ansible, and RDO’s modular repositories help manage these relationships, but users must still resolve conflicts manually when mixing sources. Understanding how packages reference one another helps you anticipate integration issues and design safe test strategies.
Managing Dependencies
When testing blackberries, isolate them using dedicated branch configurations, containerized deployments, or separate overcloud stacks. Prefer automation that pins exact package versions and records the enabling repositories. This approach reduces drift and makes it easier to discard experimental environments without affecting stable infrastructure.
Decision Criteria and Alternatives
Deciding whether to use RDO blackberries depends on your risk tolerance, timeline, and operational constraints. If you need the latest features and can tolerate instability, controlled early adoption in labs can be valuable. If stability, compliance, or predictable patching is required, wait for packages to land in proposed-updates or stable repositories. Alternatives include following upstream development without installing blackberries, participating in testing programs, and relying on vendor roadmaps for feature timelines.
Quick Comparison
| Option | Risk Level | When to Use | Support Status |
|---|---|---|---|
| Blackberries | High | Feature evaluation, upstream feedback | Best effort, no SLA |
| Proposed-updates | Medium | Next patch release, early adopters | Limited support |
| Stable | Low | Production workloads | Full support |
Conclusion and Best Practices
RDO blackberries are experimental packages aimed at the next OpenStack release train. They enable early evaluation and upstream collaboration but carry significant risk and no support guarantees. Use them only in isolated environments, track upstream and CI signals carefully, and prefer stable or proposed-updates artifacts for production. By understanding how blackberries fit into the RDO release model and following disciplined testing and rollback practices, you can explore new capabilities while minimizing operational impact.