[Win The Enterprise-wg] [OpenStack] [Win the Enterprise] EC2 API feedback

Barrett, Carol L carol.l.barrett at intel.com
Mon Feb 2 19:21:53 UTC 2015


Thanks to everyone for your feedback. I agree with Anthony, so will not work to recruit resources to address this in favor of higher priority features.
Carol

From: Anthony Hobbs [mailto:ahobbs at mirantis.com]
Sent: Monday, February 02, 2015 11:12 AM
To: Mark Voelker
Cc: Cooklin, Joel R; Esker, Robert; enterprise-wg at lists.openstack.org
Subject: Re: [Win The Enterprise-wg] [OpenStack] [Win the Enterprise] EC2 API feedback

I think Mark and Das hit it on the head there. It's a checkbox for managers, but due to the lack of feature parity, is not really used by the engineers.

My background is in utilizing AWS (I just recently started with OpenStack), but I would not want to use an AWS compatible API for OpenStack due to the parity mismatch. I'd use some middle layer as Mark suggested. I have only been at one company that actually had two fully functional clouds (AWS and Cloud.com), and we used a 3rd party wrapper to control it (RightScale) rather than use either clouds API's.

My "Vote" would to not prioritize AWS compatibility to allow us to focus on other issues (like our HA or upgrade stories).

Anthony Hobbs
SRE Operations Architect

On Mon, Feb 2, 2015 at 10:09 AM, Mark Voelker <mvoelker at vmware.com<mailto:mvoelker at vmware.com>> wrote:
I’ve generally found this to usually be a “checkbox item”.  E.g. customers deploying a private enterprise cloud are interested in having EC2 compatibility from the perspective that it *theoretically* allows them to hybridize workloads or in cases where they’re not terribly familiar with all the workloads that will be running on their private cloud but want to generally make it easy for them to run on-prem vs on Amazon.  From that perspective, it’s an item that shows up on wish lists more often than it actually gets exercised, and I don’t think I’ve ever run across a situation where supporting Nova’s EC2 compatibility or not was a deal breaker.  Those who are looking at repatriating workloads already heavily invested in AWS generally need more functionality than is currently present anyway (to Das’s point).  Those who are interested in using multiple clouds sometimes choose a middle layer such as Apache jClouds.

At Your Service,

Mark T. Voelker
OpenStack Architect

On Feb 2, 2015, at 10:39 AM, Kingshott, Daniel (Helion Professional Services.) <daniel.kingshott at hp.com<mailto:daniel.kingshott at hp.com>> wrote:

> I agree with Das, those folks who truly need AWS compatible API's either use Eucalyptus or a 3rd party tool to which manages their AWS and Openstack deployments.
>
> Thanks,
>
> Dan
>
>
> -----Original Message-----
> From: Kamhout, Das [mailto:das.kamhout at intel.com<mailto:das.kamhout at intel.com>]
> Sent: Friday, January 30, 2015 4:26 PM
> To: Esker, Robert; Barrett, Carol L; enterprise-wg at lists.openstack.org<mailto:enterprise-wg at lists.openstack.org>
> Cc: Cooklin, Joel R
> Subject: Re: [Win The Enterprise-wg] [OpenStack] [Win the Enterprise] EC2 API feedback
>
> From our experience, people using AWS utilize a large assortment of APIs (ELB, CloudFormation, S3, EBS, EC2, Route53), and many have chosen to use higher level tools to handle their cloud app deployments either through an abstraction layer, or through a PaaS (RightScale, Enstratius, Cloud Forms, CloudFoundry, and now Docker, Kubernetes, MesoSphere).
>
> Being that OpenStack doesn¹t really have full API compatibility to AWS, generally we have stuck with the native commandsŠ simple enough for the types of scripts to have variables that do get instance calls to have EC2 or Nova semantics depending on the endpoint type.
>
> Personally I would rather see more focus on getting OpenStack APIs consistent, backwards compatible, and working across different OpenStack deployments as a higher priority.
>
> -Das
> Intel (formerly Intel IT)
>
> On 1/30/15, 3:42 PM, "Esker, Robert" <Rob.Esker at netapp.com<mailto:Rob.Esker at netapp.com>> wrote:
>
>> Carol et al,
>>
>> A number of our customers employ OpenStack motivated in large part for
>> it¹s ability to function as an on-prem AWS of sorts (something they can
>> burst from or repatriate to w/ out altering app deployment logic, or
>> simply used as a target for dev tools that expect an AWS endpoint).
>>
>> Cheers,
>>
>> Rob Esker
>> NetApp, Inc.
>>
>>
>>
>>
>> On 1/30/15, 6:01 PM, "Barrett, Carol L" <carol.l.barrett at intel.com<mailto:carol.l.barrett at intel.com>> wrote:
>>
>>> Hi All - I wanted to run this by you to get your input on importance
>>> for our Enterprise Customers?
>>> Thanks
>>> Carol
>>>
>>> -----Original Message-----
>>> From: Michael Still [mailto:mikal at stillhq.com<mailto:mikal at stillhq.com>]
>>> Sent: Thursday, January 29, 2015 4:01 PM
>>> To: foundation at lists.openstack.org<mailto:foundation at lists.openstack.org>; OpenStack Development Mailing List
>>> Subject: [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
>>>
>>> _______________________________________________
>>> Foundation mailing list
>>> Foundation at lists.openstack.org<mailto:Foundation at lists.openstack.org>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
>>>
>>> _______________________________________________
>>> Enterprise-wg mailing list
>>> Enterprise-wg at lists.openstack.org<mailto:Enterprise-wg at lists.openstack.org>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/enterprise-wg
>> _______________________________________________
>> Enterprise-wg mailing list
>> Enterprise-wg at lists.openstack.org<mailto:Enterprise-wg at lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/enterprise-wg
>
>
> _______________________________________________
> Enterprise-wg mailing list
> Enterprise-wg at lists.openstack.org<mailto:Enterprise-wg at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/enterprise-wg
>
> _______________________________________________
> Enterprise-wg mailing list
> Enterprise-wg at lists.openstack.org<mailto:Enterprise-wg at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/enterprise-wg


_______________________________________________
Enterprise-wg mailing list
Enterprise-wg at lists.openstack.org<mailto:Enterprise-wg at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/enterprise-wg



--
Anthony Hobbs
SRE Operations Architect
Mirantis Inc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/enterprise-wg/attachments/20150202/4c4552b5/attachment-0001.html>


More information about the Enterprise-wg mailing list