On Sep 3, 2014, at 11:37 AM, Joe Gordon <joe.gord...@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. 

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 

[1] https://review.openstack.org/#/c/91446/
[3] https://blueprints.launchpad.net/oslo.log/+spec/remove-context-adapter

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.

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.

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.

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.

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.


> 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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

OpenStack-dev mailing list

Reply via email to