Open Stack

On Sep 29, 2014, at 4:22 PM, Robert Collins <robertc at robertcollins.net> wrote:

> On 30 September 2014 03:10, Doug Hellmann <doug at doughellmann.com> wrote:
>> 
>> On Sep 28, 2014, at 5:00 PM, Robert Collins <robertc at robertcollins.net> wrote:
> 
>> As far as I know, the client libraries aren’t being released as alphas. The Oslo libraries are, but they aren’t “public” in the same sense — they’re an internal part of OpenStack, not something a user of a cloud is going to be interacting with. The parts that affect the deployers directly are usually limited to configuration options, and we have a strict deprecation policy for dealing with those, even within the development cycle.
> 
> I'm now really confused. oslo.config for instance - its depended on by
> the client libraries. Our strict backwards compatibility guarantees
> for the clients are going to be transitive across our dependencies,
> no?

I would expect anyone using an experimental feature to be working with us on it, and to avoid releasing something “experimental" into a “stable" release stream. We do that automatically with the server projects because, irrespective of the fact that some people deploy from trunk, we create a formal release of the server and libraries at the end of a development cycle at which point the library’s API is declared stable.

> 
>> We do reserve the right to change APIs for new features being added to the Oslo libraries during a development cycle. Because we want to support CD, and because of the way we gate test, those changes have to be able to roll out in a backwards-compatible way. (THIS is why the incubator is important for API evolution, by the way, because it mean the API of a module can change and not break any updates in any consuming project or CD environment.) Even if we change the way we gate test the libraries, we would still want to allow for backwards-compatibility, but still only within a development cycle. We do not want to support every API variation of every library for all time. If we have to tweak something, we try to get the consuming projects updated within a cycle so the old variation of the new feature can be removed.
> 
> If we are only backwards compatible within a development cycle, we
> can't use the new version of e.g. oslo.db with the stable icehouse API
> servers. That means that distributors can't just distribute oslo.db...
> they have to have very fixed sets of packages lockstepped together,
> which seems unpleasant and fragile. Isn't that what the incubator was
> for: that we release things from it once we're *ready* to do backwards
> compatibility?

We do not want anyone to use development versions of libraries for stable branches, right? We have processes in place to allow us to backport changes to patch releases of libraries, so that bug and security fixes can be released without the features being developed within the cycle. But deployers using stable branches should avoid mixing in development versions of libraries.

As far as the incubator goes, we’ve been baking things there for some time. Much of the code is now ready to graduate, and some of it will require API changes as part of that process. Because we’re seeing more and more people just flatly refuse to work with incubated code at all, we are going to make some of those changes as we create the libraries. That means application changes during library adoption, but it also means fewer syncs, and those seem to be the rage trigger. We are trying to minimize API changes, but some are just unavoidable (circular dependencies, hidden globals, etc. are things we won’t support). Based on our experiences in Juno, I expect we’ll continue to get a few things wrong in the API changes, but that they will settle down after 1-2 cycles after a library graduates, depending on how well early adoption goes.

In the future, I hope we can continue to use the incubator to avoid a lot of breaking churn. It does not seem like a community preference, though, and so the trade-off is less stability within each library as we figure out what the new APIs should look like. Again, we’re trying to minimize that, but the level of stability you seem to be asking for within a development cycle is beyond what I think we’re practically capable of providing while still maintaining the ability to actually graduate and improve the libraries.

> 
>> Now, we’re not perfect and sometimes this doesn’t happen exactly as planned, but the intent is there.
>> 
>> So I think we are actually doing all of the things you are asking us to do, with the exception of using the word “alpha” in the release version, and I’ve already given the technical reasons for doing that.
> 
> As far as pip goes, you may not know, but tox defaults to pip --pre,
> which means anyone using tox, like us all here, will be pulling the
> alphas down by default: so impacting folk doing e.g. devtest on
> icehouse. So I don't think the hack is working as intended.

I dislike tox more every day. Is this why we have the installation command override set in tox.ini?

Doug

> 
> -Rob
> 
> -- 
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev