[openstack-dev] a "common" client library

Jonathan LaCour jonathan-lists at cleverdevil.org
Fri Jan 17 18:04:11 UTC 2014


On Thu, Jan 16, 2014 at 5:42 PM, Jesse Noller <jesse.noller at rackspace.com>wrote:

>
>
> On Jan 16, 2014, at 4:59 PM, "Renat Akhmerov" <rakhmerov at mirantis.com>
> wrote:
>
>  On 16 Jan 2014, at 13:06, Jesse Noller <jesse.noller at RACKSPACE.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.
>
>
> You may be right but not sure that adding another line into
> requirements.txt is a huge loss of usability.
>
>
>  It is when that 1 dependency pulls in 6 others that pull in 10 more -
> every little barrier or potential failure from the inability to make a
> static binary to how each tool acts different is a paper cut of frustration
> to an end user.
>

>
Most of the time the clients don't even properly install because of
> dependencies on setuptools plugins and other things. For developers (as
> I've said) the story is worse: you have potentially 22+ individual packages
> and their dependencies to deal with if they want to use a complete
> openstack install from their code.
>
>  So it doesn't boil down to just 1 dependency: it's a long laundry list
> of things that make consumers' lives more difficult and painful.
>
>  This doesn't even touch on the fact there aren't blessed SDKs or tools
> pointing users to consume openstack in their preferred programming language.
>
>  Shipping an API isn't enough - but it can be fixed easily enough.
>

+100

OpenStack must be attractive to our end users (developers and deployers),
as I mentioned earlier. Let's make it as simple as "pip install openstack"
if at all possible!

--
Jonathan LaCour
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140117/d4702505/attachment.html>


More information about the OpenStack-dev mailing list