openstack-poc team mailing list archive

[Monty Taylor <mordred@xxxxxxxxxxxx>]

On 06/18/2012 02:26 PM, Joe Heck wrote:
> Monty -
> 
> Thierry stated it as an assumption last PPB meeting, but I'd like it
> to be explicit that we have at least a tag on each client library
> release that we make so that it's possible to distribute a version of
> the clients.

+1000

I didn't want to get too far into implementation details, but the way
I'd really like to see this work for the client libs is that releases
are actually trigger via jenkins by tags on the repo - so there would
literally be no way to release something _without_ a tag.

I've got a POC patch to do the tag-based-versioning here:

https://review.openstack.org/#/c/8427/

We need to get (aiui) one thing landed to zuul so that we can
appropriately trigger on tag events... but that's the plan in my brain hole.

> On Jun 18, 2012, at 2:11 PM, Monty Taylor wrote:
>> We're trying to figure out how we release client libraries. We're
>> really close - but there are some sticking points.
>> 
>> First of all, things that don't really have dissent (with
>> reasoning)
>> 
>> - We should release client libs to PyPI
>> 
>> Client libs are for use in other python things, so they should be
>> able to be listed as dependencies. Additionally, proper releases to
>> PyPI will make our cross project depends work more sensibly
>> 
>> - They should not necessarily be tied to server releases
>> 
>> There could be a whole version of the server which sees no needed 
>> changes in the client. Alternately, there could be new upcoming
>> server features which need to go into a released version of the
>> library even before the server is released.
>> 
>> - They should not be versioned with the server
>> 
>> See above.
>> 
>> - Releases of client libs should support all published versions of 
>> server APIs
>> 
>> An end user wants to talk to his openstack cloud - not necessarily
>> to his Essex cloud or his Folsom cloud. That user may also have
>> accounts on multiple providers, and would like to be able to write
>> one program to interact with all of them - if the user needed the
>> folsom version of the client lib to talk to the folsom cloud and
>> the essex version to talk to the essex cloud, his life is very
>> hard. However, if he can grab the latest client lib and it will
>> talk to both folsom and essex, then he will be happy.
>> 
>> There are three major points where there is a lack of clear
>> agreement. Here they are, along with suggestions for what we do
>> about them.
>> 
>> - need for "official" stable branches
>> 
>> I would like to defer on this until such a time as we actually need
>> it, rather than doing the engineering for in case we need it. But
>> first, I'd like to define we, and that is that "we" are OpenStack
>> as an upstream. As a project, we are at the moment probably the
>> single friendliest project for the distros in the history of
>> software. But that's not really our job. Most people out there
>> writing libraries do not have multiple parallel releases of those
>> libraries - they have the stable library, and then they release a
>> new one, and people either upgrade their apps to use the new lib or
>> they don't.
>> 
>> One of the reasons this has been brought up as a need is to allow
>> for drastic re-writes of a library. I'll talk about that in a
>> second, but I think that is a thing that needs to have allowances
>> for happening.
>> 
>> So the model that keystone-lite used - create an experimental
>> branch for the new work, eventually propose that it becomes the new
>> master - seems like a better fit for the "drastic rewrite" scenario
>> than copying the stable/* model from the server projects, because I
>> think the most common thing will be that library changes are
>> evolutionary, and having two mildly different branches that both
>> represent something that's actually pretty much stable will just be
>> more confusing than helpful.
>> 
>> That being said - at such a time that there is actually a
>> pain-point or a specific need for a stable branch, creating
>> branches is fairly easy ... but I think once we have an actual
>> burning need for such a thing, it will make it easier for us to
>> look at models of how we'll use it.
>> 
>> - API or major-rewrite-driven versioning scheme
>> 
>> I was wondering why bcwaldon and I were missing each other so
>> strongly in the channel the other day when we were discussing this,
>> and then I realized that it's because we have one word "API" that's
>> getting overloaded for a couple of different meanings - and also
>> that I was being vague in my usage of the word. So to clarify, a
>> client library has:
>> 
>> * programming level code APIs * supported server REST APIs
>> 
>> So I back off everything I said about tying client libs version to 
>> server REST API support. Brian was right, I was wrong. The thing
>> that's more important here is that the version should indicate
>> programmer contract, and if it that is changed in a breaking
>> manner, the major number should bump.
>> 
>> If we combine that with the point from above that our libraries
>> should always support the existing server REST APIs, then I think
>> we can just purely have statements like "support for compute v3 can
>> be found in 2.7.8 and later" and people will likely be fine,
>> because it will map easily to the idea "just grab the latest lib
>> and you should be able to talk to the latest server" Yea?
>> 
>> So in that case, the client libs versions are purely whatever they
>> are right now, and we'll increase them moving forward using normal
>> library version thoughts.
>> 
>> - room for deprecating old APIs
>> 
>> The above then leads us to wanting to know what we do about
>> supported server REST APIs over time, especially since I keep
>> making sweeping statements about "should support all available
>> server versions" ... How about this as a straw man: Since we're
>> planning on beginning to run tests of the client libs against
>> previous versions (so we'll test trunk novaclient against essex
>> nova in addition to trunk nova) ... we need support for past
>> versions of servers as long as our automation can sensibly spin up
>> a past version. (Since the support for that API version shouldn't
>> need huge amounts of work moving forward) But there will reach a
>> point where old server versions require stuff that's older than we 
>> feel like supporting, and at that point we drop it. (or, more to
>> the point, that we reserve the right in the future to declare that
>> we're going to drop old server API versions - but the general
>> policy is that we'll keep old support until it becomes a pain in
>> the ass)
>> 
>> Does that all sit well with folks?
>> 
>> Monty
>> 
>> _______________________________________________ Mailing list:
>> https://launchpad.net/~openstack-poc Post to     :
>> openstack-poc@xxxxxxxxxxxxxxxxxxx Unsubscribe :
>> https://launchpad.net/~openstack-poc More help   :
>> https://help.launchpad.net/ListHelp
>> 
> 
> 
>