Running Chirpstack v3 and v4 side-by-side

ChirpStack (v4)
1

Hi chirpstack community!
We have a chirpstack v3 cluster (3 VMs) running in a kubernetes environment. Due to the fact, that we have third party applications connected to the chirpstack v3 api, we are considering for now to run both versions in the cluster.

So my thinking was the following:

  1. Stop chirpstack v3 (application- and networkserver)
  2. Install and migrate all data from v3 to v4 instance (Redis and Postgres)
  3. Start chirpstack v3 and v4
  4. Deleting all applications and organisations which are not connected to any third party application (which are the most) in chirpstack v3
  5. Change allowed subscribed topics to the new MQTT topic scheme of chirpstack v4

What do you think? Is this way possible, and is there anything to be aware of?

Thanks!

2

That covers a lot of the server-side, do you have a plan in place to migrate the gateway connectivity side of things (gateway versions/configuration/topics)?

Generally I like to migrate one site/location at a time, but that assumes the case where my organization controls the end-to-end flow of data.

3

Late response, sorry. Migration was not done yet.
I have now a plan to do that stuff of migration:

  1. Dump the chirpstack_as and chirpstack_ns database
  2. Backup Redis rdb (just to be save)
  3. Prepare the V4 configuration
  4. Run V4 migration tool
  5. Run a new Redis instance for the v4 chirpstack instance, because my actual instance uses redis sentinel which is not supported for now
  6. Start v4 chirpstack instance

Regarding Gateways:
I have updated all chirpstack gateway bridges and are using protobuf, so there shouldn’t be a problem. The changed topic (new application id) could be handled in our mqtt broker, where we rewrite the topic to the old application id and from then on change all applications using the old application id to use the new application id. Anyway we do not configure a prefix, because we do not need it.

My Question is, would it be possible to migrate as descibed above on the production system side by side with the v3 instances, just disabling for now the mac commands in the v4 instance? This should still update all redis and postgres data, while not interfere with the v3 instance, right?

4

I prefer having separate topologies for migrations, so I cannot speak to your approach, unfortunately. Perhaps someone else can chime in.

5

What do you mean with “sparate topologies”?

6

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.