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
smime.p7s
Description: S/MIME cryptographic signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
