Open Stack

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?

> 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?

> 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.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud