Port: change hostID to struct with id and serverRef fields

[mandre]

This changes the Port API to use a structured hostID field instead of a simple string, allowing users to specify the host ID either directly or by referencing a Server resource.

[mandre]

@winiciusallan I'd like your feedback on this. Related to my concerns in #626.

[winiciusallan]

@mandre I have some questions just to clarify my thoughts and to ensure that we're on the same page.

Could you point out a use case where I would retrieve the host ID from a running server? Making some tests on my multinode environment, if I do:

create port A binded to host A -> create a server with port A into host B

Openstack will change the binding:host_id to the host B on port A, because to a port become UP as long as I know, it must be attached on the same host as the VM. So, now I'm wondering if we really want to expose this field and if a use case for that exists.

[mandre]

@mandre I have some questions just to clarify my thoughts and to ensure that we're on the same page.

Could you point out a use case where I would retrieve the host ID from a running server? Making some tests on my multinode environment, if I do:

create port A binded to host A -> create a server with port A into host B

Openstack will change the binding:host_id to the host B on port A, because to a port become UP as long as I know, it must be attached on the same host as the VM. So, now I'm wondering if we really want to expose this field and if a use case for that exists.

Port Binding is for pass-through scenarios (think SR-IOV), where only a subset of hosts would have SR-IOV capable NICs for example.

From a user perspective, you can only get the hostID from an existing server, so it would make sense to reference a server when creating a port bound to a hostID.

The use case would be:

1. Provision a server with flavor or scheduler hint ensuring we end up on the desired host. This gives us a hostID to work with.
2. Provision a port using portBinding referencing the above server.
3. Either update the existing server to add the extra interface or provision a new server with it.

I think we still want to leave the literal id as an option, in case the user already knows the host ID.

[winiciusallan]

Thanks for the detailed explanation.

Port Binding is for pass-through scenarios (think SR-IOV), where only a subset of hosts would have SR-IOV capable NICs for example.

From a user perspective, you can only get the hostID from an existing server, so it would make sense to reference a server when creating a port bound to a hostID.

Yeah, that's true, we already discussed this indeed.

The use case would be:

1. Provision a server with flavor or scheduler hint ensuring we end up on the desired host. This gives us a hostID to work with.

2. Provision a port using portBinding referencing the above server.

3. Either update the existing server to add the extra interface or provision a new server with it.

Got it. I'd add in somewhere saying that the hostID from port doesn't affect the schedule of the server, as you can see in the test I made in the first comment, so I'm afraid to have a inconsistency state. So imagine:

1. Create a port with hostID.ID = compute1
2. Attach it to a server without any scheduler option to a host
3. The server spawn in compute2
4. The binding information for the port change to compute2

And in the port spec, we have compute1 still. Am I thinking correctly?