Cassandra branch merging into master in the next couple of hours (dbsetup thread)
Jay Shaughnessy
jshaughn at redhat.com
Fri May 31 15:24:51 UTC 2013
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.
More information about the rhq-devel
mailing list