Open Stack

On 09/03/2014 12:16 PM, Doug Hellmann wrote:
> On Sep 3, 2014, at 11:37 AM, Joe Gordon <joe.gordon0 at gmail.com
> <mailto:joe.gordon0 at gmail.com>> wrote:
>
>> As you all know, there has recently been several very active discussions
>> around how to improve assorted aspects of our development process. One
>> idea
>> that was brought up is to come up with a list of cycle goals/project
>> priorities for Kilo [0].
>>
>> To that end, I would like to propose an exercise as discussed in the
>> TC meeting yesterday [1]:
>> Have anyone interested (especially TC members) come up with a list of
>> what they think the project wide Kilo cycle goals should be and post
>> them on this thread by end of day Wednesday, September 10th. After
>> which time we can begin discussing the results.
>> The goal of this exercise is to help us see if our individual world
>> views align with the greater community, and to get the ball rolling on
>> a larger discussion of where as a project we should be focusing more time.
>
> Thanks for starting this discussion, Joe. It’s important for us to start
> working on “OpenStack” as a whole, in addition to our individual projects.

Agreed. Thank you, Joe.

> 1. Sean has done a lot of analysis and started a spec on standardizing
> logging guidelines where he is gathering input from developers,
> deployers, and operators [1]. Because it is far enough for us to see
> real progress, it’s a good place for us to start experimenting with how
> to drive cross-project initiatives involving code and policy changes
> from outside of a single project. We have a couple of potentially
> related specs in Oslo as part of the oslo.log graduation work [2] [3],
> but I think most of the work will be within the applications.

No surprise, I'm a huge +1 on this.

> 2. A longer-term topic is standardizing our notification content and
> format. See the thread "Treating notifications as a contract” for
> details. We could set a goal for Kilo of establishing the requirements
> and proposing a spec, with implementation to begin in L.

+1.

> 3. Another long-term topic is standardizing our APIs so that we use
> consistent terminology and formatting (I think we have at least 3 forms
> of errors returned now?). I’m not sure we have anyone ready to drive
> this, yet, so I don’t think it’s something to consider for Kilo.

+10

Frankly, I believe this should be our #1 priority from a cross-project 
perspective.

The inconsistencies in the current APIs (even within the same project's 
APIs!) is just poor form and since our REST APIs are the very first 
impression that we give to the outside developer community, it really is 
incumbent on us to make sure they are explicit, free of side-effects, 
well-documented, consistent, easy-to-use, and hide implementation 
details thoroughly.

> 4. I would also like to see the unified SDK and command line client
> projects continued (or resumed, I haven’t been following the SDK work
> closely). Both of those projects will eventually make using OpenStack
> clouds easier. It would be nice to see some movement towards a “user
> tools” program to encompass both of these projects, perhaps with an eye
> on incubation at the end of Kilo.

+1

> 5. And we should also be considering the Python 3 porting work. We’ve
> made some progress with the Oslo libraries, with oslo.messaging &
> eventlet still our main blocker. We need to put together a more concrete
> plan to finish that work and for tackling applications, as well as a
> team willing to help projects through their transition. This is very
> long term, but does need attention, and I think it’s reasonable to ask
> for a plan by the end of Kilo.

+0 (only because I don't consider it a priority compared with the other 
things you've documented here)

>  From a practical standpoint, we do need to work out details like where
> we make decisions about the plans for these projects once the general
> idea is approved. We’ve done some of this in the Oslo project in the
> past (log translations, for example) but I don’t think that’s the right
> place for projects at this scale. A new openstack-specs repository would
> give us a place to work on them, but we need to answer the question of
> how to decide what is approved.

An openstack-specs repo might indeed be a nice place to put this 
cross-project, OpenStack-wide type of stuff.

Best,
-jay

> Doug
>
>>
>>
>> best,
>> Joe Gordon
>>
>> [0]
>> http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html
>> [1]
>> http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-02-20.04.log.html
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> <mailto:OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>