Open Stack

> On Nov 21, 2013, at 10:43 AM, "Ben Nemec" <openstack at nemebean.com> wrote:
> 
>> 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
> 

Yup! Already been talking to people involved. All of this would build from existing work/teams and efforts


> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev