You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If I am understanding the report here, I believe this is the intended behavior.
The public_ipv4_subnet_size is not determined server-side based on the chosen OS, rather the client will always submit a public_ipv4_subnet_size of 31 unless the developer provides an alternate value.
In provisioning ESXi, with this server-side validation in place (Public ipv4 subnet size '31' is invalid for VMware ESXi 6.5), a developer will have to make sure they provide a valid public_ipv4_subnet_size in the request.
If the API does the right thing when public_ipv4_subnet_size is omitted, then we should consider making the default value in this client None, leaving the decision up to the API unless the developer knowingly overrides it. In cases where extra IP reservations are needed, I think it is reasonable to require the developer to take extra measures.
It would help if we captured more context about the expected behavior and intentions of this client (rather than my speculation).
I'm prepared to close this issue on the grounds that the current behavior creates a minor inconvenience with good intention.
A customer reported that he's unable to deploy ESXI server via Python with the error:
Here's the exact command he's running:
If the public_ipv4_subnet_size=29 is omitted the error message becomes:
For unknown reasons, we're unable to replicate this using our Packet staff account but can be replicated using our personal (non-staff) account.
![image](https://user-images.githubusercontent.com/16787381/80270024-57649b80-86e7-11ea-80e3-d31376d6fbb1.png)
The text was updated successfully, but these errors were encountered: