Let's not forget that more than a quarter of OpenStack production deployments 
are using the EC2 interface from my memory of the user survey. Our experience 
is that the basic functionality is OK but you need to keep into the appropriate 
subset.

Any plans for depreciation of the EC2 inside Nova need to factor in the real 
life usage in production and have a validation window to confirm that an 
alternative solution is not only providing better and compatible functionality 
at scale but also is packaged, configured with puppet/chef/..., can be 
monitored/metered, rate limited, …

No problem to start the effort if there is full agreement that this is the way 
to go but this is not a trivial migration. 

Tim

On 9 Jan 2015, at 17:17, Steven Hardy <sha...@redhat.com> wrote:

> On Fri, Jan 09, 2015 at 09:11:50AM -0500, Sean Dague wrote:
>> boto 2.35.0 just released, and makes hmac-v4 authentication mandatory
>> for EC2 end points (it has been optionally supported for a long time).
>> 
>> Nova's EC2 implementation does not do this.
>> 
>> The short term approach is to pin boto -
>> https://review.openstack.org/#/c/146049/, which I think is a fine long
>> term fix for stable/, but in master not supporting new boto, which
>> people are likely to deploy, doesn't really seem like an option.
>> 
>> https://bugs.launchpad.net/tempest/+bug/1408987 is the bug.
>> 
>> I don't think shipping an EC2 API in Kilo that doesn't work with recent
>> boto is a thing Nova should do. Do we have volunteers to step up and fix
>> this, or do we need to get more aggressive about deprecating this interface?
> 
> I'm not stepping up to maintain the EC2 API, but the auth part of it is
> very similar to heat's auth (which does support hmac-v4), so I hacked on
> the nova API a bit to align with the way heat does things:
> 
> https://review.openstack.org/#/c/146124/ (WIP)
> 
> This needs some more work, but AFAICS solves the actual auth part which is
> quite simply fixed by reusing some code we have in heat's ec2token middleware.
> 
> If this is used, we could extract the common parts and/or use a common auth
> middleware in future, assuming the EC2 implementation as a whole isn't
> deemed unmaintained and removed that is.
> 
> Steve
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to