RGW does not use Swift. It’s an optional component of Ceph that can provide a 
Swift compliant API (and also S3). But it does not make use of openstack-swift. 
It’s a completely separate implementation written in c++ [1].

[1] https://github.com/ceph/ceph/blob/master/src/rgw/rgw_rest_swift.cc

> On Oct 13, 2016, at 5:36 AM, Shinobu Kinjo <shinobu...@gmail.com> wrote:
> 
> 
> 
> On Wed, Oct 12, 2016 at 9:59 PM, Giulio Fidente <gfide...@redhat.com 
> <mailto:gfide...@redhat.com>> wrote:
> On 10/12/2016 02:29 PM, Thiago da Silva wrote:
> 
> 
> On 10/12/2016 07:10 AM, Giulio Fidente wrote:
> hi,
> 
> we introduced support for the deployment of Ceph in the liberty
> release so that it could optionally be used as backend for one or more
> of Cinder, Glance, Nova and more recently Gnocchi.
> 
> We used to deploy Ceph MONs on the controller nodes and Ceph OSDs on
> dedicated ceph-storage nodes so a deployment of OpenStack with Ceph
> would need at least 1 more additional node to host a Ceph OSD.
> 
> In our HA scenario the storage backends are configured as follows:
> 
> Glance -> Swift
> Nova (ephemeral) -> Local
> Cinder (persistent) -> LVM (on controllers)
> Gnocchi -> Swift
> 
> The downside of the above configuration is that Cinder volumes can not
> be replicated across the controller nodes and become unavailable if a
> controller fails, while production environments generally expect
> persistent storage to be highly available. Cinder volumes instead
> could even get lost completely in case of a permanent failure of a
> controller.
> 
> With the Newton release and the composable roles we can now deploy
> Ceph OSDs on the compute nodes, removing the requirement we had for an
> additional node to host a Ceph OSD.
> 
> I would like to ask for some feedback on the possibility of deploying
> Ceph by default in the HA scenario and use it as backend for Cinder.
> 
> Also using Swift as backend for Glance and Gnocchi is enough to cover
> the availability issue for the data, but it also means we're storing
> that data on the controller nodes which might or might not be wanted;
> I don't see a strong reason for defaulting them to Ceph, but it might
> make more sense when Ceph is available; feedback about this would be
> appreciated as well.
> I think it would be important to take into account the recently created
> guiding principles [0]:
> 
> "While the software that OpenStack produces has well defined and
> documented APIs, the primary output of OpenStack is software, not API
> definitions. We expect people who say they run “OpenStack” to run the
> software produced by and in the community, rather than alternative
> implementations of the API."
> 
> In the case of Cinder, I think the situation is a bit muddy as LVM is
> not openstack software, and my limited understanding is that LVM is used
> as a reference implementation, but in the case of Swift, I think RGW
> would be considered an 'alternative implementation of the API'.
> 
> Thiago
> 
> hi Thiago,
> 
> sorry if it wasn't clear in my original message but I did not suggest to 
> replace Swift with Ceph RGW.
> 
> Swift would continue to be deployed by default, not RGW.
> 
> RGW utilizes Swift. So Swift has to be there anyway -;
>  
> 
> The feedback I'm asking for is about storing (or not) the Cinder volumes in 
> Ceph for the HA scenario by default, and also store the Glance images and 
> Gnocchi metrics in Ceph or rather keep that data in Swift.
> -- 
> Giulio Fidente
> GPG KEY: 08D733BA
> 
> __________________________________________________________________________
> 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 
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 
> 
> 
> -- 
> Email:
> shin...@linux.com <mailto:shin...@linux.com>
> shin...@redhat.com 
> <mailto:shin...@redhat.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

__________________________________________________________________________
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

Reply via email to