Open Stack

> 
>> 
>> - Multiple agreements about strict minimum bandwidth support feature 
>> in nova -  Spec has already been updated accordingly: 
>> https://review.openstack.org/#/c/502306/
>> 
>>    - For now we keep the hostname as the information connecting the 
>> nova-compute and the neutron-agent on the same host but we are 
>> aiming for having the hostname as an FQDN to avoid possible 
>> ambiguity.
>> 
>>    - We agreed not to make this feature dependent on moving the nova 
>> port create to the conductor. The current scope is to support 
>> pre-created neutron port only.
> 
> I could rat-hole in the spec, but figured it would be good to also 
> mention it here. When we were talking about this in Dublin, someone 
> also mentioned that depending on the network on which nova-compute 
> creates a port, the port could have a QoS policy applied to it for 
> bandwidth, and then nova-compute would need to allocate resources in 
> Placement for that port (with the instance as the consumer). So then 
> we'd be doing allocations both in the scheduler for pre-created ports 
> and in the compute for ports that nova creates. So the scope 
> statement here isn't entirely true, and leaves us with some technical 
> debt until we move port creation to conductor. Or am I missing 
> something?
> 

I was sloppy and did not include all the details here. The spec goes 
into a lot more detail about what and how needs to be supported in the 
first iteration[1]. I still think that moving the port creation to the 
conductor is not a hard dependency of the first iteration of this 
feature. I also feel that we agreed on this on the PTG.

Cheers,
gibi

[1] 
https://review.openstack.org/#/c/502306/15/specs/rocky/approved/bandwidth-resource-provider.rst@111