Tim, swift3 calls keystone for authentication (in similar way as ec2api)
Andrey. On Fri, Feb 5, 2016 at 11:51 PM, Tim Bell <[email protected]> wrote: > Does Swift3 (for S3 on SWIFT) need Keystone or is it independent ? > > Tim > > > > On 05/02/16 20:57, "Andrey Pavlov" <[email protected]> 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 <[email protected]> wrote: >>> >>> >>> >>> >>> >>> On 05/02/16 20:15, "Andrey Pavlov" <[email protected]> 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 <[email protected]> >>>>wrote: >>>>> >>>>> On Fri, Feb 5, 2016 at 12:37 PM, Andrey Pavlov <[email protected]> >>>>> 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 <[email protected]> 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: >>>>>> > [email protected]?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: >>>>>> [email protected]?subject:unsubscribe >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> >>>>> >>>>> __________________________________________________________________________ >>>>> OpenStack Development Mailing List (not for usage questions) >>>>> Unsubscribe: [email protected]?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: [email protected]?subject:unsubscribe >>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: [email protected]?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: [email protected]?subject:unsubscribe >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
