Thanks for the heads up, Kevin!
Is this still necessary if a deployment disables the Neutron server's DHCP
scheduling, with
self._supported_extension_aliases.remove("dhcp_agent_scheduler")
?
Thanks,
Neil
On Fri, Mar 31, 2017 at 12:52 AM Kevin Benton <ke...@benton.pub> wrote:
> Hi,
>
> Once [1] merges, a port will not transition to ACTIVE on a subnet with
> enable_dhcp=True unless something clears the DHCP provisioning block.
>
> If your mechanism driver uses the in-tree DHCP agent, there is nothing you
> need to do. However, if you do not utilize the DHCP agent in your
> deployment scenarios and you offload DHCP to something else, your mechanism
> driver must now explicitly acknowledge that DHCP has been provisioned for
> that port.
>
> Acknowledging that DHCP is ready for a port is a one-line call to the
> provisioning_blocks module[2]. For more information on provisioning blocks,
> see [3].
>
> 1. https://review.openstack.org/452009
> 2.
> https://github.com/openstack/neutron/blob/4ed53a880714fd33280064c58e6f91b9ecd3823e/neutron/api/rpc/handlers/dhcp_rpc.py#L292-L294
> 3.
> https://docs.openstack.org/developer/neutron/devref/provisioning_blocks.html
>
> Cheers,
> Kevin Benton
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
