Re: [Openstack] Distributed quota manager concept
On 07/17/2012 06:08 PM, Everett Toews wrote: Setting aside any SQL/NoSQL religious debate or even the best tool for the job argument, I think you'd find this to be a hard sell to the operations crowd. Nobody is going to want to have all of their OpenStack data in an SQL DB (which they may have already gone through the trouble to make HA) but then have just the quota data in a NoSQL DB. I would urge you to consider starting with SQL and then make NoSQL an option if there is demand for it. I think both SQL and NoSQL solutions are warranted. Kevin, you could take the approach that Keystone does and have SQL and KVS drivers... Best, -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Distributed quota manager concept
On Tue, 2012-07-17 at 16:08 -0600, Everett Toews wrote: Were you envisioning Boson going through the incubation process and becoming a core project in OpenStack? Yes, I could envision that. If that were to happen, would Boson become a required dependency for all of the other OpenStack projects (that require quotas)? No; my thought was to create a client that could then optionally be used by quota code in each project. Boson came from thinking about the quota refactoring I did in Nova, so I envisioned writing a Boson driver for the Nova quota code. Would it be possible to run OpenStack without Boson? Yes. The benefit of Boson really comes when you have to deal with the distributed quota problem, which is most apparent if you're using multi-cell Nova. Beyond that, it provides a unified interface to quotas for multiple projects, but deployers may prefer the simplicity of a non-Boson deploy. My main concern here is the cost of the complexity of adding another service to deploy and maintain. But, one way or another, obviously something needs to be done about quotas. Indeed. Speaking of deployment and maintenance complexity...the Data Storage section reads, It is also necessary to be able to search for a given Usage or Reservation based on some or all of the key/value pairs, so that usage information may be obtained and easily displayed to the user. This latter requirement may indicate that a NoSQL solution is the best for Boson's backend. Setting aside any SQL/NoSQL religious debate or even the best tool for the job argument, I think you'd find this to be a hard sell to the operations crowd. Nobody is going to want to have all of their OpenStack data in an SQL DB (which they may have already gone through the trouble to make HA) but then have just the quota data in a NoSQL DB. I would urge you to consider starting with SQL and then make NoSQL an option if there is demand for it. I wrote that because I couldn't see a simple way of doing what I wanted via SQL at the time. Now that I think about it, I think it is possible, and I'm not against using SQL at all. (I also think there was an aspect of I'd like to try working with NoSQL sometime when I wrote that, so… ;) -- Kevin L. Mitchell kevin.mitch...@rackspace.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Distributed quota manager concept
Hi Kevin, Overall I really like what you're proposing here. Conceptually this seems like a comprehensive and scalable solution to the quota issue in OpenStack. I have a number of questions on it. Were you envisioning Boson going through the incubation process and becoming a core project in OpenStack? If that were to happen, would Boson become a required dependency for all of the other OpenStack projects (that require quotas)? Would it be possible to run OpenStack without Boson? My main concern here is the cost of the complexity of adding another service to deploy and maintain. But, one way or another, obviously something needs to be done about quotas. Speaking of deployment and maintenance complexity...the Data Storage section reads, It is also necessary to be able to search for a given Usage or Reservation based on some or all of the key/value pairs, so that usage information may be obtained and easily displayed to the user. This latter requirement may indicate that a NoSQL solution is the best for Boson's backend. Setting aside any SQL/NoSQL religious debate or even the best tool for the job argument, I think you'd find this to be a hard sell to the operations crowd. Nobody is going to want to have all of their OpenStack data in an SQL DB (which they may have already gone through the trouble to make HA) but then have just the quota data in a NoSQL DB. I would urge you to consider starting with SQL and then make NoSQL an option if there is demand for it. Regards, Everett On Tue, Jul 17, 2012 at 9:44 AM, Kevin L. Mitchell kevin.mitch...@rackspace.com wrote: I recently thought about and wrote up a concept for a distributed quota manager that I have dubbed Boson. Unfortunately, higher priorities at Rackspace have kept me from working on it, so I wanted to get the proposal out there for others to comment and cogitate on. The writeup is at http://wiki.openstack.org/Boson -- Kevin L. Mitchell kevin.mitch...@rackspace.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
