[openstack-dev] [Cinder]Persistance layer for cinder + taskflow
Hello everyone, Currently I am working on adding persistence layer for create_volume api using taskflow. Could you please give your opinions on whether is it a good idea to add taskflow tables in existing cinder database or to create a new database for taskflow. Thanks Regards, Abhishek Kekane __ Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder]Persistance layer for cinder + taskflow
An idea that might be good to do is to start off using SQLite as the taskflow persistence backend. Get that working using SQLite files (which should be fine as a persistence method for most usages) and then after this works there can be discussion around moving those tables to something like MySQL and the benefits/drawbacks of doing that. What do u think? Start small then grow seems to be a good approach. Sent from my really tiny device... On Mar 28, 2014, at 7:11 AM, Kekane, Abhishek abhishek.kek...@nttdata.commailto:abhishek.kek...@nttdata.com wrote: Hello everyone, Currently I am working on adding persistence layer for create_volume api using taskflow. Could you please give your opinions on whether is it a good idea to add taskflow tables in existing cinder database or to create a new database for taskflow. Thanks Regards, Abhishek Kekane __ Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] [Cinder]Persistance layer for cinder + taskflow
On 28 March 2014 14:38, Joshua Harlow harlo...@yahoo-inc.com wrote: An idea that might be good to do is to start off using SQLite as the taskflow persistence backend. Get that working using SQLite files (which should be fine as a persistence method for most usages) and then after this works there can be discussion around moving those tables to something like MySQL and the benefits/drawbacks of doing that. What do u think? Start small then grow seems to be a good approach. I'd say at tables to the existing database first, it adds the smallest number of new moving parts, then look at a new database if and only if there seems to be evidence that one is needed. As a systems operator, it is hard enough managing one db let alone N local dbs... ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder]Persistance layer for cinder + taskflow
On Fri, 2014-03-28 at 18:16 +, Duncan Thomas wrote: On 28 March 2014 14:38, Joshua Harlow harlo...@yahoo-inc.com wrote: An idea that might be good to do is to start off using SQLite as the taskflow persistence backend. Get that working using SQLite files (which should be fine as a persistence method for most usages) and then after this works there can be discussion around moving those tables to something like MySQL and the benefits/drawbacks of doing that. What do u think? Start small then grow seems to be a good approach. I'd say at tables to the existing database first, it adds the smallest number of new moving parts, then look at a new database if and only if there seems to be evidence that one is needed. As a systems operator, it is hard enough managing one db let alone N local dbs... My suggestion would be to add a new CONF option (persistent_db_connection?) that would default to the value of CONF.db.connection). That way you default to using the same DB as the main Cinder tables, but automagically provide the deployer with the ability to handle the taskflow tables separately if they want. best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder]Persistance layer for cinder + taskflow
That'd work to, allowing for trying out/deploying/using this feature in different ways if it's wanted. Hopefully not to many issues, if so, u know where to find us ;-) -Josh From: Jay Pipes jaypi...@gmail.commailto:jaypi...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Friday, March 28, 2014 at 12:52 PM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Cinder]Persistance layer for cinder + taskflow On Fri, 2014-03-28 at 18:16 +, Duncan Thomas wrote: On 28 March 2014 14:38, Joshua Harlow harlo...@yahoo-inc.commailto:harlo...@yahoo-inc.com wrote: An idea that might be good to do is to start off using SQLite as the taskflow persistence backend. Get that working using SQLite files (which should be fine as a persistence method for most usages) and then after this works there can be discussion around moving those tables to something like MySQL and the benefits/drawbacks of doing that. What do u think? Start small then grow seems to be a good approach. I'd say at tables to the existing database first, it adds the smallest number of new moving parts, then look at a new database if and only if there seems to be evidence that one is needed. As a systems operator, it is hard enough managing one db let alone N local dbs... My suggestion would be to add a new CONF option (persistent_db_connection?) that would default to the value of CONF.db.connection). That way you default to using the same DB as the main Cinder tables, but automagically provide the deployer with the ability to handle the taskflow tables separately if they want. best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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
