Open Stack

On Mon, Feb 2, 2015 at 11:01 PM, Alexandre Levine
<alevine at cloudscaling.com> wrote:
> Michael,
>
> I'm rather new here, especially in regard to communication matters, so I'd
> also be glad to understand how it's done and then I can drive it if it's ok
> with everybody.
> By saying EC2 sub team - who did you keep in mind? From my team 3 persons
> are involved.

I see the sub team as the way of keeping the various organisations who
have expressed interest in helping pulling in the same direction. I'd
suggest you pick a free slot on our meeting calendar and run an irc
meeting there weekly to track overall progress.

> From the technical point of view the transition plan could look somewhat
> like this (sequence can be different):
>
> 1. Triage EC2 bugs and fix showstoppers in nova's EC2.
> 2. Contribute Tempest tests for EC2 functionality and employ them against
> nova's EC2.
> 3. Write spec for required API to be exposed from nova so that we get full
> info.
> 4. Triage and fix all of the existing nova's EC2 bugs worth fixing.
> 5. Set up Tempest testing of the stackforge/ec2 (if that's possible).
> 6. Communicate and discover all of the existing questions and problematic
> points for the switching from existing EC2 API to the new one. Provide
> solutions or decisions about them.
> 7. Do performance testing of the new stackforge/ec2 and provide fixes if any
> bottlenecks come up.
> 8. Have all of the above prepared for the Vancouver summit and discuss the
> situation there.

This sounds really good to me -- this is the sort of thing you'd be
tracking against in that irc meeting, although presumably you'd
negotiate as a group exactly what the steps are and who is working on
what.

Do you see transitioning users to the external EC2 implementation as a
final step in this list? I know you've only gone as far as Vancouver
here, but I want to be explicit about the intended end goal.

> Michael, I am still wondering, who's going to be responsible for timely
> reviews and approvals of the fixes and tests we're going to contribute to
> nova? So far this is the biggest risk. Is there anyway to allow some of us
> to participate in the process?

Sean has offered here, for which I am grateful. Your team as it forms
should also start reviewing each other's work, as that will reduce the
workload somewhat for Sean and other cores.

I think given the level of interest here we can have a serious
discussion at Vancouver about if EC2 should be nominated as a priority
task for the L release, which is our more formal way of cementing this
at the beginning of a release cycle.

Thanks again to everyone who has volunteered to help out with this.
35% of our users are grateful!

Michael


> On 2/2/15 2:46 AM, Michael Still wrote:
>>
>> So, its exciting to me that we seem to developing more forward
>> momentum here. I personally think the way forward is a staged
>> transition from the in-nova EC2 API to the stackforge project, with
>> testing added to ensure that we are feature complete between the two.
>> I note that Soren disagrees with me here, but that's ok -- I'd like to
>> see us work through that as a team based on the merits.
>>
>> So... It sounds like we have an EC2 sub team forming. How do we get
>> that group meeting to come up with a transition plan?
>>
>> Michael
>>
>> On Sun, Feb 1, 2015 at 4:12 AM, Davanum Srinivas <davanum at gmail.com>
>> wrote:
>>>
>>> Alex,
>>>
>>> Very cool. thanks.
>>>
>>> -- dims
>>>
>>> On Sat, Jan 31, 2015 at 1:04 AM, Alexandre Levine
>>> <alevine at cloudscaling.com> wrote:
>>>>
>>>> Davanum,
>>>>
>>>> Now that the picture with the both EC2 API solutions has cleared up a
>>>> bit, I
>>>> can say yes, we'll be adding the tempest tests and doing devstack
>>>> integration.
>>>>
>>>> Best regards,
>>>>    Alex Levine
>>>>
>>>> On 1/31/15 2:21 AM, Davanum Srinivas wrote:
>>>>>
>>>>> Alexandre, Randy,
>>>>>
>>>>> Are there plans afoot to add support to switch on stackforge/ec2-api
>>>>> in devstack? add tempest tests etc? CI Would go a long way in
>>>>> alleviating concerns i think.
>>>>>
>>>>> thanks,
>>>>> dims
>>>>>
>>>>> On Fri, Jan 30, 2015 at 1:24 PM, Bias, Randy <Randy.Bias at emc.com>
>>>>> wrote:
>>>>>>
>>>>>> As you know we have been driving forward on the stack forge project
>>>>>> and
>>>>>> it¹s our intention to continue to support it over time, plus
>>>>>> reinvigorate
>>>>>> the GCE APIs when that makes sense. So we¹re supportive of deprecating
>>>>>> from Nova to focus on EC2 API in Nova.  I also think it¹s good for
>>>>>> these
>>>>>> APIs to be able to iterate outside of the standard release cycle.
>>>>>>
>>>>>>
>>>>>>
>>>>>> --Randy
>>>>>>
>>>>>> VP, Technology, EMC Corporation
>>>>>> Formerly Founder & CEO, Cloudscaling (now a part of EMC)
>>>>>> +1 (415) 787-2253 [google voice]
>>>>>> TWITTER: twitter.com/randybias
>>>>>> LINKEDIN: linkedin.com/in/randybias
>>>>>> ASSISTANT: ren.ly at emc.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 1/29/15, 4:01 PM, "Michael Still" <mikal at stillhq.com> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> as you might have read on openstack-dev, the Nova EC2 API
>>>>>>> implementation is in a pretty sad state. I wont repeat all of those
>>>>>>> details here -- you can read the thread on openstack-dev for detail.
>>>>>>>
>>>>>>> However, we got here because no one is maintaining the code in Nova
>>>>>>> for the EC2 API. This is despite repeated calls over the last 18
>>>>>>> months (at least).
>>>>>>>
>>>>>>> So, does the Foundation have a role here? The Nova team has failed to
>>>>>>> find someone to help us resolve these issues. Can the board perhaps
>>>>>>> find resources as the representatives of some of the largest
>>>>>>> contributors to OpenStack? Could the Foundation employ someone to
>>>>>>> help
>>>>>>> us our here?
>>>>>>>
>>>>>>> I suspect the correct plan is to work on getting the stackforge
>>>>>>> replacement finished, and ensuring that it is feature compatible with
>>>>>>> the Nova implementation. However, I don't want to preempt the design
>>>>>>> process -- there might be other ways forward here.
>>>>>>>
>>>>>>> I feel that a continued discussion which just repeats the last 18
>>>>>>> months wont actually fix the situation -- its time to "break out" of
>>>>>>> that mode and find other ways to try and get someone working on this
>>>>>>> problem.
>>>>>>>
>>>>>>> Thoughts welcome.
>>>>>>>
>>>>>>> Michael
>>>>>>>
>>>>>>> --
>>>>>>> Rackspace Australia
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Foundation mailing list
>>>>>>> Foundation at lists.openstack.org
>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> __________________________________________________________________________
>>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>>> Unsubscribe:
>>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>> --
>>> Davanum Srinivas :: https://twitter.com/dims
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>



-- 
Rackspace Australia