Thanks very much, David, appreciated!


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 <
<>> wrote:

    Added [swift] to topic.

    On 03/03/2015 07:41 AM, Matthew Farina wrote:


        Unfortunately the documentation for OpenStack has some holes.
        What you
        are calling a private API may be something missed in the
        Is there a documentation bug on the issue? If not one should be

    There is no indication that the X-Timestamp or X-Object-Meta-Mtime
    HTTP headers are part of the public Swift API:


    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 of luck,
        Matt Farina

        On Tue, Mar 3, 2015 at 9:59 AM, Radoslaw Zarzynski
        < <>
        <>>> 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
        Â  Â  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
        Â  Â  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]

        Â  Â
        Â  Â  OpenStack Development Mailing List (not for usage questions)
        Â  Â  Unsubscribe:
        Â  Â 
        Â  Â
        Â  Â

        OpenStack Development Mailing List (not for usage questions)

    OpenStack Development Mailing List (not for usage questions)

OpenStack Development Mailing List (not for usage questions)

OpenStack Development Mailing List (not for usage questions)

Reply via email to