<p dir="ltr"><br>
On Feb 5, 2016 20:42, "Andrey Pavlov" <<a href="mailto:andrey.mp@gmail.com">andrey.mp@gmail.com</a>> wrote:<br>
><br>
> Tim,<br>
><br>
> swift3 calls keystone for authentication (in similar way as ec2api)<br>
><br>
> Andrey.<br>
><br>
> On Fri, Feb 5, 2016 at 11:51 PM, Tim Bell <<a href="mailto:Tim.Bell@cern.ch">Tim.Bell@cern.ch</a>> wrote:<br>
> > Does Swift3 (for S3 on SWIFT) need Keystone or is it independent ?<br>
> ><br>
> > Tim<br>
> ><br>
> ><br>
> ><br>
> > On 05/02/16 20:57, "Andrey Pavlov" <<a href="mailto:andrey.mp@gmail.com">andrey.mp@gmail.com</a>> wrote:<br>
> ><br>
> >>As I know 'swift3' project implements S3 for OpenStack over swift. Or<br>
> >>your mention something other?<br>
> >>(but it doesn't support some features - signature v4 for instance)<br>
> >><br>
> >>Andrey.<br>
> >><br>
> >>On Fri, Feb 5, 2016 at 10:46 PM, Tim Bell <<a href="mailto:Tim.Bell@cern.ch">Tim.Bell@cern.ch</a>> wrote:<br>
> >>><br>
> >>><br>
> >>><br>
> >>><br>
> >>><br>
> >>> On 05/02/16 20:15, "Andrey Pavlov" <<a href="mailto:andrey.mp@gmail.com">andrey.mp@gmail.com</a>> wrote:<br>
> >>><br>
> >>>>Can it be implemented as keystone plugin?<br>
> >>>>Is it possible to 'get' AUTH_TOKEN outside of keystone?<br>
> >>>>Will this code use keystone DB or it should create own?<br>
> >>>><br>
> >>>>So we will need one 'auth' module for swift3/ec2-api.<br>
> >>>>Sounds good but we need to understand some details before implementation.<br>
> >>>><br>
> >>>>On Fri, Feb 5, 2016 at 10:03 PM, Dolph Mathews <<a href="mailto:dolph.mathews@gmail.com">dolph.mathews@gmail.com</a>> wrote:<br>
> >>>>><br>
> >>>>> On Fri, Feb 5, 2016 at 12:37 PM, Andrey Pavlov <<a href="mailto:andrey.mp@gmail.com">andrey.mp@gmail.com</a>> wrote:<br>
> >>>>>><br>
> >>>>>> swift3(s3) works like ec2-api.<br>
> >>>>>><br>
> >>>>>> 1. swift3/ec2-api recieves AWS request<br>
> >>>>>> 2. it parses signature and access_key (and other headers)<br>
> >>>>>> 3. it sends these values (and token that calculated from request) to<br>
> >>>>>> keystone<br>
> >>>>>> 4. keystone gets secret_key from DB, then calculates signature by<br>
> >>>>>> recieved access_key and token<br>
> >>>>>> 5. keystone compares recived signature and claculated signature and<br>
> >>>>>> then return 'error' or auth_token<br>
> >>>>>> 6. swift3/ec2-api recieves answer from keystone and return 'forbidden'<br>
> >>>>>> or continues execution<br>
> >>>>>> 7. in case of continue swift3/ec2-api uses recieved auth_token for<br>
> >>>>>> calls other services: nova, cinder, neutron, swift...<br>
> >>>>>><br>
> >>>>>> So I don't understand how implement this functionality outside of<br>
> >>>>>> keystone...<br>
> >>>>><br>
> >>>>><br>
> >>>>> EC2 support is implemented in middleware on top of keystone, and that<br>
> >>>>> middleware happens to live in the openstack/keystone repository. This change<br>
> >>>>> is just proposing to move that middleware code into a dedicated new<br>
> >>>>> repository and change the community support & maintenance model - it would<br>
> >>>>> not affect how the code actually operates. The only affect on operators is<br>
> >>>>> that it would require an extra step to deploy it. End users would not be<br>
> >>>>> affected.<br>
> >>>>><br>
> >>>>> <a href="https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/keystone/contrib/ec2/routers.py#L27">https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/keystone/contrib/ec2/routers.py#L27</a><br>
> >>>>><br>
> >>>>> <a href="https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/etc/keystone-paste.ini#L27-L31">https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/etc/keystone-paste.ini#L27-L31</a><br>
> >>><br>
> >>><br>
> >>> 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.<br>
> >>><br>
> >>> 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.<br>
> >>><br>
> >>> 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.<br>
> >>><br>
> >>> Removing function without a migration/alternative would be unpopular with the user community. According to <a href="http://superuser.openstack.org/articles/openstack-users-share-how-their-deployments-stack-up">http://superuser.openstack.org/articles/openstack-users-share-how-their-deployments-stack-up</a>, around 29% of production sites use S3. Personally, that feels a bit high but it does give an indication of the deployment level.<br>
> >>><br>
> >>> How about we split the EC2 deprecation from the S3 one ?<br>
> >>><br>
> >>> Tim<br>
> >>><br>
> >>><br>
> >>>>><br>
> >>>>>><br>
> >>>>>><br>
> >>>>>> On Fri, Feb 5, 2016 at 8:55 PM, Tim Bell <<a href="mailto:Tim.Bell@cern.ch">Tim.Bell@cern.ch</a>> wrote:<br>
> >>>>>> ><br>
> >>>>>> >><br>
> >>>>>> >> Is it certain that there is no need for the functions with the new<br>
> >>>>>> >> EC2-API<br>
> >>>>>> >> functions ?<br>
> >>>>>> >><br>
> >>>>>> >> The S3 functions are somewhat separated from the EC2 API. How does<br>
> >>>>>> >> SWIFT<br>
> >>>>>> >> implement the S3 compatibility layer ?<br>
> >>>>>> >><br>
> >>>>>> >> Getting a ‘to be deprecated’ log entry into Mitaka would be useful to<br>
> >>>>>> >> make<br>
> >>>>>> >> sure we’re not using it somewhere else.<br>
> >>>>>> >><br>
> >>>>>> ><br>
> >>>>>> > This would be just a deprecation warning. Removal would be determined at<br>
> >>>>>> > a<br>
> >>>>>> > later time with sufficient lead time.<br>
> >>>>>> ><br>
> >>>>>> > Do you know how S3 with SWIFT works ? Would they need to do something<br>
> >>>>>> > like<br>
> >>>>>> > EC2-API ?<br>
> >>>>>> ><br>
> >>>>>> > Tim<br>
> >>>>>> ><br>
> >>>>>> ><br>
> >>>>>> > __________________________________________________________________________<br>
> >>>>>> > OpenStack Development Mailing List (not for usage questions)<br>
> >>>>>> > Unsubscribe:<br>
> >>>>>> > <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> >>>>>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >>>>>> ><br>
> >>>>>><br>
> >>>>>><br>
> >>>>>><br>
> >>>>>> --<br>
> >>>>>> Kind regards,<br>
> >>>>>> Andrey Pavlov.<br>
> >>>>>><br>
> >>>>>> __________________________________________________________________________<br>
> >>>>>> OpenStack Development Mailing List (not for usage questions)<br>
> >>>>>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> >>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >>>>><br>
> >>>>><br>
> >>>>><br>
> >>>>> __________________________________________________________________________<br>
> >>>>> OpenStack Development Mailing List (not for usage questions)<br>
> >>>>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> >>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >>>>><br>
> >>>><br>
> >>>><br>
> >>>><br>
> >>>>--<br>
> >>>>Kind regards,<br>
> >>>>Andrey Pavlov.<br>
> >>>><br>
> >>>>__________________________________________________________________________<br>
> >>>>OpenStack Development Mailing List (not for usage questions)<br>
> >>>>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> >>>><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >>><br>
> >>> __________________________________________________________________________<br>
> >>> OpenStack Development Mailing List (not for usage questions)<br>
> >>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> >>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >>><br>
> >><br>
> >><br>
> >><br>
> >>--<br>
> >>Kind regards,<br>
> >>Andrey Pavlov.<br>
> >><br>
> >>__________________________________________________________________________<br>
> >>OpenStack Development Mailing List (not for usage questions)<br>
> >>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> >><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
> > __________________________________________________________________________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
><br>
><br>
><br>
> --<br>
> Kind regards,<br>
> Andrey Pavlov.<br>
><br>
></p>
<p dir="ltr">So based on this conversation and the need to support the legal requirement of some deployers to totally strip the code from the install, I've taken another approach. The base controller will emit a 403 (Forbidden) if the core of the compat code is not available for import. If the legal demands (corp.legal) change for the org that requires the ease of removing the compat code changes, we will remove the fallback to the hard 403 response if the code is still in Keystone's tree. This type of fallback will be handled only for the aws compat code since the legal requirements have been relying on this , I do not expect this pattern to be expanded beyond this specific AWS compat code in keystone.</p>
<p dir="ltr">The move to deprecate and move this into the hands of the ec2api team will continue to be discussed so we can hammer out details making sure we don't break apps relying on the aws compat apis. Long term I fully expect this to not be in Keystone's tree. </p>
<p dir="ltr">--M<br>
</p>