Open Stack

On 2/2/15 11:15 PM, Michael Still wrote:
> 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.

I'll do that when I've got myself acquainted with the weekly meetings 
procedure (haven't actually bumped into it before) :)
>
>>  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.

Yes, that's correct. The very final step though would be cleaning up 
nova from the EC2 stuff. But you're right, the major goal would be to 
make external EC2 API production-ready and to have all of the necessary 
means for users to seamlessly transition (no downtimes, no instances 
recreation required).
So I can point at least three distinct major milestones here:

1. EC2 API in nova is back and revived (no showstoppers, all of the 
currently employed functionality safe and sound, new tests added to 
check and ensure that).
2. External EC2 API is production-ready.
3. Nova is relieved of the EC2 stuff.

Vancouver is somewhere in between 1 and 3.
>
>> 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.

We've already started.
>
> 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
>>>
>>>
>
>