-
Notifications
You must be signed in to change notification settings - Fork 293
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
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This this be filled in?
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.
yes, I'm still working on the migration part and FAQ
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.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wrong indentation here it seems
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"your V3 server" -> your V3 cluster
"the V3 deployment" -> the V3 cluster
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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=false
flag, 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=false
flag 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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=false
flag 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
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.
Great, let's get this merged and let's keep a close eye on community feedback to improve as-needed. This is already infinitely better than what we have today, great work.
@htdvisser suggested we wait with publishing this until deploying |
I'm OK with merging now. |
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