Open Stack

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.