Only EU has V3 at the moment. Let’s wait until the other regions have their V3 clusters and we all have been able to check what is involved in migration our nodes.
Currently people in EU are trying to find if a node can be migrated online or requires a visit. Other regions don’t have that opportunity yet.
Gateways will probably require visits to reconfigure. For those nodes and gateways where on-site activities are required these are severely restricted in most countries around the world at the moment, that needs to be taken into account.
And as TTNs crystal ball is not better than that of most governments it would be a miracle if they can currently create a reliable timeline for anything exceeding weeks.
The provisional timeline communicated during the conference was:
April V2 read only
September switch off
However that already prompted the feedback that those timelines would be impossible to achieve in some parts of the world due to travel restrictions. And Johan promised TTN would not to put anyone’s live at risk.
If v2 is readonly in April (means we can’t add anything more in … I think we are on the rush because the impacts are large, even just for migrating devices from v2 to v3. As we have seen, this alos requires to upgrade some of the gateways to still relay traffic on v3 even if still on v2.
But my question is more about a general planning to be in sync altogether, like saying to people, the right period to migrate your gateways is July - August.
Ensuring your v2 gateway will continue to route v3 traffic ; February - March
Migrating your applications and devices March - July
This is to avoid everyone going in different directions.
Are you hoping to find a solution to cat herding? I understand the general idea of getting people in sync but if you scan through the topics we have people at all levels and human nature means many people will leave everything to the last minute.
I think the best we can do is to keep saying “Migrate gateways last” so that those who do leave their device migration late will still have some coverage.
As for TTI, they can see how much is still flowing through V2 but even if it’s a significant chunk of devices, it’s just not in their interests to buy more duct tape to keep the old stack going - at what point do you call it time?
A agree that this migration is a challenge, also that TTN is a community network, by the way if anyone commit anything anytime in Linux kernel at the end the adoption will be lower, because it will kernel panic too often
I’m locally do my best to offer a high quality network that can compete against public operators because I think TTN model is really interesting in the future. It means we need to capture professionals/commercial applications and as a consequence having a correct SLA.
Honestly, I can manage a such upgrade as a project locally and limit the impact for users (even if they are not a lot, but this is not a reason to make it badly). But if we want to have an efficient migration globally and not having this period of time quoted by all our competitors for the next 10 years, we should not only considering this as a technical operation but as a project, with phases, synchronization, progress KPIs.
So, as a local Initiator trying to execute and animate the migration locally, more information I can access about a global planning and progress, more I am able to synchronize with others.