On Mon, Feb 2, 2015 at 11:01 PM, Alexandre Levine <alev...@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 <dava...@gmail.com> >> wrote: >>> >>> Alex, >>> >>> Very cool. thanks. >>> >>> -- dims >>> >>> On Sat, Jan 31, 2015 at 1:04 AM, Alexandre Levine >>> <alev...@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.b...@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...@emc.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 1/29/15, 4:01 PM, "Michael Still" <mi...@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 >>>>>>> foundat...@lists.openstack.org >>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> __________________________________________________________________________ >>>>>> OpenStack Development Mailing List (not for usage questions) >>>>>> Unsubscribe: >>>>>> openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> > -- Rackspace Australia __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev