Cassandra branch merging into master in the next couple of hours (dbsetup thread)

John Sanda jsanda at redhat.com
Fri May 31 16:01:03 UTC 2013


On May 31, 2013, at 11:24 AM, Jay Shaughnessy <jshaughn at redhat.com> wrote:

> 
> On 5/30/2013 11:23 PM, John Sanda wrote:
>> 2) dbsetup issues
>> As I pointed out during the demo, the only time you really need to apply schema changes from the dbutils module for your dev-container is to apply updates to an existing db. There is no need to install a new schema since this will be done for you when you run rhqctl install; consequently, I have made the following changes in dbutils:
>> 
>>     * Cassandra schema changes are disabled by default
>>     * You have to set -Dstorage-schema to activate Cassandra schema changes
>>     * Cassandra schema changes are only applied when either the dbsetup-upgrade
>>       or dbreset property is set.
>> 
>> I think this will alleviate a lot of the problems people have encountered. Unlike postgres, we don't have a storage node up and running until we build the dev-container and then explicitly install the storage node. It therefore does not make much sense to try to apply schema changes to C* when running dbsetup.
> 
> I can't say i really like this approach.  To me the storage DB is an extension of the RDB. Together they form the persisted store for RHQ.  Performing setup on just the RDB part would leave you in an inconsistent state.  The only time it makes sense is when the Cassandra DB is not installed (i.e. the first build).   If Cassandra is installed and not running then the dbsetup should likely fail.  I don't like that we now have another property we must set.
> 
> And maybe I'm in the minority, but I dbsetup *often* in my dev environment.  I *do* want this to recreate my C* schema.
> 
> I would have preferred that we just look to see if the rhq-storage directory exists, and if not just ignore the C* portion of dbsetup.
> 
> 


I think it is more accurate to think of the storage db as an extension of the server. That is the concept we have been striving towards by tying server/storage lifecycle together with rhctl. Regardless of how our views may differ conceptually, several people ran into this problem as I am certain community users would as well. Hopefully the changes address these problems. You could always set the property in your settings.xml so that C* schema changes will always be applied.

It is probably worthwhile to point out the following for everyone. First, we have separate test and dev databases (for postgres/oracle) against which we run dbsetup/dbupgrade. This is not the case with Cassandra. We only run schema changes for the dev-container instance. Tests handle setting up/tearing down their own clusters, and the set up includes applying schema. Secondly, for Cassandra the schema changes are all treated as upgrade. There is no separate setup vs. upgrade like we have for the relational db.


More information about the rhq-devel mailing list