Open Stack

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

>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.


Since people are complaining about thread depth: I’ll focus on the blueprint and wiki page for now - we’re disagreeing on basic assumptions and facts here. If you are a developer or a user, trying to build an application that even uses 50% of the currently shipping openstack software; your life is extremely sub optimal.

The ideas expressed is to replace the focus of the clients and CLIs from “those who build openstack” to “those that consume openstack” which is a very different profile, knowledge level and user story.



2014/1/21 Jesse Noller <jesse.noller at rackspace.com<mailto:jesse.noller at rackspace.com>>

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


_______________________________________________
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/d7f6fb30/attachment.html>