----- Mail original ----- > De: "Curtis" <serverasc...@gmail.com> > À: "OpenStack Development Mailing List (not for usage questions)" > <openstack-...@lists.openstack.org> > Cc: openstack@lists.openstack.org > Envoyé: Vendredi 19 Mai 2017 01:43:39 > Objet: Re: [openstack-dev] [Keystone] Cockroachdb for Keystone Multi-master > > On Thu, May 18, 2017 at 4:13 PM, Adrian Turjak > <adri...@catalyst.net.nz> wrote: > > Hello fellow OpenStackers, > > > > For the last while I've been looking at options for multi-region > > multi-master Keystone, as well as multi-master for other services > > I've > > been developing and one thing that always came up was there aren't > > many > > truly good options for a true multi-master backend. Recently I've > > been > > looking at Cockroachdb and while I haven't had the chance to do any > > testing I'm curious if anyone else has looked into it. It sounds > > like > > the perfect solution, and if it can be proved to be stable enough > > it > > could solve a lot of problems. > > > > So, specifically in the realm of Keystone, since we are using > > sqlalchemy > > we already have Postgresql support, and since Cockroachdb does talk > > Postgres it shouldn't be too hard to back Keystone with it. At that > > stage you have a Keystone DB that could be multi-region, > > multi-master, > > consistent, and mostly impervious to disaster. Is that not the holy > > grail for a service like Keystone? Combine that with fernet tokens > > and > > suddenly Keystone becomes a service you can't really kill, and can > > mostly forget about. > > > > I'm welcome to being called mad, but I am curious if anyone has > > looked > > at this. I'm likely to do some tests at some stage regarding this, > > because I'm hoping this is the solution I've been hoping to find > > for > > quite a long time. > > I was going to take a look at this a bit myself, just try it out. I > can't completely speak for the Fog/Edge/Massively Distributed working > group in OpenStack, but I feel like this might be something they look > into. >
Thanks Curtis for highlighting this. Indeed, among the actions we defined during our F2F meeting in Boston, one is to investigate the feasibility of using cockroachDB as the backend. We gave really preliminary investigations and identify several aspects that we should consider (dependence w-r-t postgres, maturity of cockroach code,...) For your information, we did a PoC one year ago to show that it is possible to use a Non SQL backend (i.e Redis in our case) instead of the historical MySQL backends. Our goal was to investigate a solution to distribute the storage backends accros several nodes/sites. Although it was ``just'' a PoC (i.e., the quality of the code was definitely improvable), it demonstrated that using a non-SQL backend can make sense (for more information see [1] [2]). Among the remarks we got, the fact of loosing the SQL API seemed to be an issue. Using new SQL systems such as CockRoach can solve this issue and that's why we want to study how this can be done (1./ identify the effort in terms of development, 2./ find a way to evaluate performance pros/cons 3./ do the job) Among the different systems (cockroach, vitess, ...), the important point from the FEMDC working group [3] is the fact that we do not want to have centralized service. From what I learnt by browsing a few pages of the Vitess website, the architecture does not satisfy this aspect. In any case, we need to spend more times on these questions before having enough materials to get valuable answers. In others words, if you are interested to deal with such questions, do not hesitate to take part in our IRC meetings and follow the mailing list. Best, Ad_rien_ [1] https://hal.inria.fr/hal-01273427/ [2] https://www.openstack.org/summit/austin-2016/summit-schedule/events/7342 [3] https://wiki.openstack.org/wiki/Fog_Edge_Massively_Distributed_Clouds > For standard multi-site I don't know how much it would help, say if > you only had a couple or three clouds, but more than that maybe this > starts to make sense. Also running Galera has gotten easier but still > not that easy. > > I had thought that the OpenStack community was deprecating Postgres > support though, so that could make things a bit harder here (I might > be wrong about this). > > Thanks, > Curtis. > > > > > Further reading: > > https://www.cockroachlabs.com/ > > https://github.com/cockroachdb/cockroach > > https://www.cockroachlabs.com/docs/build-a-python-app-with-cockroachdb-sqlalchemy.html > > > > Cheers, > > - Adrian Turjak > > > > > > __________________________________________________________________________ > > 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 > > > > -- > Blog: serverascode.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 > _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
