> On Nov 21, 2013, at 10:43 AM, "Ben Nemec" <openst...@nemebean.com> wrote: > >> On 2013-11-21 10:20, Jesse Noller wrote: >>> 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) >> 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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
