Error: "The specified project contains insufficient public IPv4 space to complete the request." When Deploying ESXI

[carpejem]

A customer reported that he's unable to deploy ESXI server via Python with the error:

The specified project contains insufficient public IPv4 space to complete the request. Please e-mail support@packet.com.

Here's the exact command he's running:

manager.create_device(

project_id=_DEFAULT_PROJECT_ID,

hostname='{}-vcsa'.format(name_prefix),

plan=_DEFAULT_VCSA_HOST_PLAN,

facility=_DEFAULT_ZONE,

operating_system=_DEFAULT_ESXI_OS,

public_ipv4_subnet_size=29,

)

If the public_ipv4_subnet_size=29 is omitted the error message becomes:

packet.baseapi.Error: Error 422: Public ipv4 subnet size '31' is invalid for VMware ESXi 6.5

For unknown reasons, we're unable to replicate this using our Packet staff account but can be replicated using our personal (non-staff) account.

[dgjustice]

I am able to replicate.

Using the API, POST to https://api.packet.net/projects/{project_id}/devices works fine with the body:

{"facility": "e1e9c52e-a0bc-4117-b996-0fc94843ea09","plan": "c1.small.x86","hostname": "foo","description": "foobar","operating_system": "cba7390b-e9da-4536-8e77-c334de4baea8"}

The server gets created with the appropriate public network when it isn't specified in the payload.

[displague]

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.

https://github.com/packethost/packet-python/blob/master/packet/Manager.py#L132

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.

What do you think, @carpejem?