doc: Add V3 info #425
doc: Add V3 info #425
Conversation
| --- | ||
| title: How do I migrate to The Things Stack V3? | ||
| --- |
There was a problem hiding this comment.
yes, I'm still working on the migration part and FAQ
There was a problem hiding this comment.
@johanstokking Can you please spend some time to review this? I'm still left with FAQ, but that can be updated along the way with new questions. This was the idea:
- info page - provide info about what V3 is, where to find it, why to migrate
- migration page - unite the overall migration process in a single place on ttn.org/docs, link the relevant documentation so people know where to find more details
| var bytes = input.bytes; | ||
| var port = input.fport; | ||
| var port = input.fPort; | ||
| return { |
There was a problem hiding this comment.
Wrong indentation here it seems
There was a problem hiding this comment.
I think what suffices here is that the payload format has changed. Link to the new format.
The old format still works in V3, so to keep things as easy as possible here, don't ask to rewrite the payload codecs.
| # What to do with ABP end device? | ||
| ## What to do with ABP end device? | ||
|
|
||
| If you are using an ABP device, that means your end device is still associated with the V2 `DevAddr`, so the Packet Broker will not be able to route its traffic to your V3 server if you have not connected your gateway to V3. In order to route this traffic correctly, follow the next steps to migrate your gateway to the V3 deployment. |
There was a problem hiding this comment.
"your V3 server" -> your V3 cluster
"the V3 deployment" -> the V3 cluster
There was a problem hiding this comment.
Check other occurrences too
|
|
||
| If it was the public V2 deployment, and you are using The Things Stack v3.10 or higher, you may transfer the active device session as well - this means your device can continue working on The Things Stack V3 deployment without the need for a rejoin. | ||
|
|
||
| If it was the private V2 deployment, devices that have the `DevAddr` that is out of the scope of the address block supported by The Things Stack V3 will have to perform a rejoin. |
There was a problem hiding this comment.
For private V2 SaaS customers, we do make the DevAddr block available to The Things Stack Cloud. So that is going to work, also with ABP.
There was a problem hiding this comment.
@johanstokking I found this here: https://www.thethingsindustries.com/docs/getting-started/migrating/migrating-from-v2/, so I guess this should be updated then. Btw, something is confusing me a bit, so I would be grateful if you would explain this shortly.
- If you migrate an active OTAA session to V3, keys get deleted from V2 automatically, and the device doesn't have to perform a new join to V3. If you use
--ttnv2.with-session=falseflag, keys will stay untouched on V2, but then you have to manually prevent the device from joining V2 and your device has to do a new join to the V3 network - What confuses me is 1 session during ABP device lifetime -> what would
--ttnv2.with-session=falseflag mean in ABP case? Just that keys don't get deleted from V2 and you have to manually delete the device from V2 in order for it to work on V3? Is this flag even applicable to ABP?
There was a problem hiding this comment.
I found this here: thethingsindustries.com/docs/getting-started/migrating/migrating-from-v2
I referred to the second paragraph, about the DevAddr scope. That is not covered in that doc, right?
- What confuses me is 1 session during ABP device lifetime -> what would
--ttnv2.with-session=falseflag mean in ABP case? Just that keys don't get deleted from V2 and you have to manually delete the device from V2 in order for it to work on V3? Is this flag even applicable to ABP?
Yes. Indeed, not deleting the ABP session in V2 and creating it in V3 leads to errors as the session is then in two places, creating potential conflicts.
There was a problem hiding this comment.
I found this here: thethingsindustries.com/docs/getting-started/migrating/migrating-from-v2
I referred to the second paragraph, about the DevAddr scope. That is not covered in that doc, right?
Actually, it is - second paragraph under Migrating active sessions.
There was a problem hiding this comment.
Ah I see what you mean now, sorry. This:
When migrating from a private The Things Network Stack V2, devices that are outside of the DevAddr address block supported by The Things Stack Cloud will have to rejoin the network, otherwise The Things Stack will be unable to route their uplink and downlink traffic.
This indeed is not true and can be removed or rewritten as that we are making the same DevAddr range available in The Things Stack Cloud.
|
@johanstokking I processed your feedback |
@htdvisser suggested we wait with publishing this until deploying |
|
I'm OK with merging now. |
nejraselimovic
force-pushed
the
issue/add-v3-migration-support
branch
from
7f3ff98
to
3d92a9b
Compare
For supporting migration from V2 to V3, we addressed that there should be:
[x] a V3 info page (what is it, where to find it, reasons to migrate)
[x] a simplified guide on how to migrate from V2 to V3 -> WiP
[ ] FAQ page -> WiP