Open Stack

Hello guys,

S3 compatibility API is now maitained in openstack namespace, it is in the external repository from original Swift though.
It works as Swift proxy middleware to translate S3 api into pure Swift api. While the translation, Swift3 makes a credential to retrieve actual auth token from keystone
(this works in s3_token middleware) and the credential is compatible with tempauth. (reference auth middleware maintained in Swift)

If the credential api in s3_token deprecated in keystonemiddleware, it will be hard to maintain the semantics with pure swift authentication system.

I'm not sure I followed up this conversation completely but hopefully I wonder if you give me more infomation (e.g. Why do we need this, how do we improve/migrate this) about this


Thanks,
Kota

1: https://github.com/openstack/swift3

(2016/02/07 9:02), Morgan Fainberg wrote:
> On Sat, Feb 6, 2016 at 11:06 AM, Tim Bell <Tim.Bell at cern.ch> wrote:
> 
>>
>> I support the move to deprecate but I don’t think the EC2API people should
>> be responsible for the S3 compatibility. This would seem to need an S3API
>> project (working with the SWIFT folk to do a smooth migration).
>>
>> Tim
>>
>>
> All on the table for discussion - right now the S3Token code relies on the
> EC2 API code in Keystone, so they cannot be separated without more work.
> We'll work on this in either case and figure the best way going forward.
> 
> Cheers,
> --Morgan
> 
> 
>> From: Morgan Fainberg
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> Date: Saturday 6 February 2016 at 17:57
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> Subject: Re: [openstack-dev] [keystone][ec2-api][swift] Moving EC2 Auth
>> and S3Token to Externally supported
>>
>> So based on this conversation and the need to support the legal
>> requirement of some deployers to totally strip the code from the install,
>> I've taken another approach. The base controller will emit a 403
>> (Forbidden) if the core of the compat code is not available for import. If
>> the legal demands (corp.legal) change for the org that requires the ease of
>> removing the compat code changes, we will remove the fallback to the hard
>> 403 response if the code is still in Keystone's tree. This type of fallback
>> will be handled only for the aws compat code since the legal requirements
>> have been relying on this , I do not expect this pattern to be expanded
>> beyond this specific AWS compat code in keystone.
>>
>> The move to deprecate and move this into the hands of the ec2api team will
>> continue to be discussed so we can hammer out details making sure we don't
>> break apps relying on the aws compat apis. Long term I fully expect this to
>> not be in Keystone's tree.
>>
>> --M
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> 
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>