Open Stack

Hi Maru,

I probably can land something by tomorrow or thursday and we can see what
the keystone peoples would want to do with it. since this part of the code
don't affect much keystone core, I have hope this could land before essex
release.

The main problem was that it needed a bit of shuffling around so I wanted
to implement that only for Folsom.

IMO the swift_auth middleware is still usable as it is, having public
container is a use-case but not the most important one.

Cheers,
Chmouel.

On Tue, Mar 20, 2012 at 10:18 PM, Maru Newby <mnewby at internap.com> wrote:

> Hi Chmouel,
>
> Skipping for now is pragmatic, but I'd definitely want to implement stubs
> after your change lands to ensure that unit tests always run.
>
> I vote for implementing support for unauthenticated access asap.
>  Anonymous access to Swift is a very important use case, and not having it
> means that  Keystone's swift middleware is not usable as-is.  Deployers
> will have to implement and maintain that functionality themselves until
> this is resolved.  What will it take to have it go in for this release?
>
> Thanks,
>
>
> Maru
>
> On 2012-03-20, at 2:43 AM, Chmouel Boudjnah wrote:
>
> > Hi Maru,
> >
> > Sorry I have been taking long to come to you on this, I have revived
> > review  4529[1] which add the swift tests. I was talking to termie
> > about it sometime ago and the way we decided to do is to skip the
> > tests if Swift is not installed[2]. Feel free to add stubs as this is
> > not ideal.
> >
> > I was working as well on container-sync and anonymous requests but was
> > not sure if this should go in for Folsom or for this release.
> >
> > Cheers,
> > Chmouel.
> >
> > [1] https://review.openstack.org/#change,4529
> > [2] Ideally I would love to have swift.common.*/swiftclient go to
> > another package but that's probably a discussion for Folsom summit.
> >
> > On Tue, Mar 20, 2012 at 3:33 AM, Maru Newby <mnewby at internap.com> wrote:
> >> I'd like to write unit tests for keystone.middleware.swift_auth in
> advance of some functional changes (adding support for unauthenticated
> container sync and referrer access).  It appears that swift_auth lacks unit
> tests, though.  Is this due to its dependency on swift, or is there another
> reason?
> >>
> >> Given that untested code is difficult to maintain, what would the best
> option be to add tests for swift_auth?  Ideally the module would just move
> to the swift repo, but if for some reason that's not an option, I'm
> prepared to use stubs.
> >>
> >> Thanks,
> >>
> >>
> >> Maru
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~openstack
> >> Post to     : openstack at lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~openstack
> >> More help   : https://help.launchpad.net/ListHelp
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120320/629ec282/attachment.html>