如何区分 OpenStack Neutron Extension 和 Plugin

Neutron 里面的 extension 和 plugin 是非常相似的两个概念,我花了好久才貌似搞懂了两者的区别,还不一定完全正确。

在OpenStack 的官网wiki中,可以找到它们两个的定义:

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.

具体链接在这里:https://wiki.openstack.org/wiki/NeutronDevelopment

由上述定义,再结合 Neutron 源代码中的一些文件可以看出,其实一个官方的核心插件(Core Plugin)只包括三种资源:Network, Subnet 以及 Port。插件必须能够与一些交换机沟通,实现逻辑上的二层和三层网络。而当我们需要在Neutron中加入更多的网络资源,例如 Router, Load Balancer, Gateway, VPN, Security Group 等的时候,extension 就出场了。这些额外的资源都可以在 extension 中进行定义,例如我在之前的文章中提到的RESOURCE_ATTRIBUTE_MAP等。

在官网中,我们还可以看到,extension还分三种:

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.

可以看到,第一种 Resource extensions 就是我们说的在需要加入更多新资源的时候可以用到。

第二种 Action extensions 就是在我们需要加入新动作的时候可以用到。比如说我有一个 Gateway 资源,希望可以把它和许多 Network 关联起来,这个操作可能就不存在于传统的CRUD中,那我就需要定义一个新的 Action Extension。

第三种我也不是特别理解,可能是说Request Extension是可以用来处理已经存在的资源的一些新增属性。例如 Network 资源多出来一个 priority 属性,传统的CRUD只针对 Network 原有的属性,不会去涉及到 priority 的值,那我就需要针对 priority 属性定义一个新的 Request Extension。

所以根据上面的描述,在我们要开发 Neutron 的时候,第一个要决定的事情就是我到底要写一个 Extension 还是 Plugin?如果我需要新增一些资源,那毫无疑问必须上 Extension; 如果我要实现一个新的与交换机沟通的方法,那就需要实现一组新的 Plugin。

如何区分 OpenStack Neutron Extension 和 Plugin,布布扣,bubuko.com

时间: 2025-01-06 13:07:02

如何区分 OpenStack Neutron Extension 和 Plugin的相关文章

怎样写 OpenStack Neutron 的 Extension (四)

上文说到需要在 /neutronclient/v2_0/myextension/extension.py 中分别定义五个 class:List/Show/Create/Delete/UpdateExtension.具体形式如下: import argparse import logging from neutronclient.neutron import v2_0 as neutronV20 from neutronclient.openstack.common.gettextutils im

怎样写 OpenStack Neutron 的 Extension (一)

前两篇文章讨论了怎么写一个 Neutron 的插件.但是最基本的插件只包括 Network, Port,和 Subnet 三种资源.如果需要引入新的资源,比如一个二层的 gateway 的话,就需要在插件的基础上再写一个 extension, 也就是扩展. Neutron 已经预定义了很多扩展,可以参看 neutron/extensions 下面的文件,我在这里就不一一列举了.如果正好有一种是你需要的,那直接拿过来用就好了.如果需要自己从头搭起的话,可以现在 自己的 plugin 文件夹下面创建

怎样写 OpenStack Neutron 的 Plugin (二)

其实上一篇博文中的内容已经涵盖了大部分写Neutron插件的技术问题,这里主要还遗留了一些有关插件的具体实现的问题. 首先,Neutron对最基本的三个资源:Network, Port 和 Subnet 的基本调用都已经定义好了API接口.如果你的插件也需要用到这些资源,最好直接实现它们的接口.API接口的定义可以再 neutron/neutron_plugin_base_v2.py 这个文件中找到,其中每个参数的作用也有比较详细的介绍.对于用不着的资源,直接放任不管就好了,最多下次不小心调用了

怎样写 OpenStack Neutron 的 Extension (三)

通过上几章的介绍,我们现在的 myplugin 文件夹看上去应该是这样的: - neutron/ - plugins/ - myplugin/ - __init__.py - plugin.py - extensions/ - __init__.py - myextension.py - db/ - __init__.py - db.py - models.py 我们的plugin.py看上去应该是类似这样的: from neutron import neutron_plugin_base_v2

怎样写 OpenStack Neutron 的 Extension (二)

接着之前一篇文章,再来谈谈 Extension 的具体实现问题.我使用的是本地数据库加远程API调用的方法,所以先要定义一下数据库中 myextension 如何存储.首先,我们可以在自己的 plugin 根目录下新建一个 db 文件夹,以及三个文件: - neutron/ - plugins/ - myplugin/ - __init__.py - plugin.py - extensions/ - db/ - __init__.py - db.py - models.py db.py 用来存

怎样写 OpenStack Neutron 的 Plugin (一)

鉴于不知道Neutron的人也不会看这篇文章,而知道的人也不用我再啰嗦Neutron是什么东西,我决定跳过Neutron简介,直接爆料. 首先要介绍一下我的开发环境.我没有使用DevStack,而是直接在电脑上安装了三个Virtual Box,然后根据OpenStack的Ubuntu 安装指南部署了一个环境:一个控制节点,一个网络节点和一个计算节点.接下来我会直接在控制节点上修改 <your path>/neutron/ 下面的文件,然后通过重启neutron 的各个service来更新我的修

OpenStack Neutron 之 Load Balance

OpenStack Neutron 之 Load Balance 负载均衡(Load Balance)是 OpenStack Neutron 支持的功能之一.负载均衡能够将网络请求分发到多个实际处理请求的虚机上,这样能有效处理高流量的网络请求,负载均衡在现实中有很多使用场景.本文将基于 Neutron 所提供的负载均衡,介绍其基本概念.实现过程,并验证其功能. Neutron Load Balance 简介 负载均衡(Load Balance)其实早在 OpenStack 的 Grizzly 版

openstack Neutron分析(3)—— neutron-dhcp-agent源码分析

1.neutron dhcp3个主要部件分别为什么?2.dhcp模块包含哪些内容?3.Dnsmasq配置文件是如何创建和更新的?4.DHCP agent的信息存放在neutron数据库的哪个表中? 扩展: neutron-dhcp-agent在neutron的作用是什么? 一.概述 neutron dhcp为租户网络提供DHCP服务,即IP地址动态分配,另外还会提供metadata请求服务. 3个主要的部件:DHCP agent scheduler:负责DHCP agent与network的调度

Openstack Neutron OVS ARP Responder

ARP – Why do we need it? In any environment, be it the physical data-center, your home, or a virtualization cloud, machines need to know the MAC, or physical network address, of the next hop. For example, let there be two machines connected directly