[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