Re: [openstack-dev] [oslo-incubator] removal of slave_connection from db.sqlalchemy.session
Hi all, So yeah, we could restore the option and put creation of a slave engine instance to EngineFacade class, but I don't think we want this. The only reason why slave connections aren't implemented e.g. in SQLAlchemy is that, SQLAlchemy, as a library can't decide for you how those engines should be used: do you have an ACTIVE-ACTIVE setup or ACTIVE-PASSIVE, to which database reads/writes must go, and so on. The same is true for oslo.db. Nova is the only project that uses slave_connection option and it was kind of broken: nova bare metal driver uses a separate database and there was no way to use a slave db connection for it. So due to lack of consistency in using of slave connection, IMO, this should be left up to application to decide, how to use it. And we provide EngineFacade helper already. So I'd just say, create an EngineFacade instance for a slave connection explicitly, if you want it to be used like it is used in Nova right now. Thanks, Roman On Wed, Mar 5, 2014 at 8:35 AM, Doug Hellmann wrote: > > > > On Wed, Mar 5, 2014 at 10:43 AM, Alexei Kornienko > wrote: >> >> Hello Darren, >> >> This option is removed since oslo.db will no longer manage engine objects >> on it's own. Since it will not store engines it cannot handle query >> dispatching. >> >> Every project that wan't to use slave_connection will have to implement >> this logic (creation of the slave engine and query dispatching) on it's own. > > > If we are going to have multiple projects using that feature, we will have > to restore it to oslo.db. Just because the primary API won't manage global > objects doesn't mean we can't have a secondary API that does. > > Doug > > >> >> >> Regards, >> >> >> On 03/05/2014 05:18 PM, Darren Birkett wrote: >> >> Hi, >> >> I'm wondering why in this commit: >> >> >> https://github.com/openstack/oslo-incubator/commit/630d3959b9d001ca18bd2ed1cf757f2eb44a336f >> >> ...the slave_connection option was removed. It seems like a useful option >> to have, even if a lot of projects weren't yet using it. >> >> Darren >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo-incubator] removal of slave_connection from db.sqlalchemy.session
Hello All. We suppose to have common database code oslo.db library. So we decided to let end applications to cope with engines, not oslo.db. For example, see work with slave engine in Nova [1]. These is also patch to oslo with more details - [2] Also, Darren, please inform us about your usecase a bit. [1] https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L95 [2] https://review.openstack.org/#/c/68684/ On Wed, Mar 5, 2014 at 6:35 PM, Doug Hellmann wrote: > > > > On Wed, Mar 5, 2014 at 10:43 AM, Alexei Kornienko < > alexei.kornie...@gmail.com> wrote: > >> Hello Darren, >> >> This option is removed since oslo.db will no longer manage engine objects >> on it's own. Since it will not store engines it cannot handle query >> dispatching. >> >> Every project that wan't to use slave_connection will have to implement >> this logic (creation of the slave engine and query dispatching) on it's own. >> > > If we are going to have multiple projects using that feature, we will have > to restore it to oslo.db. Just because the primary API won't manage global > objects doesn't mean we can't have a secondary API that does. > > Doug > > > >> >> Regards, >> >> >> On 03/05/2014 05:18 PM, Darren Birkett wrote: >> >> Hi, >> >> I'm wondering why in this commit: >> >> >> https://github.com/openstack/oslo-incubator/commit/630d3959b9d001ca18bd2ed1cf757f2eb44a336f >> >> ...the slave_connection option was removed. It seems like a useful >> option to have, even if a lot of projects weren't yet using it. >> >> Darren >> >> >> ___ >> OpenStack-dev mailing >> listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo-incubator] removal of slave_connection from db.sqlalchemy.session
On Wed, Mar 5, 2014 at 10:43 AM, Alexei Kornienko < alexei.kornie...@gmail.com> wrote: > Hello Darren, > > This option is removed since oslo.db will no longer manage engine objects > on it's own. Since it will not store engines it cannot handle query > dispatching. > > Every project that wan't to use slave_connection will have to implement > this logic (creation of the slave engine and query dispatching) on it's own. > If we are going to have multiple projects using that feature, we will have to restore it to oslo.db. Just because the primary API won't manage global objects doesn't mean we can't have a secondary API that does. Doug > > Regards, > > > On 03/05/2014 05:18 PM, Darren Birkett wrote: > > Hi, > > I'm wondering why in this commit: > > > https://github.com/openstack/oslo-incubator/commit/630d3959b9d001ca18bd2ed1cf757f2eb44a336f > > ...the slave_connection option was removed. It seems like a useful > option to have, even if a lot of projects weren't yet using it. > > Darren > > > ___ > OpenStack-dev mailing > listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo-incubator] removal of slave_connection from db.sqlalchemy.session
Hello Darren, This option is removed since oslo.db will no longer manage engine objects on it's own. Since it will not store engines it cannot handle query dispatching. Every project that wan't to use slave_connection will have to implement this logic (creation of the slave engine and query dispatching) on it's own. Regards, On 03/05/2014 05:18 PM, Darren Birkett wrote: Hi, I'm wondering why in this commit: https://github.com/openstack/oslo-incubator/commit/630d3959b9d001ca18bd2ed1cf757f2eb44a336f ...the slave_connection option was removed. It seems like a useful option to have, even if a lot of projects weren't yet using it. Darren ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo-incubator] removal of slave_connection from db.sqlalchemy.session
Hi, I'm wondering why in this commit: https://github.com/openstack/oslo-incubator/commit/630d3959b9d001ca18bd2ed1cf757f2eb44a336f ...the slave_connection option was removed. It seems like a useful option to have, even if a lot of projects weren't yet using it. Darren ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
