> On Mar 12, 2015, at 12:48 PM, Jay Pipes <[email protected]> wrote: > > On 03/12/2015 03:08 PM, John Dickinson wrote: >> I'd like a little more info here. >> >> Is Horizon relying on the X-Timestamp header for reads (GET/HEAD)? If so, I >> think that's somewhat odd, but not hugely problematic. Swift has been >> returning an X-Timestamp header since patch b20264c9d3196 (which landed 3 >> years ago -- April 2012). > > OK, so there is a documentation bug here that X-Timestamp should be part of > the Swift REST API. It currently is not documented that X-Timestamp is a > non-optional HTTP Header, and therefore the RadosGW folks did not send > X-Timestamp headers back in the container response. > >> The X-Timestamp header is certainly part of the Swift API. It is required >> for container-sync functionality (implemented in early 2011) so that two >> clusters can communicate about the proper timestamp of the objects. > > OK. Sounds like an implementation detail leaking out of the API to me. In > other words, RadosGW (which is attempting to expose a Swift API in front of > Ceph backend storage) needs to expose this X-Timestamp header even if it > implements container-sync using an entirely difference mechanism... > >> I'm not sure if this actually matters for Horizon in this specific case. But >> it's certainly true that Swift requires and used the X-Timestamp header for >> implementing core functionality. Anyone talking to a Swift endpoint can >> assume that there is an X-Timestamp header in the response and use it as >> they see fit. > > Anyone talking to an upstream Swift *implementation* can assume that header > will be there :) But, the header is not actually documented in the Swift > *API* and therefore one cannot make this assumption. > > Thus the confusion. :)
I don't particularly agree with the characterization of the API and implementation as separate, but that's a "discussion" that's as old as openstack itself. (and we don't need to belabor it here.) :-) But yes, in my opinion, x-timestamp needs to be added to docs. > > Anyway, sounds like X-Timestamp should be documented as part of the official > Swift API. What about the X-Object-Meta-Mtime header in the related bug? > That, too, is problematic for a similar reason. Is that header part of the > Swift API as well? Anything prefixed by "X-Object-Meta-" is user metadata, ie completely arbitrary and set by an end user (same with x-container-meta-* and x-account-meta-*). From the context of Swift, I have zero semantic understanding of any key or value in that namespace. --John > > Best, > -jay > >> >> --John >> >> >> >> >>> On Mar 9, 2015, at 12:53 PM, Anne Gentle <[email protected]> >>> wrote: >>> >>> >>> >>> On Mon, Mar 9, 2015 at 2:32 PM, Matthew Farina <[email protected]> wrote: >>> David, >>> >>> FYI, the last time I chatted with John Dickinson I learned there are >>> numerous API elements not documented. Not meant to be private but the docs >>> have not kept up. How should we handle that? >>> >>> >>> I've read through this thread and the bug comments and searched through the >>> docs and I'd like more specifics: which docs have not kept up? Private API >>> docs for swift internal workings? Or is this a header that could be in >>> _some_ swift (not ceph) deployments? >>> >>> Thanks, >>> Anne >>> >>> >>> Thanks, >>> Matt Farina >>> >>> On Sat, Mar 7, 2015 at 5:25 PM, David Lyle <[email protected]> wrote: >>> I agree that Horizon should not be requiring optional headers. Changing >>> status of bug. >>> >>> On Tue, Mar 3, 2015 at 5:51 PM, Jay Pipes <[email protected]> wrote: >>> Added [swift] to topic. >>> >>> On 03/03/2015 07:41 AM, Matthew Farina wrote: >>> Radoslaw, >>> >>> Unfortunately the documentation for OpenStack has some holes. What you >>> are calling a private API may be something missed in the documentation. >>> Is there a documentation bug on the issue? If not one should be created. >>> >>> There is no indication that the X-Timestamp or X-Object-Meta-Mtime HTTP >>> headers are part of the public Swift API: >>> >>> http://developer.openstack.org/api-ref-objectstorage-v1.html >>> >>> I don't believe this is a bug in the Swift API documentation, either. John >>> Dickinson (cc'd) mentioned that the X-Timestamp HTTP header is required for >>> the Swift implementation of container replication (John, please do correct >>> me if wrong on that). >>> >>> But that is the private implementation and not part of the public API. >>> >>> In practice OpenStack isn't a specification and implementation. The >>> documentation has enough missing information you can't treat it this >>> way. If you want to contribute to improving the documentation I'm sure >>> the documentation team would appreciate it. The last time I looked there >>> were a number of undocumented public swift API details. >>> >>> The bug here is not in the documentation. The bug is that Horizon is coded >>> to rely on HTTP headers that are not in the Swift API. Horizon should be >>> fixed to use <DICT>.get('X-Timestamp') instead of doing >>> <DICT>['X-Timestamp'] in its view pages for container details. There are >>> already patches up that the Horizon developers have, IMO erroneously, >>> rejected stating this is a problem in Ceph RadosGW for not properly >>> following the Swift API). >>> >>> Best, >>> -jay >>> >>> Best of luck, >>> Matt Farina >>> >>> On Tue, Mar 3, 2015 at 9:59 AM, Radoslaw Zarzynski >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> Guys, >>> >>> I would like discuss a problem which can be seen in Horizon: breaking >>> the boundaries of public, well-specified Object Storage API in favour >>> of utilizing a Swift-specific extensions. Ticket #1297173 [1] may serve >>> as a good example of such violation. It is about relying on >>> non-standard (in the terms of OpenStack Object Storage API v1) and >>> undocumented HTTP header provided by Swift. In order to make >>> Ceph RADOS Gateway work correctly with Horizon, developers had to >>> inspect sources of Swift and implement the same behaviour. >>> >>> From my perspective, that practise breaks the the mission of OpenStack >>> which is much more than delivering yet another IaaS/PaaS implementation. >>> I think its main goal is to provide a universal set of APIs covering all >>> functional areas relevant for cloud computing, and to place that set >>> of APIs in front as many implementations as possible. Having an open >>> source reference implementation of a particular API is required to prove >>> its viability, but is secondary to having an open and documented API. >>> >>> I have full understanding that situations where the public OpenStack >>> interfaces are insufficient to get the work done might exist. >>> However, introduction of dependency on implementation-specific feature >>> (especially without giving the users a choice via e.g. some >>> configuration option) is not the proper way to deal with the problem. >>> From my point of view, such cases should be handled with adoption of >>> new, carefully designed and documented version of the given API. >>> >>> In any case I think that Horizon, at least basic functionality, should >>> work with any storage which provides Object Storage API. >>> That being said, I'm willing to contribute such patches, if we decide >>> to go that way. >>> >>> Best regards, >>> Radoslaw Zarzynski >>> >>> [1] https://bugs.launchpad.net/horizon/+bug/1297173 >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> [email protected]?subject:unsubscribe >>> <http://[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 >>> >>> >>> __________________________________________________________________________ >>> 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 >>> >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> >>> >>> -- >>> Anne Gentle >>> [email protected] >>> __________________________________________________________________________ >>> 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 >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
