Open Stack

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2792 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160205/2353c460/attachment.bin>