[openstack-dev] Configuration Options, APIs, Class Paths, Oh my!

Eric Windisch eric at cloudscaling.com
Wed Oct 31 14:16:56 UTC 2012


> 
> So that's the problem. You are expecting these APIs to be stable, at
> least within a release. We are doing absolutely nothing to ensure that
> is the case right now. The fact that these config options were there
> gave you that expectation, which is unfortunate, and I'd like to fix it.
> 
Forking is such a better option?  Stability of the API is secondary to its availability.

Once a stable release is made, I don't expect significant changes due to the general contract of what 'stable' implies. However, I don't expect there won't be a change, either. If this needs to be documented and clarified, fine.

As for Cloudscaling, we've run our own custom schedulers, networking code, and queuing/rpc mechanism through Nova's *_backend options. This has allowed us to address deficits in the stable releases within the context of our customer deployments. Many of those improvements were then rolled into the next-stable release.

For instance, a number of scheduler improvements we had been running in-house against Essex were eliminated through the release of general host aggregates and aggregate-based scheduling.  Of course, we're also using the ZeroMQ driver, which we rolled-out as a plugin against stable for Essex, prior to being merged into Folsom.

My design intention for the matchmaker, which the ServiceGroup API might prove to eliminate, was to have it pluggable so that lookups of hosts could be offloaded. One reason for this was that what we could scope in the Essex timeframe would not include dynamic host memberships (something the ServiceGroup API promises).  The thought being, that if it were pluggable, we could extend upon it in Folsom as a new feature and backport the changes as a plugin.

Even with the ServiceGroup API, there are backends that people will want to develop or backport out of H into Grizzly. I don't expect this code to mature enough within Grizzly that this won't happen.

Additionally, my plan for secure messaging will be to have it be extensible.  In particular, a pluggable keyserver component will be available, so users will be able to public key and CRL lookups against various backends. It is a design goal that the community and vendors can plugin here. There are many keyserver solutions and I don't want to dictate this to the users. Can these go upstream? Sure, for the most part, if not entirely.  However, with the rapid development cycle of OpenStack, we'll cut stable with pluggable backends and /THEN/ the backends will trickle into H and as plugins to then-stable Grizzly.

You'll notice that I'm not generally advocating long-lived cross-release plugins. Most (but not all) of our out-of-branch code is for a single stable release. Then, such code is no longer needed because of improvements subsequently made in trunk and merged into the next stable release.

The code that does cross releases does need to get updated and these changes are not necessarily minor, and yes these modules sometimes break within a release. It has happened. We're kind of okay with it. Might we be happier if it didn't break? Sure, but we'd be much less happy if we couldn't plugin at all.

I suggest it might be useful if thread were cross-posted to the operators/users list.

Regards,
Eric Windisch





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121031/59f45981/attachment.html>


More information about the OpenStack-dev mailing list