Not Authorized to Create Canisters on Public Subnet

I have not been able to deploy new canisters to my subnet of choice, which I already have ~15 canisters on.

I can make canisters without a specified subnet. I was always was able to make new ones with this command up until about 1-2 months ago (when I realized this failure):

This issue has come up before on this forum, but the following solutions do not apply:

  • This subnet is not ‘at capacity’ (I think): nl6hn-ja4yw-wvmpy-3z2jx-ymc34-pisx3-3cp5z-3oj4a-qzzny-jbsv3-4qe
  • This subnet should give every principal permission to create canisters. See this proposal.

My use case is to keep my app’s inter-canister calls fast. Does anyone know the fix?

If not, does anyone have canisters on this subnet they want to sell :slight_smile:

2 Likes

This looks like the last update to public subnets: Updating the list of public subnets

nl6hn should be public according to it. Checking with the CMC shows that the list of public subnets is not properly set. Let me go ask the team…

2 Likes

As a workaround: If a canister calls aaaaa-aa:create_canister the newly created canister will be on the same subnet. If you use one of your canisters on that subnet to create a new one you’ll have a new one there :slightly_smiling_face:

1 Like

Hey @evanmcfarland! Just to put as all on the correct page, this is the latest proposal that updates the list of authorized subnets. If you take a look at the payload you will see that your preferred subnet got closed because it has more than 400GB in total state. Sorry for the inconvenience and hope that the explanation helps!

If you are interested on how do we generate the list of subnets we intend to close / open you can find it on dre repo.

Cheers!

2 Likes

That’s a clever workaround. Thank you.

1 Like

Okay, I see. The subnet spiked above 400GiB for 2 days and then went back to ~250 GiB. I’ll use the canister create technique.

2 Likes