Open Stack

On Jan 19, 2014, at 5:37 PM, Jamie Lennox <jamielennox at redhat.com<mailto:jamielennox at redhat.com>> wrote:

On Sat, 2014-01-18 at 09:13 -0500, Doug Hellmann wrote:
I like the idea of a fresh start, but I don't think that's
incompatible with the other work to clean up the existing clients.
That cleanup work could help with creating the backwards compatibility
layer, if a new library needs to include one, for example.


As far as namespace packages and separate client libraries, I'm torn.
It makes sense, and I originally assumed we would want to take that
approach. The more I think about it, though, the more I like the
approach Dean took with the CLI, creating a single repository with a
team responsible for managing consistency in the UI.


Doug

This *is* the approach Dean took with the CLI. Have a package that
provides the CLI but then have the actual work handed off to the
individual clients (with quite a lot of glue).

And I think many of us are making the argument (or trying to) that the “a lot of glue” approach is wrong and unsustainable for both a unified CLI long term *and especially* for application developers.



On Sat, Jan 18, 2014 at 1:00 AM, Jamie Lennox <jamielennox at redhat.com<mailto:jamielennox at redhat.com>>
wrote:
       I can't see any reason that all of these situations can't be
       met.

       We can finally take the openstack pypi namespace, move
       keystoneclient -> openstack.keystone and similar for the other
       projects. Have them all based upon openstack.base and probably
       an openstack.transport for transport.

       For the all-in-one users we can then just have
       openstack.client which depends on all of the openstack.x
       projects. This would satisfy the requirement of keeping
       projects seperate, but having the one entry point for newer
       users. Similar to the OSC project (which could acutally rely
       on the new all-in-one).

       This would also satisfy a lot of the clients who have i know
       are looking to move to a version 2 and break compatability
       with some of the crap from the early days.

       I think what is most important here is deciding what we want
       from our clients and discussing a common base that we are
       happy to support - not just renaming the existing ones.

       (I don't buy the problem with large amounts of dependencies,
       if you have a meta-package you just have one line in
       requirements and pip will figure the rest out.)

       Jamie

       ----- Original Message -----
From: "Jonathan LaCour" <jonathan-lists at cleverdevil.org<mailto:jonathan-lists at cleverdevil.org>>
To: "OpenStack Development Mailing List (not for usage
       questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Sent: Saturday, 18 January, 2014 4:00:58 AM
Subject: Re: [openstack-dev] a "common" client library


On Thu, Jan 16, 2014 at 1:23 PM, Donald Stufft <
       donald at stufft.io<mailto:donald at stufft.io> > wrote:




On Jan 16, 2014, at 4:06 PM, Jesse Noller <
       jesse.noller at RACKSPACE.COM<mailto:jesse.noller at RACKSPACE.COM> >
wrote:





On Jan 16, 2014, at 2:22 PM, Renat Akhmerov <
       rakhmerov at mirantis.com<mailto:rakhmerov at mirantis.com> > wrote:




Since it’s pretty easy to get lost among all the opinions
       I’d like to
clarify/ask a couple of things:




   * Keeping all the clients physically separate/combining
       them in to a
   single library. Two things here:

       * In case of combining them, what exact project are
       we considering?
       If this list is limited to core projects like nova
       and keystone what
       policy could we have for other projects to join this
       list?
       (Incubation, graduation, something else?)

       * In terms of granularity and easiness of
       development I’m for keeping
       them separate but have them use the same boilerplate
       code, basically
       we need a OpenStack Rest Client Framework which is
       flexible enough
       to address all the needs in an abstract domain
       agnostic manner. I
       would assume that combining them would be an
       additional
       organizational burden that every stakeholder would
       have to deal
       with.

Keeping them separate is awesome for *us* but really,
       really, really sucks
for users trying to use the system.

I agree. Keeping them separate trades user usability for
       developer usability,
I think user usability is a better thing to strive for.
100% agree with this. In order for OpenStack to be its most
       successful, I
believe firmly that a focus on end-users and deployers needs
       to take the
forefront. That means making OpenStack clouds as easy to
       consume/leverage as
possible for users and tool builders, and
       simplifying/streamlining as much
as possible.

I think that a single, common client project, based upon
       package namespaces,
with a unified, cohesive feel is a big step in this
       direction.

--
Jonathan LaCour



_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>

       http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


       _______________________________________________
       OpenStack-dev mailing list
       OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
       http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140120/d5dfb612/attachment.html>