On Nov 20, 2013, at 9:09 AM, Thierry Carrez <thie...@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)

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.


OpenStack-dev mailing list

Reply via email to