Re: [openstack-dev] [Horizon] [swift] dependency on non-standardized, private APIs
On 03/12/2015 05:09 PM, John Dickinson wrote: On Mar 12, 2015, at 12:48 PM, Jay Pipes jaypi...@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.) :-) :) Understood. But yes, in my opinion, x-timestamp needs to be added to docs. K, thx for the verification. I've added a doc bug: https://bugs.launchpad.net/openstack-manuals/+bug/1431568 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. Excellent, thanks for the clarification. All the best, -jay --John Best, -jay --John On Mar 9, 2015, at 12:53 PM, Anne Gentle annegen...@justwriteclick.com wrote: 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
Re: [openstack-dev] [Horizon] [swift] dependency on non-standardized, private APIs
On Mar 12, 2015, at 12:48 PM, Jay Pipes jaypi...@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 annegen...@justwriteclick.com
wrote:
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
Re: [openstack-dev] [Horizon] [swift] dependency on non-standardized, private APIs
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. :)
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?
Best,
-jay
--John
On Mar 9, 2015, at 12:53 PM, Anne Gentle annegen...@justwriteclick.com wrote:
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
Re: [openstack-dev] [Horizon] [swift] dependency on non-standardized, private APIs
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).
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.
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.
--John
On Mar 9, 2015, at 12:53 PM, Anne Gentle annegen...@justwriteclick.com
wrote:
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.
Re: [openstack-dev] [Horizon] [swift] dependency on non-standardized, private APIs
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
__
Re: [openstack-dev] [Horizon] [swift] dependency on non-standardized, private APIs
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?
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:
Re: [openstack-dev] [Horizon] [swift] dependency on non-standardized, private APIs
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 jaypi...@gmail.com
mailto: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
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
mailto:rzarzynski@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
https://bugs.launchpad.net/horizon/+bug/1297173
 Â
__
  OpenStack Development Mailing List (not for usage questions)
 Â
Re: [openstack-dev] [Horizon] [swift] dependency on non-standardized, private APIs
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:
Re: [openstack-dev] [Horizon] [swift] dependency on non-standardized, private APIs
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
