-
Notifications
You must be signed in to change notification settings - Fork 39
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
Conversation
There was a problem hiding this 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> |
There was a problem hiding this comment.
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.
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. |
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. |
I also want to point out point out this issue. |
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. |
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.