This issue is the same under 1.4.1.

Greg Petras wrote:

This issue is the same under 1.4.1.

We are also affected by this issue. This did work successfully in 1.3.x, but is no longer working in 1.4.0 or 1.4.1. We would be more than happy to test any code changes if that would help speed up the lead time for a fix!

-Andrew

Using compute_profile_id won't work at the moment from what I can tell, since the attributes get filled in from the compute profile after validation. The validation though (MAC addresses) is failing because it needs to know during validation that the attributes are present.

It's not clear from either the description or Andrew's response whether you're only trying to use compute_profile_id or if you're using the original API call unsuccessfully too. If so, please supply the corresponding logs (the ones supplied show compute_profile_id only).

Hey Dominic -

#1 is definitely an issue. I was able to provision a host using the corresponding "network-<ID>" for the VM network. Here's an example:

{
  "host": {
    "subnet_id": null,
    "name": "<fqdn>",
    "build": "1",
    "compute_attributes": {
      "interfaces_attributes": {
        "0": {
          "network": "network-426",
          "type": "VirtualE1000",
          "_delete": "" 
        }
      },
      "cluster": "QAC1-ESX3001C",
      "volumes_attributes": {
        "1": {
          "thin": "0",
          "datastore": "qac1_nfs_1",
          "name": "Hard disk 1",
          "size_gb": 20
        }
      },
      "power_action": "start",
      "memory_mb": 2048,
      "path": "<path>",
      "cpus": 1,
      "start": "1" 
    },
    "hostgroup_id": "81",
    "medium_id": null,
    "managed": "true",
    "environment_id": 40,
    "provision_method": "build",
    "ptable_id": 11,
    "compute_resource_id": 2,
    "overwrite": "false",
    "enabled": "1" 
  }
}

We used to be able to provision VM's using the friendly VM network name. This is definitely a change from previous behavior. Can this be fixed? Or, can these networks be made available through the API?

#2 I inadvertently attached a log without the Content-Type header set.

3. Sounds good. Is this something that can potentially be fixed in the API as well?

I think the biggest issue at this point is being able to get a list of network id's and their respective names from the API (#1).

Thanks again for your help.

Greg

Sorry for the formatting issues. Reposting for clarity.

Hey Dominic -

1. This is definitely an issue. I was able to provision a host using the corresponding "network-<ID>" for the VM network. Here's an example:

{
  "host": {
    "subnet_id": null,
    "name": "<fqdn>",
    "build": "1",
    "compute_attributes": {
      "interfaces_attributes": {
        "0": {
          "network": "network-426",
          "type": "VirtualE1000",
          "_delete": "" 
        }
      },
      "cluster": "<cluster>",
      "volumes_attributes": {
        "1": {
          "thin": "0",
          "datastore": "<datastore>",
          "name": "Hard disk 1",
          "size_gb": 20
        }
      },
      "power_action": "start",
      "memory_mb": 2048,
      "path": "<path>",
      "cpus": 1,
      "start": "1" 
    },
    "hostgroup_id": "81",
    "medium_id": null,
    "managed": "true",
    "environment_id": 40,
    "provision_method": "build",
    "ptable_id": 11,
    "compute_resource_id": 2,
    "overwrite": "false",
    "enabled": "1" 
  }
}

We used to be able to provision VM's using the friendly VM network name. This is definitely a change from previous behavior. Can this be fixed? Or, can these networks be made available through the API?

2. I inadvertently attached a log without the Content-Type header set.

3. Sounds good. Is this something that can potentially be fixed in the API as well?

I think the biggest issue at this point is being able to get a list of network id's and their respective names from the API (#1).

Thanks again for your help.

Greg

Oh, I forgot to say: I'm not sure how the network IDs can be changed, we haven't done anything ourselves to do this. I suspect it's either rbvmomi (the VMware Ruby bindings) or on vSphere itself, as I can't see any relevant changes in network code in Fog.

Thanks Dominic.

1. I've submitted a PR for the available_* methods for VMware compute resources (#4581). This is working on our 1.4 test system.

3. I agree. Definitely will help to make an API around compute_profiles as compute profiles are somewhat hidden right now without it.

I appreciate your help. You can close this issue out.

Thanks,

Greg