openstack team mailing list archive

[Joe Heck <Joe.Heck@xxxxxxxxxx>]

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. 

-joe

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
>