Hi Suchi, I am not sure I understand your email, is your question says if temp_url work with the keystone middleware? the answer would be no as the middleware does not implement the allow_overrides feature to allow such thing.
Please feel free to log a bug in launchpad. Cheers, Chmouel. On Mon, May 14, 2012 at 8:19 PM, Suchi Sinha (susinha) <susi...@cisco.com> wrote: > Does it work with keystone? I am trying to test this feature. > Follow all your steps.. Always getting "No such file or directory" > > Here how I am accessing > > https://IP:8080/v1/AUTH_74a6a2e705e74158bda736f5c8c6c89d/android/droidfi > le.jpg?temp_url_sig=97fbcdba9be019c6d76dcf4d8079e66436c9d557&temp_url_ex > pires=1337025081 > > getting this error > > https://IP:8080/v1/AUTH_74a6a2e705e74158bda736f5c8c6c89d/android/droidfi > le.jpg?temp_url_sig=97fbcdba9be019c6d76dcf4d8079e66436c9d557: No such > file or directory > > > Do I need to setup anything to support this feature? > > Thanks > ~Suchi > > > -----Original Message----- > From: openstack-bounces+susinha=cisco....@lists.launchpad.net > [mailto:openstack-bounces+susinha=cisco....@lists.launchpad.net] On > Behalf Of John Dickinson > Sent: Friday, May 04, 2012 11:57 AM > To: openstack (openstack@lists.launchpad.net) > Subject: [Openstack] [Swift] swift news and plans > > TL;DR: removing code from swift, associated projects doc, swift 1.5.0 > > I want to let the openstack community know of some recent changes within > swift and how those changes will affect the next version of swift. Swift > has a growing developer community and a rapidly expanding deployed base. > While this growth is fantastic, it does come with new challenges, > especially for the swift core developers. As more and varied use cases > are presented to swift, patches are submitted that enhance swift's > functionality either by offering optional features or alternative APIs. > > The challenge with this growth is that the core developers become > responsible for understanding and maintaining an ever-increasing > codebase. This responsibility becomes a timesink, both for reviews and > for fixing regression bugs as new core features are added. For non-core > developers, the review process for new code becomes slower, and changes > that don't affect swift's core functionality often fall to the bottom of > the pile--sometimes even to the point of expiring due to inactivity. > > Our solution for these problems is to limit the scope of swift. Swift's > core functionality is to provide cheap, durable, and scalable object > storage exposed through its own API. Other functionality and alternative > APIs should be maintained separately from the swift codebase. > > As a result of this focus in scope, we have begun removing some of the > optional parts of swift. Initially, this will include the tempurl, > formpost, staticweb, rate limiting, swift3, domain remap, and cname > lookup middleware modules. Proposed patches that offer alternative APIs > (like CDMI) or include optional functionality that can be implemented > external to swift will be encouraged to be developed separately from > swift. > > We have already begun the process of removing many of these pieces of > middleware from swift and moving them into their own respective repos. > > However, all of this functionality is quite valuable and beneficial to > swift. > There is a real need for most of these modules. Separating them from > swift introduces the problem of discoverability. As a result, we have > added a new page to our swift docs that lists associated projects and > added links to that page on swift.openstack.org. > > http://swift.openstack.org/associated_projects.html > > This page is fairly limited right now, but the basic structure is there. > As things are removed from swift and as new associated projects are > created, they will be added to the list. This doc page is maintained in > the swift codebase, so updating it is subject to the same requirements > of any other patch to swift. > > An important note is that this list offers no distinction or references > to "official" or "approved" associated projects. This list is > independent of any openstack CI integration that may or may not happen > in the future. > > Once we finish the process of migrating the optional pieces of swift > away from the swift codebase, we will cut our next release: swift 1.5.0. > There is no date set for this yet, but I hope the migration process can > be finished in the next several weeks. Swift 1.5.0, therefore, will be > somewhat larger than most of our other swift releases. Existing > deployers will need to be careful about upgrading to ensure that new > dependencies are met. > > If you have any questions, please feel free to email me. This whole > effort is a work-in-progress. I know that there are several similar > discussions going on within the openstack community, and swift's > solution is not necessarily intended to replace any more general > solution that may eventually arise. If there is a better solution at > some point, we will do what we can to integrate with it. > > --John > > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
