Open Stack

On Feb 5, 2016 20:42, "Andrey Pavlov" <andrey.mp at gmail.com> wrote:
>
> Tim,
>
> swift3 calls keystone for authentication (in similar way as ec2api)
>
> Andrey.
>
> On Fri, Feb 5, 2016 at 11:51 PM, Tim Bell <Tim.Bell at cern.ch> wrote:
> > Does Swift3 (for S3 on SWIFT) need Keystone or is it independent ?
> >
> > Tim
> >
> >
> >
> > On 05/02/16 20:57, "Andrey Pavlov" <andrey.mp at 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.Bell at cern.ch> wrote:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On 05/02/16 20:15, "Andrey Pavlov" <andrey.mp at 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.mathews at gmail.com> wrote:
> >>>>>
> >>>>> On Fri, Feb 5, 2016 at 12:37 PM, Andrey Pavlov <andrey.mp at 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.Bell at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Kind regards,
> Andrey Pavlov.
>
>

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.

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.

--M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160206/f0ae0434/attachment.html>