如何区分 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

时间: 08-07

如何区分 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数据库

一.Neutron 数据库的整体架构图 Neutron Database采用的是分布式架构,由3台服务器组成一个cluster.Neutron Server通过Plugin,然后发送给Neutron Database的VIP, HAProxy收到消息后,转发给database的实地址. 1.Neutron server 接收 api 请求. 2.plugin转换消息,发送给database 3.database 保存 neutron 网络状态. 4.HAProxy实现数据的主备保护 二. Neu

openstack neutron L3 HA

作者:Liping Mao  发表于:2014-08-20 版权声明:可以任意转载,转载时请务必以超链接形式标明文章原始出处和作者信息及本版权声明 最近Assaf Muller写了一篇关于Neutron L3 HA的文章很不错. 建议看原文,地址如下: http://assafmuller.wordpress.com/category/ml2/ 大致翻译如下: L3 Agent Low Availability(L3 agent的低可用性) 目前,在Openstack中,你只能用多个网络节点达到

深入浅出新一代云网络——VPC中的那些功能与基于OpenStack Neutron的实现(二)

在VPC功能实现第一篇中,简单介绍了一下VPC网络对租户间隔离能力的提升以及基于路由提供的一系列网络功能.在这一篇中,将继续介绍VPC网络中十分重要的一个内容:网络带宽的控制,共享以及分离. 首先是对第一篇中,端口转发功能的样例代码,all-in-one http service 风格的实现. 核心功能: find_router_ip = "ip netns exec qrouter-{router_id} ifconfig |grep -A1 qg- | grep inet | awk '{{

第五十八课 Openstack Neutron网络模型及Cinder基础及部署

OpenStack  Neutron网络模型详解 OpenStack  Cinder基础及部署

[转]OpenStack Neutron运行机制解析概要

转载自:http://panpei.net.cn/2013/12/04/openstack-neutron-mechanism-introduce/ 自从开学以来,玩OpenStack也已经3个月了,这段时间主要把精力投在了OpenStack的安装部署和网络组件Neutron的研究上了.这期间零零散散在安装部署和Neutron运作原理上来回切换,有点在实践中学习的味道,虽然在安装部署的过程遇到了不少的问题,也一一都给解决了.然而,总是觉得对于Neutron的机制理解的还是不够透彻.前一阵子刚刚部

OpenStack 学习笔记(六):OpenStack neutron服务搭建

--先决条件 1.)创建数据库 MariaDB [(none)]> CREATE DATABASE neutron; Query OK, 1 row affected (0.00 sec) MariaDB [(none)]> GRANT ALL PRIVILEGES ON neutron.* TO 'neutron'@'localhost' IDENTIFIED BY 'neutron'; Query OK, 0 rows affected (0.00 sec) MariaDB [(none)

深度探索 OpenStack Neutron:BGP(1) 【转载】

3.4 BGP 原文地址:http://mp.weixin.qq.com/s?src=3&timestamp=1500043305&ver=1&signature=XwiIVVLHaVK5kzRNQKR1dkOzl1DR375P-R9g998sGTpT8WF20P9REPkYOfS85KOlI2h8RnHL3jvJvFu6gu*CNceX8Ky1iJXeGkX1NGYyMFruvBNS1XsJUv3RHgtEpGEIdMN4UZfKkUcdQQ6b9ZbvkqUaAcyanc3bh

Floating IP in OpenStack Neutron

前言 Floating IP 是相对于Fixed IP而言的,它一般是在VM创建后分配给VM的,可以达到的目的就是,外界可以访问通过这个Floating Ip访问这个VM,VM也可以通过这个IP访问外界. 在OpenStack中,这个Floating IP使用了namespace内的iptables建立NAT 转发机制来达到VM与外界的通讯的.这片文章主要讲述如何使用OpenStack搭建和使用Floating IP. Environment Setup Ubuntu 14.04 LTS 2个网