博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
如何区分 OpenStack Neutron Extension 和 Plugin
阅读量:5057 次
发布时间:2019-06-12

本文共 2496 字,大约阅读时间需要 8 分钟。

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。

转载于:https://www.cnblogs.com/zhutianshi/p/3902315.html

你可能感兴趣的文章
Android应用程序进程启动过程的源代码分析
查看>>
adb logcat 命令行用法
查看>>
Redis学习手册(Key操作命令)
查看>>
模板统计LA 4670 Dominating Patterns
查看>>
文件内容红帽子数据库.profile文件内容详解
查看>>
泛型第23条:请不要在新代码中使用原生态类型
查看>>
对象方法(转载)Java中finalize的使用
查看>>
一个截屏工具制作的全过程记录——如何使用“拿来主义”
查看>>
了解SpringMVC框架及基本工作流程
查看>>
软件开发之能力素养
查看>>
5.28 周末笔记
查看>>
git 永久性设置密码
查看>>
自拍机器人(摄影 拍照 录像)
查看>>
Installation for TinyOS on Ubuntu 16.04
查看>>
h5页面在不同ios设备上的问题总结
查看>>
Python的map、filter、reduce函数
查看>>
前端面试js题
查看>>
51NOD 大数加法以及python写法
查看>>
java四种数组排序
查看>>
(三)、
查看>>