With Pulp 1.0 a few weeks old now, I wanted to send out an update on the next steps for the project.

Version 1.0.x

Our recent work on the v1 stream has been bug fixes for a related project in Red Hat (Katello). Our current (internal-only for now) v1 release is 1.0.2 and contains about a dozen bug fixes. The current plan is to move that into the v1/stable repository sometime next week. More information, including a list of bug fixes, coming in the next few days.

Version 1.1

This may or may not even exist :)

The original thought was that we’d be a few months out from being able to do a version 2.0 release and would probably want to do an interim release with critical bug fixes. That role seems to have been filled with the 1.0.x builds. As a team we’re not exactly swimming in free time, so it’s possible that we may push forward to get version 2.0 in an alpha state and skip 1.1 entirely. We should have a clearer idea of this in the next few weeks as Katello gets closer to a release.

Version 2.0

Not surprisingly, our big push as a team is to get the 2.0 release to a usable state as quickly as possible. It’s been talked about on this site before but never as an overall checklist of features and goals. Now that 1.0 is out and in use, it makes sense to start to look to what’s coming in 2.0.

  • New architecture to allow for user-defined content types to be managed.
  • Plugin-based architecture allows content synchronization from non-yum external sources. Plugins are able to leverage Pulp’s platform capabilities such as concurrency management, sync scheduling, permissions, and more.
  • A more clear distinction between external content synchronization and the publishing of that content from the Pulp server. As with sync, the architecture revolves around a plugin model which allows new publishing mechanisms to be easily added to the platform.
  • Revamped concurrency layer to ensure safety across multiple requests through postponing or outright rejecting conflicting requests.
  • Closer adherence to REST practices including the proper usage of HTTP response codes and consistent data and format for exception conditions.
  • Rewritten client using an extension mechanism to easily add new commands by leveraging the client’s pre-configured server bindings. Not happy with Pulp client output? In 5 minutes you can write a new extension that formats the data however you see fit.

The above list is already implemented, just not quite in a totally clean state yet. The following are planned changes for version 2.0 but obviously may change over the next few months:

  • Separation of the server->consumer communications, allowing the existing consumer agent infrastructure to be used outside of Pulp for custom needs.
  • Revamped CDS functionality. There are a lot of ideas here, many revolving around allowing the CDS to function as more than a simple repository mirror. One such ability is to act as a proxy to the Pulp server in the case of large geographic differences between server and consumers or firewall and security considerations.