Does Swift3 (for S3 on SWIFT) need Keystone or is it independent ? Tim
On 05/02/16 20:57, "Andrey Pavlov" <andrey...@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.b...@cern.ch> wrote: >> >> >> >> >> >> On 05/02/16 20:15, "Andrey Pavlov" <andrey...@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.math...@gmail.com> >>>wrote: >>>> >>>> On Fri, Feb 5, 2016 at 12:37 PM, Andrey Pavlov <andrey...@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.b...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
smime.p7s
Description: S/MIME cryptographic signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
