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++ .
 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 : > > "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