Re: [openstack-dev] How to best make User Experience a priority in every project

On Nov 20, 2013, at 10:27 AM, Thierry Carrez wrote: > Anne Gentle wrote: >> It's nigh-impossible with the UX resources there now (four core) for >> them to attend all the project meetings with an eye to UX. Docs are in a >> similar situation. We also want docs to be present in every project. >>

Re: [openstack-dev] How to best make User Experience a priority in every project

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

Re: [openstack-dev] How to best make User Experience a priority in every project

> On Nov 21, 2013, at 10:43 AM, "Ben Nemec" wrote: > >> On 2013-11-21 10:20, Jesse Noller wrote: >>> On Nov 20, 2013, at 9:09 AM, Thierry Carrez wrote: >>> Hi everyone, >>> How should we proceed to make sure UX (user experience) is properly

Re: [openstack-dev] a "common" client library

On Jan 15, 2014, at 1:37 PM, Doug Hellmann wrote: > Several people have mentioned to me that they are interested in, or actively > working on, code related to a "common" client library -- something meant to > be reused directly as a basis for creating a common library for all of the > opensta

Re: [openstack-dev] a "common" client library

On Jan 15, 2014, at 4:55 PM, "Renat Akhmerov" mailto:rakhme...@mirantis.com>> wrote: Great idea, fully support it. We’re interested in that too. One specific thing that was mentioned is the ability to mock auth service seems to be very useful for some test scenarios, we came across that recen

Re: [openstack-dev] a "common" client library

On Jan 15, 2014, at 6:16 PM, Doug Hellmann wrote: > > > > On Wed, Jan 15, 2014 at 5:39 PM, Dean Troyer wrote: > On Wed, Jan 15, 2014 at 1:37 PM, Doug Hellmann > wrote: > Several people have mentioned to me that they are interested in, or actively > working on, code related to a "common" c

Re: [openstack-dev] a "common" client library

> On Jan 16, 2014, at 2:09 AM, "Flavio Percoco" wrote: > >> On 15/01/14 21:35 +, Jesse Noller wrote: >> >>> On Jan 15, 2014, at 1:37 PM, Doug Hellmann >>> wrote: >>> >>> Several people have mentioned to me that they a

Re: [openstack-dev] a "common" client library

On Jan 16, 2014, at 5:42 AM, "Chris Jones" mailto:c...@tenshu.net>> wrote: Hi Once a common library is in place, is there any intention to (or resistance against) collapsing the clients into a single project or even a single command (a la busybox)? (I'm thinking reduced load for packagers,

Re: [openstack-dev] a "common" client library

On Jan 16, 2014, at 5:53 AM, Chmouel Boudjnah mailto:chmo...@enovance.com>> wrote: On Thu, Jan 16, 2014 at 12:38 PM, Chris Jones mailto:c...@tenshu.net>> wrote: Once a common library is in place, is there any intention to (or resistance against) collapsing the clients into a single project or

Re: [openstack-dev] a "common" client library

On Jan 16, 2014, at 9:07 AM, Joe Gordon mailto:joe.gord...@gmail.com>> wrote: On Thu, Jan 16, 2014 at 9:45 AM, Jesse Noller mailto:jesse.nol...@rackspace.com>> wrote: On Jan 16, 2014, at 5:53 AM, Chmouel Boudjnah mailto:chmo...@enovance.com>> wrote: On Thu, Jan 16

Re: [openstack-dev] a "common" client library

On Jan 16, 2014, at 9:26 AM, Justin Hammond mailto:justin.hamm...@rackspace.com>> wrote: I'm not sure if it was said, but which httplib using being used (urllib3 maybe?). Also I noticed many people were talking about supporting auth properly, but are there any intentions to properly support 'noa

Re: [openstack-dev] a "common" client library

On Jan 16, 2014, at 9:54 AM, Alexei Kornienko mailto:alexei.kornie...@gmail.com>> wrote: On 01/16/2014 05:25 PM, Jesse Noller wrote: On Jan 16, 2014, at 9:07 AM, Joe Gordon mailto:joe.gord...@gmail.com>> wrote: On Thu, Jan 16, 2014 at 9:45 AM, Jesse Noller mail

Re: [openstack-dev] a "common" client library

On Jan 16, 2014, at 11:39 AM, Mark Washenberger mailto:mark.washenber...@markwash.net>> wrote: On Thu, Jan 16, 2014 at 8:06 AM, Dean Troyer mailto:dtro...@gmail.com>> wrote: On Thu, Jan 16, 2014 at 9:37 AM, Jesse Noller mailto:jesse.nol...@rackspace.com>> wrote: On Jan 16

Re: [openstack-dev] a "common" client library

On Jan 16, 2014, at 2:22 PM, Renat Akhmerov mailto:rakhme...@mirantis.com>> wrote: Since it’s pretty easy to get lost among all the opinions I’d like to clarify/ask a couple of things: * Keeping all the clients physically separate/combining them in to a single library. Two things here:

Re: [openstack-dev] a "common" client library

On Jan 16, 2014, at 4:59 PM, "Renat Akhmerov" mailto:rakhme...@mirantis.com>> wrote: On 16 Jan 2014, at 13:06, Jesse Noller mailto:jesse.nol...@rackspace.com>> wrote: Since it’s pretty easy to get lost among all the opinions I’d like to clarify/ask a couple of thing

Re: [openstack-dev] a "common" client library

currently progressing work on a blueprint that doesn't fully capture the design and I'd like to avoid that. Renat On 16 Jan 2014, at 18:09, Donald Stufft mailto:don...@stufft.io>> wrote: On Jan 16, 2014, at 8:42 PM, Jesse Noller mailto:jesse.nol...@rackspace.com>> wrote:

Re: [openstack-dev] a "common" client library

part: you re-ship the entire thing. This is how every other SDK *other* than openstack’s cli tools handles this. > johnu > > From: Jesse Noller [jesse.nol...@rackspace.com] > Sent: Thursday, January 16, 2014 5:42 PM > To: OpenStack Dev

Re: [openstack-dev] a "common" client library

58 AM > Subject: Re: [openstack-dev] a "common" client library > > On Thu, Jan 16, 2014 at 1:23 PM, Donald Stufft < > don...@stufft.io<mailto:don...@stufft.io> > wrote: > > > > > On Jan 16, 2014, at 4:06 PM, Jesse Noller < > jesse.nol

Re: [openstack-dev] a "common" client library

penstack-dev] a "common" client library >> >> On Thu, Jan 16, 2014 at 1:23 PM, Donald Stufft < don...@stufft.io > wrote: >> >> >> >> >> On Jan 16, 2014, at 4:06 PM, Jesse Noller < jesse.nol...@rackspace.com > >> wrote: >

Re: [openstack-dev] a "common" client library

s)" mailto:openstack-dev@lists.openstack.org>> Sent: Saturday, 18 January, 2014 4:00:58 AM Subject: Re: [openstack-dev] a "common" client library On Thu, Jan 16, 2014 at 1:23 PM, Donald Stufft < don...@stufft.io<mailto:don...@stufft.io> > wrote:

Re: [openstack-dev] a "common" client library

On Jan 21, 2014, at 10:54 AM, Renat Akhmerov mailto:rakhme...@mirantis.com>> wrote: On 17 Jan 2014, at 22:00, Jamie Lennox mailto:jamielen...@redhat.com>> wrote: (I don't buy the problem with large amounts of dependencies, if you have a meta-package you just have one line in requirements and

Re: [openstack-dev] a "common" client library

On Jan 21, 2014, at 12:19 PM, Alexei Kornienko mailto:alexei.kornie...@gmail.com>> wrote: Hello, I would like to end this requirements talk cause it doesn't make any sense in term of python clients. Initially the discussion was about "many clients projects with separate requirements" VS "sing

Re: [openstack-dev] a "common" client library

ume openstack” which is a very different profile, knowledge level and user story. 2014/1/21 Jesse Noller mailto:jesse.nol...@rackspace.com>> On Jan 21, 2014, at 12:19 PM, Alexei Kornienko mailto:alexei.kornie...@gmail.com>> wrote: Hello, I would like to end this requirements

[openstack-dev] [Horizon] Upstream help needed (django-compressor)

Hi All; Jannis Leidel, author of Django-Compressor which Horizon relies on recently sent out a message saying that he needs help maintaining/releasing django_compressor: https://twitter.com/jezdez/status/423559915660382209 If we have people willing to help upstream dependencies, this would be

Re: [openstack-dev] Ugly Hack to deal with multiple versions

On Feb 4, 2014, at 10:31 AM, Sean Dague wrote: > On 02/05/2014 01:09 AM, Dean Troyer wrote: >> On Tue, Feb 4, 2014 at 9:00 AM, Sean Dague > > wrote: >> >>Can you be more specific about what goes wrong here? I'm not entirely >>sure I understand why an old client of

Re: [openstack-dev] Ugly Hack to deal with multiple versions

On Feb 4, 2014, at 1:28 PM, Sean Dague wrote: > On 02/05/2014 01:50 AM, Jesse Noller wrote: >> >> On Feb 4, 2014, at 10:31 AM, Sean Dague wrote: >> >>> On 02/05/2014 01:09 AM, Dean Troyer wrote: >>>> On Tue, Feb 4, 2014 at 9:00 AM, Sea

Re: [openstack-dev] Asynchrounous programming: replace eventlet with asyncio

On Feb 6, 2014, at 2:32 PM, Kevin Conway wrote: > There's an incredibly valid reason why we use green thread abstractions like > eventlet and gevent in Python. The CPython implementation is inherently > single threaded so we need some other form of concurrency to get the most > effective use

Re: [openstack-dev] Asynchrounous programming: replace eventlet with asyncio

On Feb 7, 2014, at 1:51 AM, Chris Behrens wrote: > > On Feb 6, 2014, at 11:07 PM, Joshua Harlow wrote: > >> +1 >> >> To give an example as to why eventlet implicit monkey patch the world isn't >> especially great (although it's what we are currently using throughout >> openstack). >> >> T

Re: [openstack-dev] Asynchrounous programming: replace eventlet with asyncio

On Feb 7, 2014, at 11:12 AM, Chris Behrens wrote: > > On Feb 7, 2014, at 8:21 AM, Jesse Noller wrote: > >> It seems that baking concurrency models into the individual clients / >> services adds some opinionated choices that may not scale, or fit the needs >>

[openstack-dev] [python-openstacksdk] Initial meeting scheduling

Hi Everyone: Circling back to the client tools / SDK discussion - we’ve gotten a critical mass of people involved/interesting in the unified/common SDK back end for application developers and other end-users. From the wiki page: "This is a proposed OpenStack project that is desig

Re: [openstack-dev] [python-openstacksdk] Initial meeting scheduling

On Feb 7, 2014, at 5:57 PM, Doug Hellmann wrote: > > > > On Fri, Feb 7, 2014 at 6:15 PM, Jesse Noller > wrote: > Hi Everyone: > Circling back to the client tools / SDK discussion - we’ve gotten a > critical mass of people involved/interesting in the unifie

[openstack-dev] [python-openstacksdk] First meeting scheduled

As I said last week; we’re ready to kickoff and have regular meetings for the “unified python SDK” project. The initial meeting is scheduled on the wiki: https://wiki.openstack.org/wiki/Meetings#python-openstacksdk_Meeting Date/Time: Feb. 19th - 19:00 UTC / 1pm CST IRC channel: #openstack-meet

Re: [openstack-dev] [python-openstacksdk] First meeting scheduled

that would be successful. > > [1] > https://github.com/openstack/oslo-incubator/tree/master/openstack/common/apiclient > > > Best regards, > Boris Pavlovic > > > On Wed, Feb 12, 2014 at 12:40 AM, Jesse Noller > wrote: > As I said last week; we’re ready to

Re: [openstack-dev] [python-openstacksdk] First meeting scheduled

On Feb 12, 2014, at 9:07 AM, Ed Leafe wrote: > On Feb 11, 2014, at 3:30 PM, Jesse Noller wrote: > >> I did propose in the original thread that we join efforts: in fact, we >> already have a fully functioning, unified SDK that *could* be checked in >> today - but wit

Re: [openstack-dev] Interested in attracting new contributors?

On Feb 12, 2014, at 8:30 AM, Julie Pichon wrote: > Hi folks, > > Stefano's post on how to make contributions to OpenStack easier [1] > finally stirred me into writing about something that vkmc and myself > have been doing on the side for a few months to help new contributors > to get involved.

Re: [openstack-dev] [python-openstacksdk] REMINDER: First meeting scheduled

On Feb 11, 2014, at 2:40 PM, Jesse Noller wrote: > As I said last week; we’re ready to kickoff and have regular meetings for the > “unified python SDK” project. The initial meeting is scheduled on the wiki: > > https://wiki.openstack.org/wiki/Meetings#python-openstacksdk_Meeti

[openstack-dev] [python-openstacksdk] Meeting minutes, and Next Steps/new meeting time.

Hi Everyone; Our first python-openstack meeting was awesome: and I really want to thank everyone who came, and for Doug teaching me the meeting bot :) Minutes: http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-02-19-19.01.html Minutes (text):http: