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

2015-03-13 Thread Rishi Raj Singh
7i
On Mar 3, 2015 8:30 PM, Radoslaw Zarzynski 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://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


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

2015-03-13 Thread Rishi Raj Singh
Sorry,

that was by mistake.

On Fri, Mar 13, 2015 at 8:19 PM, Rishi Raj Singh rishiraj.de...@gmail.com
wrote:

 7i
 On Mar 3, 2015 8:30 PM, Radoslaw Zarzynski 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://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