Open Stack

On Nov 13, 2014, at 12:41 PM, Jeremy Stanley <fungi at yuggoth.org> wrote:

> On 2014-11-13 07:50:51 -0500 (-0500), Doug Hellmann wrote:
> [...]
>> I do remember a comment at some point, and I’m not sure it was in
>> this session, about using the per-project client libraries as
>> “internal only” libraries when the new SDK matures enough that we
>> can declare that the official external client library. That might
>> solve the problem, since we could pin the version of the client
>> libraries used, but it seems like a solution for the future rather
>> than for this cycle.
> [...]
> 
> Many of us have suggested this as a possible way out of the tangle
> in the past, though Monty was the one who raised it during that
> session. Basically the problem we have boils down to wanting to use
> these libraries as a stable internal communication mechanism within
> components of an OpenStack environment but also be able to support
> tenant users and application developers interacting with a broad
> variety of OpenStack releases through them, and that is a mostly
> unreconcilable difference. Having a user-facing SDK which talks to
> OpenStack APIs with broad version support, and a separate set of
> per-project communication libraries which can follow the integrated
> release cadence and maintain stable backport branches as needed,
> makes the problem much more tractable in the long term.

That makes sense. If we go that route, there is a good chance we will want to reconsider the decision to deprecate the apiclient and cliutils modules in the incubator, since there would still be good value in maintaining those as shared code for the internal client libraries.

Doug