Open Stack

On Jan 21, 2014, at 12:19 PM, Alexei Kornienko <alexei.kornienko at gmail.com<mailto:alexei.kornienko at gmail.com>> wrote:

Hello,

I would like to end this requirements talk cause it doesn't make any sense in term of python clients.
Initially the discussion was about "many clients projects with separate requirements" VS "single client project with single requirements list".


Then I suspect we’re at an impasse; I do plan on proceeding with a new wiki page and blueprint for a unified client, SDK (backend) for end users. I for one do not think things are as clear cut as you make them - and the +1s to the unified client thoughts clearly express the discontent with the current structure & packaging.

At that moment we should have stop and actually open requirements lists for python clients.
Basically all clients have the same requirement (cause they all do the same stuff - sending HTTP requests K.O.)
There is absolutely no difference in the situation of many clients vs single client.

Answering another question about "user only needs X (keystone) and we install package with clients for all openstack services":
Size of keystone client (and any other client I suppose) is ~300Kb I don't think that it's a big difference for the user to install package that is ~300Kb or ~10Mb (unless we are using openstack from Android).

It is when most openstack clouds don’t just run keystone. Or nova, or swift. Or when each client acts, smells and behaves differently. It matters a LOT when you’re trying to write applications on top of a mature openstack deployment.


>From the user perspective I think it's much easier to use client with "everything included" rather than try to google for client package for some rarely used service.


I have actual experience here as a person running a cloud and supporting end-users & developers: the overwhelming customer feedback (paid and unpaid (exploratory users)) is that the 22+ clients are confusing, difficult to use, prone to error. There are two ways of resolving this if you’re in my shoes - or in a role where the primary focus is not openstack developers or builders; the first is you coordinate work focusing on developer & end user experience upstream, working with openstack and the teams to come up with something that benefits everyone, or, you fork, and build the openstack equivalent to boto / awscli so you can provide a unified “one obvious way to consume openstack clouds”.

jesse

Regards,
Alexei




2014/1/21 Sean Dague <sean at dague.net<mailto:sean at dague.net>>
On 01/21/2014 11:54 AM, Renat Akhmerov wrote:
>
> On 17 Jan 2014, at 22:00, Jamie Lennox <jamielennox at redhat.com<mailto:jamielennox at redhat.com>
> <mailto:jamielennox at redhat.com<mailto:jamielennox at redhat.com>>> wrote:
>
>> (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.)
>
> +1
>
> Renat Akhmerov
> @ Mirantis Inc.

Man, where were you then when we had to spend 3 weeks unwinding global
requirements in the gate because pip was figuring it out all kinds of
wrong, and we'd do things like uninstall and reinstall
python-keystoneclient 6 times during an install. Because after that
experience, I'm very anti "pip will figure the rest out".

Because it won't, not in python, where we're talking about libraries
that are in the global namespace, where python can only have 1 version
of a dependency installed.

If the the solution is every openstack project should install a venv for
all it's dependencies to get around this issue, then we're talking a
different problem (and a different architecture from what we've been
trying to do). But I find the idea of having 12 copies of
python-keystone client installed on my openstack environment to be
distasteful.

So come spend a month working on requirements updates in OpenStack
gate... and if you still believe "pip will figure it out", well you are
a braver man than I. :)

        -Sean

--
Sean Dague
Samsung Research America
sean at dague.net<mailto:sean at dague.net> / sean.dague at samsung.com<mailto:sean.dague at samsung.com>
http://dague.net<http://dague.net/>


_______________________________________________
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/20140121/48e728ad/attachment.html>