Open Stack

On Nov 20, 2013, at 9:09 AM, Thierry Carrez <thierry at openstack.org> wrote:

> Hi everyone,
> 
> How should we proceed to make sure UX (user experience) is properly
> taken into account into OpenStack development ? Historically it was hard
> for UX sessions (especially the ones that affect multiple projects, like
> CLI / API experience) to get session time at our design summits. This
> visibility issue prompted the recent request by UX-minded folks to make
> UX an official OpenStack program.
> 
> However, as was apparent in the Technical Committee meeting discussion
> about it yesterday, most of us are not convinced that establishing and
> blessing a separate team is the most efficient way to give UX the
> attention it deserves. Ideally, UX-minded folks would get active
> *within* existing project teams rather than form some sort of
> counter-power as a separate team. In the same way we want scalability
> and security mindset to be present in every project, we want UX to be
> present in every project. It's more of an advocacy group than a
> "program" imho.
> 
> So my recommendation would be to encourage UX folks to get involved
> within projects and during project-specific weekly meetings to
> efficiently drive better UX there, as a direct project contributor. If
> all the UX-minded folks need a forum to coordinate, I think [UX] ML
> threads and, maybe, a UX weekly meeting would be an interesting first step.
> 
> There would still be an issue with UX session space at the Design
> Summit... but that's a well known issue that affects more than just UX:
> the way our design summits were historically organized (around programs
> only) made it difficult to discuss cross-project and cross-program
> issues. To address that, the plan is to carve cross-project space into
> the next design summit, even if that means a little less topical
> sessions for everyone else.
> 
> Thoughts ?

Hello again everyone - let me turn this around a little bit, I’m working on proposing something based on the Oslo work and openstack-client, and overall looking at the *Developer Experience* focused around application developers and end-users more so than the individual UX issues (configuration, UI, IxD, etc).

I’ve spoken to Everett and others about discussions had at the summit around ideas like developer.openstack.org - and I think the idea is a good start towards improving the lives of downstream application developers. However, one of the problems (as I and others see it) is that there’s a series of disconnects between the needs of the individual projects to have a command line client for administrative / basic usage and the needs of application developers and end-users (not Openstack admins, just end users).

What I’d like to propose is a team that’s not focused on the overarching UX (from horizon to **) but rather a team / group focused on some key areas:

1: Creating an *application developer* focused SDK for openstack services 
2: Unifying the back-end code and common tools for the command line clients into 1 
3: Providing extension points for downstream vendors to add custom extensions as needed
4: Based on 1; make deriving project-specific CLIs a matter of importing/subclassing and extending 

This is a bit of a hybrid between what the awesome openstackclient team has done to make a unified CLI, but takes a step back to focus on a unified back end with clean APIs that can not only power CLIs, but also act as an SDK. This would allow many vendors (Rackspace, for example) to willingly drop their SDKs and leverage this unified back end.

In my “perfect world” you’d be able to, as an application developer targeting Openstack providers, do something close to (code sketch):

from openstack.api.auth import AuthClass
from openstack.api.nova import NovaClient
from openstack.api.nova import NovaAdmin

auth = AuthClass(…)

nova = NovaClient(auth)
nova.server.create(… block=True)

nova_admin = NovaAdmin(auth)
nova_admin.delete_flavor(…)

Downstream vendors could further extend each of these and either create very thin shims or meta packages that add provider specific services, e.g:

from openstack.vendor.rackspace.api.auth AuthClass 

…

The end goals being:

1: provide a common rest client back end for all the things
2: Collapse all common functions (such as error retries) into a common lib
3: DO NOT DICTATE a concurrency system: no eventlet, no greenlet. Just Python; allow application developers to use what they need to.
4: Provide a cliff based extension system for vendors 
5: Document everything.
6: Python 3 & 2 compatible code base

As I said earlier; this would build on work already in flight within openstack, and additionally within vendors such as rackspace to contribute to this effort directly and reduce the proliferation of SDKs/clis/etc. Existing SDKs could be end-of-lifed. The team working on this would be comprised of people focused on working across the openstack projects not just as dictators of supreme design, but actually implementing a consistent backend with resulting front-end. Individual project teams would also be involved and consulted - they would have to be as it would be a group effort.

jesse