Open Stack

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
-------------- 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/3ba81a4e/attachment.bin>