I tried to deploy a canister next to a specific canister on an application subnet (qdvhd-os4o2-zzrdw-xrcv4-gljou-eztdp-bj326-e6jgr-tkhuc-ql6v2-yqe) using --next-to <canister-id> and it tells me that my canister is not allowed to do so.
Failed to create canister: Subnet qdvhd-os4o2-zzrdw-xrcv4-gljou-eztdp-bj326-e6jgr-tkhuc-ql6v2-yqe does not exist or <canister-id> is not authorized to deploy to that subnet.
Looking at the canister count on the dashboard, it seems like this subnet was blocked from deployed new canisters at some point. Can someone confirm this? So no new canisters can be deployed on this subnet?
I have an old canister running there and was hoping to deploy another on the same subnet to have fast inter-canister calls.
1 Like
This is the latest list of subnets that all principals can deploy to.
Do you have a specific use case for why you need to deploy this canister next to this specific canister?
2 Likes
IIRC the list of ‘default subnets’ gets updated every so often to balance the load across the different subnets a bit better. If you already have a canister on that subnet you can use that canister to create a new canister for you by calling the management canister’s create_canister through it
3 Likes
Thank you for this info!
I have a canister running on that subnet and am now deploying a new canister which interacts frequently with that one via update calls. If I understand correctly, inter-canister update calls on the same subnet should take 2 seconds whereas if the canisters are on different subnets, it takes 6 seconds?
As a rule of thumb that is fine, but there are a lot of things that can throw off that timing. Especially in the same subnet optimizations may make it a lot faster (especially self-awaits in periods of low load). But cross-subnet takes at least 4 rounds/seconds
1 Like
