Concern about Liquibase Hub

Hello! This is not as much an issue about Dropwizard, but I wanted to express a small concern I got about Liquibase yesterday, when attempting to upgrade from v3 (3.6.3) to v4 (4.3.4).

I maintain an application which uses Dropwizard, and we like to stay ahead and keep our dependencies updated. We use the, at time of writing, latest Dropwizard v2.0.21. It may also be that we override some dependencies in dropwizard-dependencies to later versions, if we see that they work.

One such dependency is Liquibase, which we have actually overridden to stay on version 3.6.3 now for quite a long time. Mainly because we experienced some differences in how Liquibase generates SQL from v3.7.0 which made our migrations break, and we didn’t invest time in resolving it because 3.6.3 worked just fine, and it is not really being used for anything during runtime. However yesterday I decided to try to finally bring Liquibase to latest-greatest. Resolving the anomalies for the migrations was easy, so that was nothing to worry about. But when testing and running the migrations I noticed some warnings being logged, looking like this:

WARN  liquibase.hub.HubUpdater - Skipping auto-registration
WARNING: The changelog file specified is not registered with any Liquibase Hub project,
so the results will not be recorded in Liquibase Hub.
To register the changelog with your Hub Project run 'liquibase registerchangelog'.
Learn more at https://hub.liquibase.com

Which made me a bit curious of this Liquibase Hub, which it looks like it is something it want to contact during our database migrations. In short, it looks to be some kind of analysis tool for displaying insights into your migrations. After some digging and debugging, I think I have verified that it actually does not connect to Liquibase Hub to send anything about our database schema, but it strongly nudges to register an account and set up so that data about your database seems to be sent to Liquibase each time a migration is performed.

Setting the system property liquibase.hub.mode=OFF disables the Liquibase Hub feature. But, in our migration setup for our automated tests, we run Liquibase.dropAll, and for that I also had to make sure that I use a separate Liquibase instance where changeLog is explicitly set to null, or I would get the aforementioned warning, even though I had set the system property liquibase.hub.mode=OFF. It does not seem like the DropAllCommand in liquibase takes the system property into account.

All this makes me a bit uneasy about Liquibase, to be honest. Yes, it will seemingly not send anything as long as you have not configured an API-key to connect to their Liquibase Hub API, but it took me a bit off-guard that they are actually thinking of sending lots of data about our database to their servers, and also having it as a sort of, and a bit hidden tbh, opt-out feature. If you decide to do as the warnings advise you to, according to their FAQ they will send “Changeset body from the changelog”, “Generated SQL executed by the Liquibase core app”, and “Two types of logs: operation-event and change-event”.

I see that Liquibase v4 is planned for the 2.1 release of Dropwizard, so I wanted to ask if you have any thoughts on this? Have you noticed this behaviour? I do not wish to be dramatic about this, am I overreacting or is this a legitimate concern? Maybe there are some insight here as well that is applicable for incorporating into Dropwizard.

Thanks for reading my rambling wall-of-text, and thanks for making Dropwizard! 😃

[zUniQueX]

@runeflobakk Thanks for the detailed answer. I just looked into their code (current master branch) and they seem to instantiate a HubUpdater anyway in the Liquibase.update(...) method. This instance shouldn’t do anything, if the user is not registered, but I also think this should be opt-in rather than opt-out.

One solution seems to be ensuring HubService.isOnline() returns false. Then the methods of HubUpdater would all return before sending any data.

I just didn’t fully get their configuration mechanism, so I currently can’t say, if there is a default instance of HubService registered, which fulfills isOnline(). I’ll take a closer look at that and will report this here.

If there is no default registered HubService, then a fallback one is used which directly returns at all methods instead of connecting to the hub. So in this case, we shouldn’t have to care about any data send although there might be an API key anywhere.

[runeflobakk]

@zUniQueX I left this a bit after the “assessment” above, but I will check a branch I have here with the changes I did as soon as I find the time, and get back to you!