How to differentiate openstack neutron extension and plugin

The extension and plug-in concepts in neutron are very similar. It took me a long time to understand the differences between the two. They are not necessarily correct yet.

On the openstack wiki, you can find two definitions:

Plugin:

Neutron exposes a logical API to define network connectivity between devices from other OpenStack services (e.g., vNICs from Nova VMs). The logical connectivity described using the API must be translated into actually configuration on virtual and/or physical switches. This is where a Neutron plugin comes in. The Neutron plugin is able to talk to one or more types of switches and dynamically reconfigures the switches based on API calls.

Extension:

API Extensions allow a plugin to extend the Neutron API in order to expose more information. This information could be required to implement advanced functionality that is specific to a particular plugin, or to expose a capability before it has been incorporated into an official Neutron API.

Link here: https://wiki.openstack.org/wiki/NeutronDevelopment

From the above definition, combined with some files in the neutron source code, we can see that an official core plug-in actually contains only three resources: Network, subnet, and port. The plug-in must be able to communicate with some vswitches to implement a logical layer-2 and layer-3 network. When we need to add more network resources in neutron, such as router, Load balancer, gateway, VPN, and security group, extension will be available. These additional resources can be defined in extension, such as resource_attribute_map I mentioned in previous articles.

On the official website, we can also see that extension is divided into three types:

Resource extensions introduce a new "entity" to the API. In Neutron, current entities are "networks" and "ports".Action extensions tend to be "verbs" that act on a resource. For example, in Nova, there is a "server" resource, and a "rebuild" action on that server resource: http://docs.openstack.org/cactus/openstack-compute/developer/openstack-compute-api-1.1/content/Rebuild_Server-d1e3538.html#d2278e1430 . Core Neutron API doesn‘t really use "actions" as part of the core API, but extensions certainly could.Request extensions allow one to add new values to existing requests objects. For example, if you were doing a POST to create a server, but wanted to add a new ‘widgetType‘ attribute for the server object.

We can see that the first type of resource extensions is used when we need to add more new resources.

The second type of action extensions can be used when we need to add new actions. For example, if I have a gateway resource and want to associate it with many networks, this operation may not exist in the traditional crud, so I need to define a new action extension.

In the third case, I do not particularly understand it. It may be that request extension can be used to process some new attributes of existing resources. For example, if the network resource has an extra priority attribute, the traditional crud only applies to the original network attribute and does not involve the priority value, then I need to define a new request extension for the priority attribute.

So according to the above description, when we are developing neutron, the first thing to decide is whether I want to write an extension or plugin? If I need to add some resources, there is no doubt that I must go to extension; if I want to implement a new method of communicating with the switch, then I need to implement a new set of plugins.