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

[Kota TSUYUZAKI]

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.b...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Morgan Fainberg]

On Sat, Feb 6, 2016 at 11:06 AM, Tim Bell <tim.b...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Morgan Fainberg]

On Feb 5, 2016 20:42, "Andrey Pavlov"  wrote:
>
> Tim,
>
> swift3 calls keystone for authentication (in similar way as ec2api)
>
> Andrey.
>
> On Fri, Feb 5, 2016 at 11:51 PM, Tim Bell  wrote:
> > Does Swift3 (for S3 on SWIFT) need Keystone or is it independent ?
> >
> > Tim
> >
> >
> >
> > On 05/02/16 20:57, "Andrey Pavlov"  wrote:
> >
> >>As I know 'swift3' project implements S3 for OpenStack over swift. Or
> >>your mention something other?
> >>(but it doesn't support some features - signature v4 for instance)
> >>
> >>Andrey.
> >>
> >>On Fri, Feb 5, 2016 at 10:46 PM, Tim Bell  wrote:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On 05/02/16 20:15, "Andrey Pavlov"  wrote:
> >>>
> Can it be implemented as keystone plugin?
> Is it possible to 'get' AUTH_TOKEN outside of keystone?
> Will this code use keystone DB or it should create own?
> 
> So we will need one 'auth' module for swift3/ec2-api.
> Sounds good but we need to understand some details before
implementation.
> 
> On Fri, Feb 5, 2016 at 10:03 PM, Dolph Mathews <
dolph.math...@gmail.com> wrote:
> >
> > On Fri, Feb 5, 2016 at 12:37 PM, Andrey Pavlov 
wrote:
> >>
> >> swift3(s3) works like ec2-api.
> >>
> >> 1. swift3/ec2-api recieves AWS request
> >> 2. it parses signature and access_key (and other headers)
> >> 3. it sends these values (and token that calculated from request)
to
> >> keystone
> >> 4. keystone gets secret_key from DB, then calculates signature by
> >> recieved access_key and token
> >> 5. keystone compares recived signature and claculated signature and
> >> then return 'error' or auth_token
> >> 6. swift3/ec2-api recieves answer from keystone and return
'forbidden'
> >> or continues execution
> >> 7. in case of continue swift3/ec2-api uses recieved auth_token for
> >> calls other services: nova, cinder, neutron, swift...
> >>
> >> So I don't understand how implement this functionality outside of
> >> keystone...
> >
> >
> > EC2 support is implemented in middleware on top of keystone, and
that
> > middleware happens to live in the openstack/keystone repository.
This change
> > is just proposing to move that middleware code into a dedicated new
> > repository and change the community support & maintenance model -
it would
> > not affect how the code actually operates. The only affect on
operators is
> > that it would require an extra step to deploy it. End users would
not be
> > affected.
> >
> >
https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/keystone/contrib/ec2/routers.py#L27
> >
> >
https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/etc/keystone-paste.ini#L27-L31
> >>>
> >>>
> >>> However, looking at the current state of deployments, the EC2-API is
close to production ready, CERN has been working with the community to get
an RPM package and a Puppet module for configuring it at scale.
> >>>
> >>> In comparison, the equivalent S3 support would need some further
effort to develop an S3-API project, package and configure it. Given the
CERN EC2 experience, this is several months of work.
> >>>
> >>> Thus, I have no problem with a message saying this function is on the
way out but there is currently no equivalent function for S3 support (or
project ownership to implement it). I would advise to address these
questions before we start on the road to deprecation on the same time
scales as the EC2 functions.
> >>>
> >>> Removing function without a migration/alternative would be unpopular
with the user community. According to
http://superuser.openstack.org/articles/openstack-users-share-how-their-deployments-stack-up,
around 29% of production sites use S3. Personally, that feels a bit high
but it does give an indication of the deployment level.
> >>>
> >>> How about we split the EC2 deprecation from the S3 one ?
> >>>
> >>> Tim
> >>>
> >>>
> >
> >>
> >>
> >> On Fri, Feb 5, 2016 at 8:55 PM, Tim Bell  wrote:
> >> >
> >> >>
> >> >> 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.
> >> >>
> >> >
> >> > This would be just a deprecation warning. Removal would be
determined at
> >> > a
> >> > later time with sufficient lead time.
> >> >
> >> > Do you know how S3 with SWIFT works ? Would they need to do
something
> >> > like
> >> > EC2-API ?
> >> >

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

[Andrey Pavlov]

As I know 'swift3' project implements S3 for OpenStack over swift. Or
your mention something other?
(but it doesn't support some features - signature v4 for instance)

Andrey.

On Fri, Feb 5, 2016 at 10:46 PM, Tim Bell  wrote:
>
>
>
>
>
> On 05/02/16 20:15, "Andrey Pavlov"  wrote:
>
>>Can it be implemented as keystone plugin?
>>Is it possible to 'get' AUTH_TOKEN outside of keystone?
>>Will this code use keystone DB or it should create own?
>>
>>So we will need one 'auth' module for swift3/ec2-api.
>>Sounds good but we need to understand some details before implementation.
>>
>>On Fri, Feb 5, 2016 at 10:03 PM, Dolph Mathews  
>>wrote:
>>>
>>> On Fri, Feb 5, 2016 at 12:37 PM, Andrey Pavlov  wrote:

 swift3(s3) works like ec2-api.

 1. swift3/ec2-api recieves AWS request
 2. it parses signature and access_key (and other headers)
 3. it sends these values (and token that calculated from request) to
 keystone
 4. keystone gets secret_key from DB, then calculates signature by
 recieved access_key and token
 5. keystone compares recived signature and claculated signature and
 then return 'error' or auth_token
 6. swift3/ec2-api recieves answer from keystone and return 'forbidden'
 or continues execution
 7. in case of continue swift3/ec2-api uses recieved auth_token for
 calls other services: nova, cinder, neutron, swift...

 So I don't understand how implement this functionality outside of
 keystone...
>>>
>>>
>>> EC2 support is implemented in middleware on top of keystone, and that
>>> middleware happens to live in the openstack/keystone repository. This change
>>> is just proposing to move that middleware code into a dedicated new
>>> repository and change the community support & maintenance model - it would
>>> not affect how the code actually operates. The only affect on operators is
>>> that it would require an extra step to deploy it. End users would not be
>>> affected.
>>>
>>> https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/keystone/contrib/ec2/routers.py#L27
>>>
>>> https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/etc/keystone-paste.ini#L27-L31
>
>
> However, looking at the current state of deployments, the EC2-API is close to 
> production ready, CERN has been working with the community to get an RPM 
> package and a Puppet module for configuring it at scale.
>
> In comparison, the equivalent S3 support would need some further effort to 
> develop an S3-API project, package and configure it. Given the CERN EC2 
> experience, this is several months of work.
>
> Thus, I have no problem with a message saying this function is on the way out 
> but there is currently no equivalent function for S3 support (or project 
> ownership to implement it). I would advise to address these questions before 
> we start on the road to deprecation on the same time scales as the EC2 
> functions.
>
> Removing function without a migration/alternative would be unpopular with the 
> user community. According to 
> http://superuser.openstack.org/articles/openstack-users-share-how-their-deployments-stack-up,
>  around 29% of production sites use S3. Personally, that feels a bit high but 
> it does give an indication of the deployment level.
>
> How about we split the EC2 deprecation from the S3 one ?
>
> Tim
>
>
>>>


 On Fri, Feb 5, 2016 at 8:55 PM, Tim Bell  wrote:
 >
 >>
 >> 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.
 >>
 >
 > This would be just a deprecation warning. Removal would be determined at
 > a
 > later time with sufficient lead time.
 >
 > Do you know how S3 with SWIFT works ? Would they need to do something
 > like
 > EC2-API ?
 >
 > Tim
 >
 >
 > __
 > 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
 >



 --
 Kind regards,
 Andrey Pavlov.

 __
 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
>>>
>>>
>>>
>>> 

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

[Tim Bell]

Does Swift3 (for S3 on SWIFT) need Keystone or is it independent ?

Tim



On 05/02/16 20:57, "Andrey Pavlov"  wrote:

>As I know 'swift3' project implements S3 for OpenStack over swift. Or
>your mention something other?
>(but it doesn't support some features - signature v4 for instance)
>
>Andrey.
>
>On Fri, Feb 5, 2016 at 10:46 PM, Tim Bell  wrote:
>>
>>
>>
>>
>>
>> On 05/02/16 20:15, "Andrey Pavlov"  wrote:
>>
>>>Can it be implemented as keystone plugin?
>>>Is it possible to 'get' AUTH_TOKEN outside of keystone?
>>>Will this code use keystone DB or it should create own?
>>>
>>>So we will need one 'auth' module for swift3/ec2-api.
>>>Sounds good but we need to understand some details before implementation.
>>>
>>>On Fri, Feb 5, 2016 at 10:03 PM, Dolph Mathews  
>>>wrote:

 On Fri, Feb 5, 2016 at 12:37 PM, Andrey Pavlov  wrote:
>
> swift3(s3) works like ec2-api.
>
> 1. swift3/ec2-api recieves AWS request
> 2. it parses signature and access_key (and other headers)
> 3. it sends these values (and token that calculated from request) to
> keystone
> 4. keystone gets secret_key from DB, then calculates signature by
> recieved access_key and token
> 5. keystone compares recived signature and claculated signature and
> then return 'error' or auth_token
> 6. swift3/ec2-api recieves answer from keystone and return 'forbidden'
> or continues execution
> 7. in case of continue swift3/ec2-api uses recieved auth_token for
> calls other services: nova, cinder, neutron, swift...
>
> So I don't understand how implement this functionality outside of
> keystone...


 EC2 support is implemented in middleware on top of keystone, and that
 middleware happens to live in the openstack/keystone repository. This 
 change
 is just proposing to move that middleware code into a dedicated new
 repository and change the community support & maintenance model - it would
 not affect how the code actually operates. The only affect on operators is
 that it would require an extra step to deploy it. End users would not be
 affected.

 https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/keystone/contrib/ec2/routers.py#L27

 https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/etc/keystone-paste.ini#L27-L31
>>
>>
>> However, looking at the current state of deployments, the EC2-API is close 
>> to production ready, CERN has been working with the community to get an RPM 
>> package and a Puppet module for configuring it at scale.
>>
>> In comparison, the equivalent S3 support would need some further effort to 
>> develop an S3-API project, package and configure it. Given the CERN EC2 
>> experience, this is several months of work.
>>
>> Thus, I have no problem with a message saying this function is on the way 
>> out but there is currently no equivalent function for S3 support (or project 
>> ownership to implement it). I would advise to address these questions before 
>> we start on the road to deprecation on the same time scales as the EC2 
>> functions.
>>
>> Removing function without a migration/alternative would be unpopular with 
>> the user community. According to 
>> http://superuser.openstack.org/articles/openstack-users-share-how-their-deployments-stack-up,
>>  around 29% of production sites use S3. Personally, that feels a bit high 
>> but it does give an indication of the deployment level.
>>
>> How about we split the EC2 deprecation from the S3 one ?
>>
>> Tim
>>
>>

>
>
> On Fri, Feb 5, 2016 at 8:55 PM, Tim Bell  wrote:
> >
> >>
> >> 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.
> >>
> >
> > This would be just a deprecation warning. Removal would be determined at
> > a
> > later time with sufficient lead time.
> >
> > Do you know how S3 with SWIFT works ? Would they need to do something
> > like
> > EC2-API ?
> >
> > Tim
> >
> >
> > __
> > 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
> >
>
>
>
> --
> Kind regards,
> Andrey Pavlov.
>
> 

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

[Tim Bell]

On 05/02/16 20:15, "Andrey Pavlov"  wrote:

>Can it be implemented as keystone plugin?
>Is it possible to 'get' AUTH_TOKEN outside of keystone?
>Will this code use keystone DB or it should create own?
>
>So we will need one 'auth' module for swift3/ec2-api.
>Sounds good but we need to understand some details before implementation.
>
>On Fri, Feb 5, 2016 at 10:03 PM, Dolph Mathews  wrote:
>>
>> On Fri, Feb 5, 2016 at 12:37 PM, Andrey Pavlov  wrote:
>>>
>>> swift3(s3) works like ec2-api.
>>>
>>> 1. swift3/ec2-api recieves AWS request
>>> 2. it parses signature and access_key (and other headers)
>>> 3. it sends these values (and token that calculated from request) to
>>> keystone
>>> 4. keystone gets secret_key from DB, then calculates signature by
>>> recieved access_key and token
>>> 5. keystone compares recived signature and claculated signature and
>>> then return 'error' or auth_token
>>> 6. swift3/ec2-api recieves answer from keystone and return 'forbidden'
>>> or continues execution
>>> 7. in case of continue swift3/ec2-api uses recieved auth_token for
>>> calls other services: nova, cinder, neutron, swift...
>>>
>>> So I don't understand how implement this functionality outside of
>>> keystone...
>>
>>
>> EC2 support is implemented in middleware on top of keystone, and that
>> middleware happens to live in the openstack/keystone repository. This change
>> is just proposing to move that middleware code into a dedicated new
>> repository and change the community support & maintenance model - it would
>> not affect how the code actually operates. The only affect on operators is
>> that it would require an extra step to deploy it. End users would not be
>> affected.
>>
>> https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/keystone/contrib/ec2/routers.py#L27
>>
>> https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/etc/keystone-paste.ini#L27-L31


However, looking at the current state of deployments, the EC2-API is close to 
production ready, CERN has been working with the community to get an RPM 
package and a Puppet module for configuring it at scale.

In comparison, the equivalent S3 support would need some further effort to 
develop an S3-API project, package and configure it. Given the CERN EC2 
experience, this is several months of work.

Thus, I have no problem with a message saying this function is on the way out 
but there is currently no equivalent function for S3 support (or project 
ownership to implement it). I would advise to address these questions before we 
start on the road to deprecation on the same time scales as the EC2 functions. 

Removing function without a migration/alternative would be unpopular with the 
user community. According to 
http://superuser.openstack.org/articles/openstack-users-share-how-their-deployments-stack-up,
 around 29% of production sites use S3. Personally, that feels a bit high but 
it does give an indication of the deployment level.

How about we split the EC2 deprecation from the S3 one ?

Tim


>>
>>>
>>>
>>> On Fri, Feb 5, 2016 at 8:55 PM, Tim Bell  wrote:
>>> >
>>> >>
>>> >> 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.
>>> >>
>>> >
>>> > This would be just a deprecation warning. Removal would be determined at
>>> > a
>>> > later time with sufficient lead time.
>>> >
>>> > Do you know how S3 with SWIFT works ? Would they need to do something
>>> > like
>>> > EC2-API ?
>>> >
>>> > Tim
>>> >
>>> >
>>> > __
>>> > 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
>>> >
>>>
>>>
>>>
>>> --
>>> Kind regards,
>>> Andrey Pavlov.
>>>
>>> __
>>> 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
>>
>>
>>
>> __
>> 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
>>
>
>
>
>-- 
>Kind regards,
>Andrey Pavlov.
>
>__

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

[Andrey Pavlov]

Tim,

swift3 calls keystone for authentication (in similar way as ec2api)

Andrey.

On Fri, Feb 5, 2016 at 11:51 PM, Tim Bell  wrote:
> Does Swift3 (for S3 on SWIFT) need Keystone or is it independent ?
>
> Tim
>
>
>
> On 05/02/16 20:57, "Andrey Pavlov"  wrote:
>
>>As I know 'swift3' project implements S3 for OpenStack over swift. Or
>>your mention something other?
>>(but it doesn't support some features - signature v4 for instance)
>>
>>Andrey.
>>
>>On Fri, Feb 5, 2016 at 10:46 PM, Tim Bell  wrote:
>>>
>>>
>>>
>>>
>>>
>>> On 05/02/16 20:15, "Andrey Pavlov"  wrote:
>>>
Can it be implemented as keystone plugin?
Is it possible to 'get' AUTH_TOKEN outside of keystone?
Will this code use keystone DB or it should create own?

So we will need one 'auth' module for swift3/ec2-api.
Sounds good but we need to understand some details before implementation.

On Fri, Feb 5, 2016 at 10:03 PM, Dolph Mathews  
wrote:
>
> On Fri, Feb 5, 2016 at 12:37 PM, Andrey Pavlov  
> wrote:
>>
>> swift3(s3) works like ec2-api.
>>
>> 1. swift3/ec2-api recieves AWS request
>> 2. it parses signature and access_key (and other headers)
>> 3. it sends these values (and token that calculated from request) to
>> keystone
>> 4. keystone gets secret_key from DB, then calculates signature by
>> recieved access_key and token
>> 5. keystone compares recived signature and claculated signature and
>> then return 'error' or auth_token
>> 6. swift3/ec2-api recieves answer from keystone and return 'forbidden'
>> or continues execution
>> 7. in case of continue swift3/ec2-api uses recieved auth_token for
>> calls other services: nova, cinder, neutron, swift...
>>
>> So I don't understand how implement this functionality outside of
>> keystone...
>
>
> EC2 support is implemented in middleware on top of keystone, and that
> middleware happens to live in the openstack/keystone repository. This 
> change
> is just proposing to move that middleware code into a dedicated new
> repository and change the community support & maintenance model - it would
> not affect how the code actually operates. The only affect on operators is
> that it would require an extra step to deploy it. End users would not be
> affected.
>
> https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/keystone/contrib/ec2/routers.py#L27
>
> https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/etc/keystone-paste.ini#L27-L31
>>>
>>>
>>> However, looking at the current state of deployments, the EC2-API is close 
>>> to production ready, CERN has been working with the community to get an RPM 
>>> package and a Puppet module for configuring it at scale.
>>>
>>> In comparison, the equivalent S3 support would need some further effort to 
>>> develop an S3-API project, package and configure it. Given the CERN EC2 
>>> experience, this is several months of work.
>>>
>>> Thus, I have no problem with a message saying this function is on the way 
>>> out but there is currently no equivalent function for S3 support (or 
>>> project ownership to implement it). I would advise to address these 
>>> questions before we start on the road to deprecation on the same time 
>>> scales as the EC2 functions.
>>>
>>> Removing function without a migration/alternative would be unpopular with 
>>> the user community. According to 
>>> http://superuser.openstack.org/articles/openstack-users-share-how-their-deployments-stack-up,
>>>  around 29% of production sites use S3. Personally, that feels a bit high 
>>> but it does give an indication of the deployment level.
>>>
>>> How about we split the EC2 deprecation from the S3 one ?
>>>
>>> Tim
>>>
>>>
>
>>
>>
>> On Fri, Feb 5, 2016 at 8:55 PM, Tim Bell  wrote:
>> >
>> >>
>> >> 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.
>> >>
>> >
>> > This would be just a deprecation warning. Removal would be determined 
>> > at
>> > a
>> > later time with sufficient lead time.
>> >
>> > Do you know how S3 with SWIFT works ? Would they need to do something
>> > like
>> > EC2-API ?
>> >
>> > Tim
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> >