Thanks very much, David, appreciated! -jay
On 03/07/2015 02:25 PM, David Lyle 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 <jaypi...@gmail.com <mailto:jaypi...@gmail.com>> 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 <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 <rzarzyn...@mirantis.com <mailto:rzarzyn...@mirantis.com> <mailto:rzarzynski@mirantis.__com <mailto:rzarzyn...@mirantis.com>>> 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 <https://bugs.launchpad.net/horizon/+bug/1297173>   ______________________________________________________________________________   OpenStack Development Mailing List (not for usage questions)   Unsubscribe:   OpenStack-dev-request@lists.__openstack.org?subject:__unsubscribe <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>   <http://OpenStack-dev-request@__lists.openstack.org?subject:__unsubscribe <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>>   http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> ______________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.__openstack.org?subject:__unsubscribe <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> ______________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.__openstack.org?subject:__unsubscribe <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
