Open Stack

On 2013-11-21 10:20, Jesse Noller wrote:
> 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

I believe this has been at least started in Oslo: 
https://github.com/openstack/oslo-incubator/tree/master/openstack/common/apiclient

I don't know how well that fits with what you're planning, but it's 
something to look at.

-Ben