openstack team mailing list archive

["Kevin L. Mitchell" <kevin.mitchell@xxxxxxxxxxxxx>]

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.mitchell@xxxxxxxxxxxxx>