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
