Open Stack

> On Mar 12, 2015, at 12:48 PM, Jay Pipes <jaypipes at gmail.com> wrote:
> 
> On 03/12/2015 03:08 PM, John Dickinson wrote:
>> I'd like a little more info here.
>> 
>> Is Horizon relying on the X-Timestamp header for reads (GET/HEAD)? If so, I think that's somewhat odd, but not hugely problematic. Swift has been returning an X-Timestamp header since patch b20264c9d3196 (which landed 3 years ago -- April 2012).
> 
> OK, so there is a documentation bug here that X-Timestamp should be part of the Swift REST API. It currently is not documented that X-Timestamp is a non-optional HTTP Header, and therefore the RadosGW folks did not send X-Timestamp headers back in the container response.
> 
>> The X-Timestamp header is certainly part of the Swift API. It is required for container-sync functionality (implemented in early 2011) so that two clusters can communicate about the proper timestamp of the objects.
> 
> OK. Sounds like an implementation detail leaking out of the API to me. In other words, RadosGW (which is attempting to expose a Swift API in front of Ceph backend storage) needs to expose this X-Timestamp header even if it implements container-sync using an entirely difference mechanism...
> 
>> I'm not sure if this actually matters for Horizon in this specific case. But it's certainly true that Swift requires and used the X-Timestamp header for implementing core functionality. Anyone talking to a Swift endpoint can assume that there is an X-Timestamp header in the response and use it as they see fit.
> 
> Anyone talking to an upstream Swift *implementation* can assume that header will be there :) But, the header is not actually documented in the Swift *API* and therefore one cannot make this assumption.
> 
> Thus the confusion. :)


I don't particularly agree with the characterization of the API and implementation as separate, but that's a "discussion" that's as old as openstack itself. (and we don't need to belabor it here.)

:-)


But yes, in my opinion, x-timestamp needs to be added to docs.


> 
> Anyway, sounds like X-Timestamp should be documented as part of the official Swift API. What about the X-Object-Meta-Mtime header in the related bug? That, too, is problematic for a similar reason. Is that header part of the Swift API as well?


Anything prefixed by "X-Object-Meta-" is user metadata, ie completely arbitrary and set by an end user (same with x-container-meta-* and x-account-meta-*). From the context of Swift, I have zero semantic understanding of any key or value in that namespace.


--John

> 
> Best,
> -jay
> 
>> 
>> --John
>> 
>> 
>> 
>> 
>>> On Mar 9, 2015, at 12:53 PM, Anne Gentle <annegentle at justwriteclick.com> wrote:
>>> 
>>> 
>>> 
>>> 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
>>> __________________________________________________________________________
>>> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150312/1bfe8e03/attachment.pgp>