Open Stack

On Wed, 2019-11-27 at 15:28 +0100, Bence Romsics wrote:
> Hi,
> 
> Matt wrote:
> > The point of the API change is to let neutron do everything
> > automatically and avoid additional configuration, right? The
> > configuration on the neutron side was meant to be a workaround.
> 
> I had the following reasons to propose using configuration:
> 
> (1) Using a nova API from neutron-server means we'd have a startup
> ordering dependency. Neutron would have to wait for nova to start up.
> So far it had to wait for placement - there we did not have an
> alternative. Here we have.
> 
> (2) We cannot use a new nova API for fixing this bug in stein and
> train. If the backportable fix works on master too, do we want to
> create a different fix for master?
> 
> Sean wrote:
> > > (1) Extend ovs and sriov agents config with
> > > 'resource_provider_hypervisors' for example:
> > > 
> > > ml2_conf.ini
> > > [ovs]
> > > bridge_mappings = physnet0:br-physnet0,...
> > > resource_provider_bandwidths = br-physnet0:10000000:10000000,...
> > > resource_provider_hypervisors = physnet0:hypervisor0,... # this is
> > 
> > im guessing you are adding this for the ironic smart nic usecasue but i dont think this makes sense.
> 
> That's right. I made a mistake there. Thanks for catching it. I meant
> keying resource_provider_hypervisors by the physdevs (the values in
> mappings) not the physnets. For example:
> 
> resource_provider_hypervisors = br-physnet0:hypervisor0,...
this also wont work as the same bridge name will exists on multipel hosts
> 
> I understand we don't have use for this right now (neutron with ironic
> does not use placement), but if we don't allow the 1:N mapping here,
> then we prohibit the future use of it too.
> 
> Cheers,
> Bence
>