On May 31, 2013, at 11:24 AM, Jay Shaughnessy <jshaughn(a)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.