Open Stack

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 <jaypipes at gmail.com
> <mailto:jaypipes at 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
>         <rzarzynski at mirantis.com <mailto:rzarzynski at mirantis.com>
>         <mailto:rzarzynski at mirantis.__com
>         <mailto:rzarzynski at 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 at lists.__openstack.org?subject:__unsubscribe <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>         Â  Â
>         <http://OpenStack-dev-request@__lists.openstack.org?subject:__unsubscribe
>         <http://OpenStack-dev-request@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 at lists.__openstack.org?subject:__unsubscribe <http://OpenStack-dev-request@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 at lists.__openstack.org?subject:__unsubscribe
>     <http://OpenStack-dev-request@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 at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>