Open Stack

Deleting unnecessary code, introducing a stabilization cycle and/or making
definite steps towards a unified SDK are definitely my votes.


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Tue, Sep 9, 2014 at 5:09 PM, Joe Gordon <joe.gordon0 at gmail.com> wrote:

>
>
> On Wed, Sep 3, 2014 at 8:37 AM, Joe Gordon <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.
>>
>
>
>
> 1. Strengthen our north bound APIs
>
> * API micro-versioning
> * Improved CLI's and SDKs
> * Better capability discovery
> * Hide usability issues with client side logic
> * Improve reliability
>
> As others have said in this thread trying to use OpenStack as a user is a
> very frustrating experience. For a long time now we have focused on
> southbound APIs such as drivers, configuration options, supported
> architectures etc. But as a project we have not spent nearly enough time on
> the end user experience. If our northbound APIs aren't something developers
> want to use, our southbound API work doesn't matter.
>
> 2. 'Fix' our development process
>
> * openstack-specs. Currently we don't have any good way to work on big
> entire-project efforts, hopefully something like a openstack-specs repo
> (with liasons from each core-team reviewing it) will help make it possible
> for us to tackle these issues.  I see us addressing the API
> micro-versioning and capability  discovery issues here.
> * functional testing and post merge testing. As discussed elsewhere in
> this thread our current testing model isn't meeting our current
> requirements.
>
> 3. Pay down technical debt
>
> This is the one I am actually least sure about, as I can really only speak
> for nova on this one. In our constant push forward we have accumulated a
> lot of technical debt. The debt manifests itself as hard to maintain code,
> bugs (nova had over 1000 open bugs until yesterday), performance/scaling
> issues and missing basic features. I think its time for us to take
> inventory if our technical debt and fix some of the biggest issues.
>
>
>>
>> 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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140909/2652ea6c/attachment.html>