Open Stack

On Tue, May 6, 2014 at 8:02 AM, Thierry Carrez <thierry at openstack.org> wrote:
> Dean Troyer wrote:
>> I want to open the discussion of an OpenStack Client Tools program
>> proposal to a wider audience.  It would initially consist of
>> OpenStackClient and eventually add the existing SDK projects as they are
>> ready to join. The initial wiki page is at
>> https://wiki.openstack.org/wiki/ClientTools.  I do want to have the
>> proposal made before the summit, but not necessarily the TC consideration.

I've been looking forward to this day for a long time! :-)

>
> Would you take over the Python client libraries as well ? On one hand
> they need /some/ domain expertise, but on the other I see no reason to
> special-case Python against other SDKs, and that may give the libraries
> a bit more attention and convergence (they currently are the ugly
> stepchild in some programs, and vary a lot).

If I understand the mission of the new Python SDK team, they plan to
build a new library with more consistency that may eventually replace
the project-specific libraries. (Maybe someone on that team can check
my facts there?) If that's correct, then it could make sense for that
SDK project to fold into a client tools program when it reaches some
definition of "done".

>
> In the case you'd absorb the Python client libraries, it might make
> sense to ship the keystone middleware in a separate package that would
> still live in the Identity program.

+1 -- Every consumer of the middleware needs a keystone client, but
not every keystone client user needs the middleware and its
dependencies.

>
>> There has recently been some discussion (specifically around summit
>> sessions) regarding the overlap of client code and the user experience
>> team.  This is one of the things I want to get some feedback on before
>> making a formal proposal.
>
> I think we need people caring for the end user and their experience of
> interacting with an OpenStack-backed cloud. I understand that CLI/SDK
> specialists and GUI-oriented specialists are different crowds, but they
> share the same objective and would benefit IMHO from being in the same
> program. There could be two subteams to care for specialists in both
> areas (or even 3 if you separate the CLI and SDK folks). Overall from
> the TC perspective it would make a much stronger proposal if you somehow
> could present a united (and without overlap) proposal.

If we intend to have official SDKs in multiple languages, we'll likely
have multiple teams working on those as well. The model emerging in
Oslo, based on similar sub-team models in Nova and Neutron, is to
allow a separate lead and review team for each new library, with
oslo-core participating in all repos/projects. A similar model seems
like it would fit well here, too.

Doug

>
> --
> Thierry Carrez (ttx)
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev