>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.
I still don't understand the problem here. Installed packages usually just lie quietly on your disk (which size is now measured in terabytes) and they don't act or stink unless you ask them to. I'm pretty sure that most of the people are not aware of ALL packages installed in their distribution and few packages that are not used won't make it any worse >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”. I agree that many clients can be confusing however I think that actuall problem here is not the clients number but discrepancies in client parameters naming and missing/unclear help. In our work of clients refactoring I will also update bash completition that we have for our clients. So when you use nova start-server you will see options applicable to this command etc. For the unified client we can make a nice commands hierarhcy and I don't think it will be confusing to users for example: $ openstack help nova cloud computing fabric controller glance discovering, registering, retrieving and storing virtual machine images cinder ... 22 records $ openstack help nova OpenStack Nova provides a cloud computing fabric controller, supporting a wide variety of virtualization technologies, including KVM, Xen, LXC, VMware, and more. In addition to its native API, it includes compatibility with the commonly encountered Amazon EC2 and S3 APIs. start-server ... With proper bash completition it should be quite easy to use. 2014/1/21 Jesse Noller <jesse.nol...@rackspace.com> > > On Jan 21, 2014, at 12:19 PM, Alexei Kornienko < > 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> > >> 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>> 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 / sean.da...@samsung.com >> http://dague.net >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> 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 > > > > _______________________________________________ > OpenStack-dev mailing list > 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
