On Mon, Mar 9, 2015 at 2:32 PM, Matthew Farina <m...@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 <dkly...@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 <jaypi...@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 >>>> <rzarzyn...@mirantis.com <mailto:rzarzyn...@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-requ...@lists.openstack.org?subject:unsubscribe >>>> <http://openstack-dev-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Anne Gentle annegen...@justwriteclick.com
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev