[OpenStack Foundation] Finding people to work on the EC2 API in Nova
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
Is there a blue print or some set of bugs tagged in some way to tackle? -matt On Thu, Jan 29, 2015 at 7:01 PM, Michael Still <mikal@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
Michael, Seems like Wataru from CERN is working on testing EC2. He is adding Rally scenarios related to EC2: https://review.openstack.org/#/c/147550/ So at least EC2 will have good functional/perf test coverage. Best regards, Boris Pavlovic On Fri, Jan 30, 2015 at 3:11 AM, matt <matt@nycresistor.com> wrote:
Is there a blue print or some set of bugs tagged in some way to tackle?
-matt
On Thu, Jan 29, 2015 at 7:01 PM, Michael Still <mikal@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
There is an ec2 bug tag in launchpad. I would link to it except I am writing this offline. I will fix that later today. However I think what we've shown is that moving this code out of nova is the future. I would like to see someone come up with a plan to transition users to the stackforge project. That seems the best way forward at this point. Thanks, Michael On 30 Jan 2015 11:11 am, "matt" <matt@nycresistor.com> wrote:
Is there a blue print or some set of bugs tagged in some way to tackle?
-matt
On Thu, Jan 29, 2015 at 7:01 PM, Michael Still <mikal@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
On Thu, Jan 29, 2015 at 5:15 PM, Michael Still <mikal@stillhq.com> wrote:
There is an ec2 bug tag in launchpad. I would link to it except I am writing this offline. I will fix that later today.
Ok, now that the 40 seater turbo prop has landed, here we go: https://bugs.launchpad.net/nova/+bugs?field.tag=ec2
However I think what we've shown is that moving this code out of nova is the future. I would like to see someone come up with a plan to transition users to the stackforge project. That seems the best way forward at this point.
Thanks, Michael
On 30 Jan 2015 11:11 am, "matt" <matt@nycresistor.com> wrote:
Is there a blue print or some set of bugs tagged in some way to tackle?
-matt
On Thu, Jan 29, 2015 at 7:01 PM, Michael Still <mikal@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
-- Rackspace Australia
On Thu, 2015-01-29 at 16:01 -0800, Michael Still wrote:
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).
I'd love to get to the root cause before we jump to look for solutions. The story we hear is that EC2 is important and according to the user survey there are users that seem to be using OpenStack's EC2 code. Nova developers point out though that the EC2 code is broken and unusable. So something is out of whack: either user report are more 'wishes' than usage or the openstack code is not as bad or someone else is feeding these users good code (that is not in openstack repositories) or something else. I would suggest that we start by reaching out to these users. Which questions shall we ask them? I'd start from: * where did you get the EC2 API: vanilla openstack (version, etc) or via a vendor? which vendor? * how do you use the EC2 code? Anecdotes are enough I think at this point. Tim and user committee: do you think I or Tom can get the list of respondents to the user survey who declared to use EC2 so we can ask them more questions? If not, we can start by asking on the operators list and blog posts and wait for someone to come forward.
Michael, Our team can take the effort. We're the ones doing the stackforge EC2 API and we can maintain the nova's EC2 in acceptable state for the time being as well. If you can give us any permissions and leverage to not just contribute fixes and tests but also have a say in approval of those (maybe to just one of us) then it'll be fast. Otherwise it'll happen in due time but our previous attempts to contribute some fixes for EC2 API in nova took usually more than half a year to get through. Best regards Alex Levine On 1/30/15 3:01 AM, Michael Still 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
+1 cloudscaling has been pretty involved in ec2 support for openstack for a long while now. On Fri, Jan 30, 2015 at 2:27 PM, Alexandre Levine <alevine@cloudscaling.com> wrote:
Michael,
Our team can take the effort. We're the ones doing the stackforge EC2 API and we can maintain the nova's EC2 in acceptable state for the time being as well. If you can give us any permissions and leverage to not just contribute fixes and tests but also have a say in approval of those (maybe to just one of us) then it'll be fast. Otherwise it'll happen in due time but our previous attempts to contribute some fixes for EC2 API in nova took usually more than half a year to get through.
Best regards Alex Levine
On 1/30/15 3:01 AM, Michael Still 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
_______________________________________________ Foundation mailing list Foundation@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
Alex, Many thanks for the constructive approach. I've added an item to the list for the Ops meetup in March to see who would be interested to help. As discussed on the change, it is likely that there would need to be some additional Nova APIs added to support the full EC2 semantics. Thus, there would need to support from the Nova team to enable these additional functions. Having tables in the EC2 layer which get out of sync with those in the Nova layer would be a significant problem in production. I think this would merit a good slot in the Vancouver design sessions so we can also discuss documentation, migration, packaging, configuration management, scaling, HA, etc. Tim From: matt [mailto:matt@nycresistor.com] Sent: 30 January 2015 20:44 To: Alexandre Levine Cc: foundation@lists.openstack.org; OpenStack Development Mailing List (not for usage questions) Subject: Re: [OpenStack Foundation] [openstack-dev] Finding people to work on the EC2 API in Nova +1 cloudscaling has been pretty involved in ec2 support for openstack for a long while now. On Fri, Jan 30, 2015 at 2:27 PM, Alexandre Levine <alevine@cloudscaling.com<mailto:alevine@cloudscaling.com>> wrote: Michael, Our team can take the effort. We're the ones doing the stackforge EC2 API and we can maintain the nova's EC2 in acceptable state for the time being as well. If you can give us any permissions and leverage to not just contribute fixes and tests but also have a say in approval of those (maybe to just one of us) then it'll be fast. Otherwise it'll happen in due time but our previous attempts to contribute some fixes for EC2 API in nova took usually more than half a year to get through. Best regards Alex Levine On 1/30/15 3:01 AM, Michael Still 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 _______________________________________________ Foundation mailing list Foundation@lists.openstack.org<mailto:Foundation@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
Tim, We sure we can fix it and we know how. The only problem is to somehow get a hand with reviewing and approvals speed? Is there any remedy for this? I've asked Michael already above in the thread, but I don't presume that it's possible even to allow one of us to become core reviewer for EC2 part of the nova? Or is it? Best regards, Alex Levine On 1/30/15 10:57 PM, Tim Bell wrote:
Alex,
Many thanks for the constructive approach. I've added an item to the list for the Ops meetup in March to see who would be interested to help.
As discussed on the change, it is likely that there would need to be some additional Nova APIs added to support the full EC2 semantics. Thus, there would need to support from the Nova team to enable these additional functions. Having tables in the EC2 layer which get out of sync with those in the Nova layer would be a significant problem in production.
I think this would merit a good slot in the Vancouver design sessions so we can also discuss documentation, migration, packaging, configuration management, scaling, HA, etc.
Tim
*From:*matt [mailto:matt@nycresistor.com] *Sent:* 30 January 2015 20:44 *To:* Alexandre Levine *Cc:* foundation@lists.openstack.org; OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [OpenStack Foundation] [openstack-dev] Finding people to work on the EC2 API in Nova
+1 cloudscaling has been pretty involved in ec2 support for openstack for a long while now.
On Fri, Jan 30, 2015 at 2:27 PM, Alexandre Levine <alevine@cloudscaling.com <mailto:alevine@cloudscaling.com>> wrote:
Michael,
Our team can take the effort. We're the ones doing the stackforge EC2 API and we can maintain the nova's EC2 in acceptable state for the time being as well. If you can give us any permissions and leverage to not just contribute fixes and tests but also have a say in approval of those (maybe to just one of us) then it'll be fast. Otherwise it'll happen in due time but our previous attempts to contribute some fixes for EC2 API in nova took usually more than half a year to get through.
Best regards Alex Levine
On 1/30/15 3:01 AM, Michael Still 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
_______________________________________________ Foundation mailing list Foundation@lists.openstack.org <mailto:Foundation@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
On Fri, Jan 30, 2015 at 07:57:08PM +0000, Tim Bell wrote:
Alex,
Many thanks for the constructive approach. I've added an item to the list for the Ops meetup in March to see who would be interested to help.
As discussed on the change, it is likely that there would need to be some additional Nova APIs added to support the full EC2 semantics. Thus, there would need to support from the Nova team to enable these additional functions. Having tables in the EC2 layer which get out of sync with those in the Nova layer would be a significant problem in production.
Adding new APIs to Nova to support out of tree EC2 impl is perfectly reasonsable. Indeed if there is data needed by EC2 that Nova doesn't provide already, chances are that providing this data woudl be useful to other regular users / client apps too. Just really needs someone to submit a spec with details of exactly which functionality is missing. It shouldnt be hard for Nova cores to support it, given the desire to see the out of tree EC2 impl take over & in tree impl removed.
I think this would merit a good slot in the Vancouver design sessions so we can also discuss documentation, migration, packaging, configuration management, scaling, HA, etc.
I'd really strongly encourage the people working on this to submit the detailed spec for the new APIs well before the Vancouver design summit. Likewise at lesat document somewhere the thoughts on upgrade paths plans. We need to at least discuss & iterate on this a few times online, so that we can take advantage of the f2f time for any remaining harder parts of the discussion. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Daniel, On 2/2/15 12:58 PM, Daniel P. Berrange wrote:
Alex,
Many thanks for the constructive approach. I've added an item to the list for the Ops meetup in March to see who would be interested to help.
As discussed on the change, it is likely that there would need to be some additional Nova APIs added to support the full EC2 semantics. Thus, there would need to support from the Nova team to enable these additional functions. Having tables in the EC2 layer which get out of sync with those in the Nova layer would be a significant problem in production. Adding new APIs to Nova to support out of tree EC2 impl is perfectly reasonsable. Indeed if there is data needed by EC2 that Nova doesn't provide already, chances are that providing this data woudl be useful to other regular users / client apps too. Just really needs someone to submit a spec with details of exactly which functionality is missing. It shouldnt be hard for Nova cores to support it, given
On Fri, Jan 30, 2015 at 07:57:08PM +0000, Tim Bell wrote: the desire to see the out of tree EC2 impl take over & in tree impl removed.
We'll do the spec shortly.
I think this would merit a good slot in the Vancouver design sessions so we can also discuss documentation, migration, packaging, configuration management, scaling, HA, etc. I'd really strongly encourage the people working on this to submit the detailed spec for the new APIs well before the Vancouver design summit. Likewise at lesat document somewhere the thoughts on upgrade paths plans. We need to at least discuss & iterate on this a few times online, so that we can take advantage of the f2f time for any remaining harder parts of the discussion.
We'll see about that also when all of the subjects we can think of or get questions about are covered somewhere in docs or specs. By the way - how do you usually do those online discussions? I mean what is the tooling?
Regards, Daniel
Best regards, Alex Levine
On Mon, Feb 02, 2015 at 02:45:53PM +0300, Alexandre Levine wrote:
Daniel,
On 2/2/15 12:58 PM, Daniel P. Berrange wrote:
Alex,
Many thanks for the constructive approach. I've added an item to the list for the Ops meetup in March to see who would be interested to help.
As discussed on the change, it is likely that there would need to be some additional Nova APIs added to support the full EC2 semantics. Thus, there would need to support from the Nova team to enable these additional functions. Having tables in the EC2 layer which get out of sync with those in the Nova layer would be a significant problem in production. Adding new APIs to Nova to support out of tree EC2 impl is perfectly reasonsable. Indeed if there is data needed by EC2 that Nova doesn't provide already, chances are that providing this data woudl be useful to other regular users / client apps too. Just really needs someone to submit a spec with details of exactly which functionality is missing. It shouldnt be hard for Nova cores to support it, given
On Fri, Jan 30, 2015 at 07:57:08PM +0000, Tim Bell wrote: the desire to see the out of tree EC2 impl take over & in tree impl removed.
We'll do the spec shortly.
I think this would merit a good slot in the Vancouver design sessions so we can also discuss documentation, migration, packaging, configuration management, scaling, HA, etc. I'd really strongly encourage the people working on this to submit the detailed spec for the new APIs well before the Vancouver design summit. Likewise at lesat document somewhere the thoughts on upgrade paths plans. We need to at least discuss & iterate on this a few times online, so that we can take advantage of the f2f time for any remaining harder parts of the discussion.
We'll see about that also when all of the subjects we can think of or get questions about are covered somewhere in docs or specs. By the way - how do you usually do those online discussions? I mean what is the tooling?
I just mean discussions on this mailing list, or in the gerrit reviews for the spec and/or patches Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On 2015-02-02 14:45:53 +0300 (+0300), Alexandre Levine wrote:
On 2/2/15 12:58 PM, Daniel P. Berrange wrote: [...]
We need to at least discuss & iterate on this a few times online, so that we can take advantage of the f2f time for any remaining harder parts of the discussion. [...] how do you usually do those online discussions? I mean what is the tooling?
You're doing it right now. But also, comments on review.openstack.org for your proposed spec, ad hoc discussions in appropriate IRC channels[1] and possibly more officially in weekly IRC meetings[2]. [1] https://wiki.openstack.org/wiki/IRC [2] https://wiki.openstack.org/wiki/Meetings -- Jeremy Stanley
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@emc.com On 1/29/15, 4:01 PM, "Michael Still" <mikal@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
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@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@emc.com
On 1/29/15, 4:01 PM, "Michael Still" <mikal@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-- Davanum Srinivas :: https://twitter.com/dims
On Fri, Jan 30, 2015 at 5:21 PM, Davanum Srinivas <davanum@gmail.com> wrote:
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.
I would encourage DevStack support to be implemented as an external plugin in the stackforge repo directly if they want to do the integration. This would allow local devstack runs to use it directly even if it doesn't get in to the CI gate. Most of the EC2 exercises in DevStack are broken and I plan to go ahead and remove them soon, plus disabling n-crt and n-obj which both only exist to support euca2ools bundling. dt -- Dean Troyer dtroyer@gmail.com
Davanum, We've added the devstack support. It's in our stackforge repository. https://github.com/stackforge/ec2-api/tree/master/contrib/devstack 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@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@emc.com
On 1/29/15, 4:01 PM, "Michael Still" <mikal@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Alexandre, very cool. Next step would be what we call a dsvm job that uses this devstack hook. Example i am most familiar is is nova-docker's check-tempest-dsvm-docker job: https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/n... (also see zuul/layout.yaml) thanks, dims On Thu, Feb 5, 2015 at 7:01 AM, Alexandre Levine <alevine@cloudscaling.com> wrote:
Davanum,
We've added the devstack support. It's in our stackforge repository. https://github.com/stackforge/ec2-api/tree/master/contrib/devstack
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@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@emc.com
On 1/29/15, 4:01 PM, "Michael Still" <mikal@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-- Davanum Srinivas :: https://twitter.com/dims
participants (11)
-
Alexandre Levine
-
Bias, Randy
-
Boris Pavlovic
-
Daniel P. Berrange
-
Davanum Srinivas
-
Dean Troyer
-
Jeremy Stanley
-
matt
-
Michael Still
-
Stefano Maffulli
-
Tim Bell