Open Stack

Hi everyone,

I agree with both of the perspectives given thus far.  

I've seen organizations that leverage both private and public as available options for production typically are doing so through PaaS or an "abstraction layer".  Organizations that leverage only [private] or [private cloud for Test/Dev + public for production] develop with AWS compatible APIs to keep their options open (or as a way to match what their production environment will look like).

In the last user survey, 30-40% of respondents said they were using  EC2 or S3 compatible APIs (http://superuser.openstack.org/articles/openstack-user-survey-insights-november-2014).

Finally, I noticed that Alex Levine and team are already offering to help and Tim is going to try and get additional help during the Ops summit.  

Have a great weekend everyone!!

Thanks,
Shamail 



> On Jan 30, 2015, at 4:26 PM, Kamhout, Das <das.kamhout at intel.com> wrote:
> 
> 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> 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> 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]
>>> Sent: Thursday, January 29, 2015 4:01 PM
>>> To: 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
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
>>> 
>>> _______________________________________________
>>> Enterprise-wg mailing list
>>> 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
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/enterprise-wg
> 
> 
> _______________________________________________
> Enterprise-wg mailing list
> Enterprise-wg at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/enterprise-wg