Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HWKALERTS-168 Support schema upgrades #216

Merged
merged 2 commits into from
Sep 28, 2016

Conversation

lucasponce
Copy link
Contributor

This PR introduces Cassalog library as mechanism to create and upgrades the alerting C* schema.
With this enhancement incremental updates are supported instead to re-create full cql schema.
Cassalog library deploy a helper versioning mechanism on the keyspace to perform this goal.
Please @jshaughn, can you review it ?

/cc @jsanda I have tested locally and on cluster environments and things are running well but as you are the author of cassalog if you see something wrong just let me know.

Thanks in advance.

Copy link
Contributor

@jshaughn jshaughn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Everything LGTM other than than the cassalog update.

@@ -83,6 +83,7 @@
<version.com.icegreen>1.4.1</version.com.icegreen>
<version.javaee.spec>7.0</version.javaee.spec>
<version.maven-patch-plugin>1.2</version.maven-patch-plugin>
<version.org.cassalog>0.3.0</version.org.cassalog>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lucasponce, @jsanda has released an important fix in cassaloge 0.3.1, please update.

@jsanda
Copy link
Contributor

jsanda commented Sep 28, 2016

I wasn't aware that h-alerts was moving to cassalog, so I just now started looking at the PR. You probably don't need the bootstrap.groovy. The reason we needed that in h-metrics is because we prod releases before we introduced cassalog, which meant we had to be able to introduce the schema management tool on top of existing schemas. That made things more complicated.

@jshaughn jshaughn merged commit a8be941 into hawkular:master Sep 28, 2016
@lucasponce
Copy link
Contributor Author

I wasn't aware that h-alerts was moving to cassalog, so I just now started looking at the PR. You probably don't need the bootstrap.groovy. The reason we needed that in h-metrics is because we prod releases before we introduced cassalog, which meant we had to be able to introduce the schema management tool on top of existing schemas. That made things more complicated.

As the previous alerting version 1.2.0 didn't have the cassalog and it was ready for using I thought also in some legacy schema too, so I left the bootstrap.groovy for same reason.

But I agree, if we don't need it in the future we can simplify it, too.

@jsanda
Copy link
Contributor

jsanda commented Sep 28, 2016

If we didn't have production releases of h-metrics already, then we would not have a bootstrap.groovy. It was a source of complexity and bugs that we unfortunately were not able to avoid. Do whatever makes the most sense for h-alerts. I just wanted to point out that you can probably simplify things.

@jsanda
Copy link
Contributor

jsanda commented Sep 28, 2016

I also want to point out point out this issue.

@lucasponce
Copy link
Contributor Author

I guess we are not going to use alerting 1.2.0 for production, so I am going to simplify the bootstart and use only the schema scripts.
I think that will help future upgrades of cassalog where detection of problems can be delegated into the library.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants