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