On Jan 21, 2014, at 12:19 PM, Alexei Kornienko <alexei.kornie...@gmail.com<mailto:alexei.kornie...@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 <s...@dague.net<mailto:s...@dague.net>> On 01/21/2014 11:54 AM, Renat Akhmerov wrote: > > On 17 Jan 2014, at 22:00, Jamie Lennox > <jamielen...@redhat.com<mailto:jamielen...@redhat.com> > <mailto:jamielen...@redhat.com<mailto:jamielen...@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 s...@dague.net<mailto:s...@dague.net> / sean.da...@samsung.com<mailto:sean.da...@samsung.com> http://dague.net<http://dague.net/> _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
