[openstack-dev] [keystone][ec2-api][heat] Moving EC2 Auth and S3Token to Externally supported

Fox, Kevin M Kevin.Fox at pnnl.gov
Fri Feb 5 17:57:56 UTC 2016


Might double check with the heat folks. I think they use some of it with wait conditions still?

Thanks,
Kevin
________________________________
From: Tim Bell [Tim.Bell at cern.ch]
Sent: Friday, February 05, 2016 9:41 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported


Is it certain that there is no need for the functions with the new EC2-API functions ?

The S3 functions are somewhat separated from the EC2 API. How does SWIFT implement the S3 compatibility layer ?

Getting a ‘to be deprecated’ log entry into Mitaka would be useful to make sure we’re not using it somewhere else.

Tim

From: Dolph Mathews
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Friday 5 February 2016 at 17:07
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported

+1 this is a totally logical move, especially given that the current implementation back to the /v3/credentials API anyway.

On Friday, February 5, 2016, Morgan Fainberg <morgan.fainberg at gmail.com<mailto:morgan.fainberg at gmail.com>> wrote:
Looking over the state [and relatively untested nature] of the Keystone EC2 API and S3Token APIs, I want to propose deprecating these mechanisms of auth within Keystone at this time.

These systems have been historically poorly tested and supported and have remained broken / incompatible for long periods at a time. With the move that the EC2-API team is taking the code from nova out-of-tree, I would like to propose that the auth mechanisms are also moved out of tree and into the purview of the team focused on providing a solid EC2 compatibility layer for OpenStack.

This will allow the EC2-API team to better ensure the long term viability and compatibility of the required auth systems and can free this all from the requirement to propose code to keystone to handle forward momentum as required to support future/new signature versions and movement within the libraries that rely on clear AWS compatibility.

This should ideally be moved to something standalone that can handle the translation of EC2 or S3Token Auth to native Keystone api calls.

Thanks for reading,
--Morgan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160205/318eb1f6/attachment.html>


More information about the OpenStack-dev mailing list