Do you know anything about if the functionality mentioned above has actually been implemented?
No, this functionality is not implemented. We’re still in the design phase when it comes to subnet splitting, so it will take a while longer until it’s available.
The requirement that the canister which is instantiating the creation of new canisters be located on the same subnet is a bit limiting, and I’m not 100% sure why this was put in place in the first place. We already have the random “round-robin” approach of picking a subnet to create a canister on documented here , so I’m not quite sure why this restriction exists in terms of letting a canister do this directly (both have the ability to pick a random subnet, and to choose the exact subnet).
There are some historical reasons for this, mainly out of caution before launch since it was easier to limit canister creation on the same subnet. We’ve had discussions in the past about extending the api for create_canister to allow for choosing a subnet but there were concerns about an api where you set some specific subnet id because that would mean that the concept of subnets needs to be a first class citizen which sort of goes against our efforts to “hide” that concept from end users as much as possible (e.g. in the interface spec we rarely, if at all, talk about subnets). As such we didn’t reach an agreement and given there was no real use case yet we left things as they are. Given what you describe, it might be a good idea to pick up this discussion again.
If DFINITY is concerned about people deploying to “private subnets” like the Bitcoin integration, the dev testing subnet, or to “private” subnets reserved for larger, specific applications, then IC management canister related actions like
create_canisteron those subnets can be gated by the principal id of the developer or of the canister (i.e. if it is already on that subnet).
I don’t think this is a concern anymore. There is a mechanism to disallow canister creation on special subnets if needed (the authorized subnetwork proposals you might have seen from time to time).
25.42TB in an application subnet? But I thought each subnet has a canister memory capacity of 300GB…?
The limit was indeed 300GiB but we have increased it to 350GiB not so long ago. You can always consult this to know what’s the latest value.
As for what’s shown in the dashboard: it’s the total available disk space on the subnet which is why you see different numbers for different size of subnets (I mean subnets with different number of nodes). The disk space allocated on the nodes is more but because of current protocol limitations (that we are also working to lift some time in the future) we need to enforce the lower limit of 350GiB. It can be misleading (apparently, since you’re asking) so it’s probably a good idea to clarify what is shown there. I can take it up with the team.