search

TheThingsNetwork / lorawan-stack-migrate

Migrate devices from other LoRaWAN Network Servers to The Things Stack
Apache License 2.0
8 stars 3 forks source link

TTS source improvements #51

Closed adriansmares closed 2 years ago

adriansmares commented 2 years ago

Summary

References https://github.com/TheThingsIndustries/lorawan-stack-support/issues/854#issuecomment-1260510806

We should add extra options to the TTS (ttnv3) source.

Why do we need this?

These options would allow easier migration.

What is already there? What do you see now?

Non dry-run runs of the tool disable the end device downlinks and export the end device.

What is missing? What do you want to see?

  1. A --no-session option that would enable users to export the device without the session added.
  2. A --delete-source-device option that would delete the end device in the 4 source servers (JS, NS, AS, IS. The order matters to a certain extent. The IS should always be the last one).

For the above, --dry-run should cause these options to not be executed.

Environment

v0.9.0-rc1.

How do you propose to implement this?

  1. We do a SetFields from nil with a field mask of "session", "pending_session", "mac_state", "pending_mac_state", in the same fashion that we delete the addresses.
  2. It is similar to device updates, but you call it with Delete instead of Set.

How do you propose to test this?

Use the options and check that:

  1. There is no session, pending_session,mac_state or pending_mac_state in the returned end device.
  2. The device is delete after you run the command. You can check that everything went fine by attempting to re-register it.

Can you do this yourself and submit a Pull Request?

Can review.

jpmeijers commented 2 years ago

For the above, --dry-run should cause these options to not be executed.

We just need to be very careful to document what the migration tool does when --dry-run is omitted. How I like to do my migrations is to leave the devices on TTS-CE sending uplinks, disabling downlink, until they rejoin the new network. If I omit --dry-run now, this is the behaviour I will get. But if the description above is implemented, my devices might be deleted, and the devices will fall off the network.

adriansmares commented 2 years ago

The intent is that they are opt-in, not opt out. So the devices are deleted only if the --delete-source-device flag is explicitly provided.

A 'non dry run' without any extra parameters just disables the downlinks, but the devices are not deleted (even after this issue is closed).

jpmeijers commented 2 years ago

For consistency, shouldn't we just remove the --dry-run and make disabling downlinks also opt-in?

adriansmares commented 2 years ago

My reasoning for this inconsistency is that things are battery included without risks. You just run the migration command with no parameters and nothing bad happens - your device is still there, the downlinks are disabled, and after you import it you're good to go.

Making the 'disable downlinks' option be opt-out is intentional as having two Network Servers attempting to send downlinks at the same time can be very problematic (what if they both decide to send a downlink at the same time but the payloads are not the same ?).

Historically speaking people may jump the gun a bit (which is totally fair) and just run the command on their application / end device. In v2 this was very bad because deletion was implicit so they would accidentally lose sessions. I would prefer that the enthusiasm on the v3 source is not met with surprises (devices stay, and downlinks stop), but I am open to interpretations.