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.fainb...@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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to