On 09/03/2014 12:16 PM, Doug Hellmann wrote:
On Sep 3, 2014, at 11:37 AM, Joe Gordon <joe.gord...@gmail.com
<mailto: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.
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@lists.openstack.org
<mailto: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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
