response to vm spawn may contain invalid values

[Andrea Frittoli]

When spawning a VM via nova API, the response contains a description of the server with the information available at API level.

However the API makes assumptions for some of the fields which may turn out to be incorrect.

For example:

- availability zone: the default one is returned by the API, however logic in the scheduler may cause the non-default AZ to be used

- security group: when spawning a VM using the --nic port=<uuid> flag in a neutron deployment, the server response shows the security group "default" in none was specified at creation time. However the correct SGs are those (if any) attached to the port rather than default

The response from the API shall only contain information which the API can control.

[Matt Riedemann (mriedem)]

For the availability zone issue, this was just merged, does it resolve that problem?

https://review.openstack.org/#/c/28645/

[Jeffrey Zhang (jeffrey4l)]

I don't think query the port details in the nova api code. I don't find any similar process in the code, either.

I think the best solution should be change the api behavior.

When there is no security_group, we should not configure a default security group name in nova-api's code. We should take this determination into nova-compute/nova-network or neutron's code.

is this acceptable?

[Jeffrey Zhang (jeffrey4l)]

The security group should be bond with port or net. But in the current api behavior, the security group is separated with that.

So the API have some confused meaning when there are security group and port parameters. Like following

    nova boot test --security_group sec1 --security_group sec2 --net port=xxxxxx -net port=yyyyyy

[Feodor Tersin (ftersin)]

If no SG is specified for create instance operation, Nova adds 'default' SG to the response:
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/plugins/v3/security_groups.py#L469

There is https://review.openstack.org/#/c/173204/1 which partially fixes this behavior.

[Markus Zoeller (markus_z) (mzoeller)]

This is an automated cleanup. This bug report has been closed because it
is older than 18 months and there is no open code change to fix this.
After this time it is unlikely that the circumstances which lead to
the observed issue can be reproduced.

If you can reproduce the bug, please:
* reopen the bug report (set to status "New")
* AND add the detailed steps to reproduce the issue (if applicable)
* AND leave a comment "CONFIRMED FOR: <RELEASE_NAME>"
  Only still supported release names are valid (LIBERTY, MITAKA, OCATA, NEWTON).
  Valid example: CONFIRMED FOR: LIBERTY