openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #13315
Re: Thoughts on client library releasing
On Mon, Jun 18, 2012 at 5:56 PM, Monty Taylor <mordred@xxxxxxxxxxxx> wrote:
> On 06/18/2012 02:25 PM, Doug Hellmann wrote:
> > How do these plans fit with the idea of creating a unified client
> > library (either as one package or several, based on a common core)?
>
> They are kind of orthogonal. At the point where python-openstackclient
> is ready for release, we'd likely want to manage it the same way.
>
That makes sense. I didn't know if the unification work would be a trigger
for the "major rewrite" branching and versioning issues that you mentioned.
>
> > On Mon, Jun 18, 2012 at 5:11 PM, Monty Taylor <mordred@xxxxxxxxxxxx
> > <mailto:mordred@xxxxxxxxxxxx>> 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
> > Post to : openstack@xxxxxxxxxxxxxxxxxxx
> > <mailto:openstack@xxxxxxxxxxxxxxxxxxx>
> > Unsubscribe : https://launchpad.net/~openstack
> > More help : https://help.launchpad.net/ListHelp
> >
> >
>
References