Open Stack

Tim,

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

Andrey.

On Fri, Feb 5, 2016 at 11:51 PM, Tim Bell <Tim.Bell at cern.ch> wrote:
> Does Swift3 (for S3 on SWIFT) need Keystone or is it independent ?
>
> Tim
>
>
>
> On 05/02/16 20:57, "Andrey Pavlov" <andrey.mp at gmail.com> 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 <Tim.Bell at cern.ch> wrote:
>>>
>>>
>>>
>>>
>>>
>>> On 05/02/16 20:15, "Andrey Pavlov" <andrey.mp at gmail.com> 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.mathews at gmail.com> wrote:
>>>>>
>>>>> On Fri, Feb 5, 2016 at 12:37 PM, Andrey Pavlov <andrey.mp at gmail.com> 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 <Tim.Bell at cern.ch> 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-request at 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-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
>>>>>
>>>>
>>>>
>>>>
>>>>--
>>>>Kind regards,
>>>>Andrey Pavlov.
>>>>
>>>>__________________________________________________________________________
>>>>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
>>>
>>
>>
>>
>>--
>>Kind regards,
>>Andrey Pavlov.
>>
>>__________________________________________________________________________
>>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
>



-- 
Kind regards,
Andrey Pavlov.