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
