[openstack-dev] [Horizon] [swift] dependency on non-standardized, private APIs

Anne Gentle annegentle at justwriteclick.com
Mon Mar 9 19:53:53 UTC 2015


On Mon, Mar 9, 2015 at 2:32 PM, Matthew Farina <matt at mattfarina.com> 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 <dklyle0 at gmail.com> 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> 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
>>>> <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
>>>>
>>>>     ____________________________________________________________
>>>> ______________
>>>>     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
>>>>
>>>>
>>>>
>>>>
>>>> ____________________________________________________________
>>>> ______________
>>>> 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
>>>>
>>>>
>>> ____________________________________________________________
>>> ______________
>>> 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
>>>
>>
>>
>> __________________________________________________________________________
>> 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
>>
>>
>
> __________________________________________________________________________
> 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
>
>


-- 
Anne Gentle
annegentle at justwriteclick.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150309/0b51091d/attachment.html>


More information about the OpenStack-dev mailing list