SDN refers to separating the network control plane from the forwarding plane. There are two main architectural approaches for SDN: overlay models which use tunneling/encapsulation, and underlay models which manipulate flows and use a centralized controller. Open vSwitch is commonly used as the software switch in OpenStack and supports SDN protocols like OpenFlow. OpenStack's Neutron project provides APIs for SDN controllers to integrate with and configure virtual networks. OpenDaylight is an open source SDN controller that can be used with OpenStack for features like L3 routing, LBaaS, and direct integration between Nova and Open vSwitch.
The Havana release of OpenStack, came out in October 2013, contains several significant changes and new features in the networking component. OpenStack Networking has changed name from 'quantum' to 'neutron'. It lays the foundation for supporting heterogeneous network components with the introduction of the ML2 (modular layer 2) plugin. The first implementations of FireWall as a Service (FWaaS) and VPN as a Service (VPNaaS) are now included. These features were demonstrated by Cisco developers at the OpenStack meetup in Boston in Oct 2013.
David Lenwell from Akanda will briefly recap basic Neutron topics around network architecture and common features such as security groups, plugins and agents, then dive in deeper, focusing on advanced services such as Routing and Load Balancing. We will then drill down into typical service provider network designs and the specific technologies in use such as Linuxbridge. We will discuss the Neutron Advanced Services driver model and how it can be useful to Service Providers (and Enterprises) based on our team's experience powering DreamCompute’s networking capabilities using Akanda. We will review Akanda, an open source suite of software, services, orchestration, and tools for providing L3+ services in OpenStack that builds on top of Linux and OpenStack Neutron. Using Akanda, an OpenStack provider can provide tenants with a rich, powerful set of L3+ services. Finally, we will provide an update on the latest discussions heading into Tokyo such as the status of LBaaS, FWaaS as well as the newer Neutron projects such as L2 Gateway, the Neutron Stadium effort and the new Lieutenant system.
This document discusses OpenStack SDN using Neutron and GRE tunneling. It explains that Neutron provides networking as a service and uses plugins like ml2 with Open vSwitch for SDN. GRE tunneling is used to encapsulate VM traffic between compute and network nodes. Network namespaces are used to create isolated virtual routers and DHCP servers without collisions on each node. The packet flow between an external network, routers, bridges and a VM is outlined.
Use Neutron instead of nova-network
●
neutron_url = http://neutron:9696
●
neutron_auth_strategy = keystone
●
neutron_admin_auth_url = http://keystone:35357/v2.0
●
neutron_admin_username = neutron
●
neutron_admin_tenant_name = service
●
neutron_admin_password = password
Nova interaction with Neutron
1. Create network, subnet, router etc via Neutron API
2. Boot VM, pass network info to Neutron
3. Attach ports, floating IP via Neutron
4. On delete,
Networking with Neutron is one of the most complex subsystems in Openstack. In this talk we shed light on the key components of Neutron networking and the specialities of the relatively new ML2 core plugin.
SDN refers to separating the network control plane from the forwarding plane. There are two main architectural approaches for SDN: overlay models which use tunneling/encapsulation, and underlay models which manipulate flows and use a centralized controller. Open vSwitch is commonly used as the software switch in OpenStack and supports SDN protocols like OpenFlow. OpenStack's Neutron project provides APIs for SDN controllers to integrate with and configure virtual networks. OpenDaylight is an open source SDN controller that can be used with OpenStack for features like L3 routing, LBaaS, and direct integration between Nova and Open vSwitch.
The Havana release of OpenStack, came out in October 2013, contains several significant changes and new features in the networking component. OpenStack Networking has changed name from 'quantum' to 'neutron'. It lays the foundation for supporting heterogeneous network components with the introduction of the ML2 (modular layer 2) plugin. The first implementations of FireWall as a Service (FWaaS) and VPN as a Service (VPNaaS) are now included. These features were demonstrated by Cisco developers at the OpenStack meetup in Boston in Oct 2013.
David Lenwell from Akanda will briefly recap basic Neutron topics around network architecture and common features such as security groups, plugins and agents, then dive in deeper, focusing on advanced services such as Routing and Load Balancing. We will then drill down into typical service provider network designs and the specific technologies in use such as Linuxbridge. We will discuss the Neutron Advanced Services driver model and how it can be useful to Service Providers (and Enterprises) based on our team's experience powering DreamCompute’s networking capabilities using Akanda. We will review Akanda, an open source suite of software, services, orchestration, and tools for providing L3+ services in OpenStack that builds on top of Linux and OpenStack Neutron. Using Akanda, an OpenStack provider can provide tenants with a rich, powerful set of L3+ services. Finally, we will provide an update on the latest discussions heading into Tokyo such as the status of LBaaS, FWaaS as well as the newer Neutron projects such as L2 Gateway, the Neutron Stadium effort and the new Lieutenant system.
This document discusses OpenStack SDN using Neutron and GRE tunneling. It explains that Neutron provides networking as a service and uses plugins like ml2 with Open vSwitch for SDN. GRE tunneling is used to encapsulate VM traffic between compute and network nodes. Network namespaces are used to create isolated virtual routers and DHCP servers without collisions on each node. The packet flow between an external network, routers, bridges and a VM is outlined.
Use Neutron instead of nova-network
●
neutron_url = http://neutron:9696
●
neutron_auth_strategy = keystone
●
neutron_admin_auth_url = http://keystone:35357/v2.0
●
neutron_admin_username = neutron
●
neutron_admin_tenant_name = service
●
neutron_admin_password = password
Nova interaction with Neutron
1. Create network, subnet, router etc via Neutron API
2. Boot VM, pass network info to Neutron
3. Attach ports, floating IP via Neutron
4. On delete,
Networking with Neutron is one of the most complex subsystems in Openstack. In this talk we shed light on the key components of Neutron networking and the specialities of the relatively new ML2 core plugin.
OpenStack networking - Neutron deep dive with PLUMgridKamesh Pemmaraju
These are slides from the OpenSTack Meeting in Boston on Marck 18, 2015. The session led by Fernando Sanchez - Principal Systems Engineer, at PLUMgrid. In this talk, Fernando discussed OpenStack architecture with a particular focus on networking. We’ll cover some important considerations for networking in your OpenStack cloud, provide a look at common terminology, and discuss how Open Networking Suite works with OpenStack to alleviate networking challenges.
How to write a Neutron Plugin - if you really need tosalv_orlando
Slides for the talk from Salvatore Orlando and Armando Migliaccio at the Openstack Summit - Fall 2013 in Hong Kong
Talk abstract: http://openstacksummitnovember2013.sched.org/event/c6478ecf54d639de3b8b9958bfe9d450#.UnLEI5ROpU0
Kyle Mestery provided an update on OpenStack Networking (Neutron) priorities for the Liberty release. Key areas of focus include continuing the plugin decomposition effort, improving the API, enabling quality of service features, and integrating network services like load balancing and VPN. Governance changes are also underway to help scale Neutron development.
OpenStack Neutron Havana Overview - Oct 2013Edgar Magana
Presentation about OpenStack Neutron Overview presented during three meet-ups in NYC, Connecticut and Philadelphia during October 2013 by Edgar Magana from PLUMgrid
Networking in OpenStack for non-networking people: Neutron, Open vSwitch and ...Dave Neary
This document discusses networking in OpenStack and Neutron. It begins with an overview of the OSI model and networking in a virtual world using Open vSwitch. It then covers Neutron and how it provides high-level abstractions for networking while abstracting away the internals. The document demonstrates how to create subnets and attach instances using Neutron. It also discusses debugging networking issues through examining devices, tracking packets, and looking at DHCP and routing tables. Resources for further information are provided at the end.
Introduction to Software Defined Networking and OpenStack NeutronSana Khan
Virtualization allows for more efficient use of server resources by running multiple virtual machines on a single physical server. This is done through the use of a hypervisor which creates isolated virtual machines, each with their own operating system and applications. Networking in virtualized environments is enabled through software-defined networking which decouples the network control and forwarding functions from the underlying hardware, allowing for centralized programmatic control of network resources. Neutron is OpenStack's networking component that provides software-defined networking capabilities like network provisioning and virtual port management.
The document discusses OpenStack Neutron and Software Defined Networks (SDN). It begins with an agenda for a demonstration of Neutron including creating networks, spawning VMs, testing connectivity, and creating load balancers. It then provides an overview of Neutron components and architecture, including the modular layer 2 plugin. It demonstrates Neutron APIs and network namespaces. It introduces SDN concepts like the control plane and network virtualization. Finally, it discusses how Neutron enforces SDN through plugins like PLUMgrid that implement the functionality on software edges in compute nodes.
These are the slides from the webinar "OpenStack networking (Neutron)", which covered the topics:
- OpenStack Networking: the Neutron project (NaaS);
- Main features of Neutron;
- Advanced networking functionalities in OpenStack.
This document provides an overview of OpenStack Neutron, the networking component of OpenStack. It describes Neutron's architecture and components, how it uses Linux networking and Open vSwitch, and how network packets flow through the Neutron distributed virtual router architecture. Key concepts covered include Neutron plugins, agents, GRE tunnels, Linux network namespaces, and east-west vs north-south traffic flows in a DVR configuration.
OpenStack Neutron Advanced Services by AkandaSean Roberts
Sean Roberts, VP Development Akanda, gave this talk on 03 September 2015 at the HP Sunnyvale offices. This talk goes into detail of how Akanda delivers OpenStack Neutron Advanced Services. Event details can be found here http://www.meetup.com/openstack/events/215648162/
Scaling OpenStack Neutron in Heterogeneous EnvironmentsMartin Klein
Scaling an Openstack deployment requires serious thought and consideration, commonly it is achieved by multiplying the constrained resource. A notable exception is Neutron, in particular the L2 subsystem. The L2 network needs to scale up while most connected components are scaling out. A common approach to scaling the number of available L2 network segments in a region is the introduction of advanced overlay networks, with the drawback that all connected devices need to implement the overlay protocol. Installations requiring multiple hypervisor types or bare metal have a limited number of overlay protocol options.
Neutron provides an alternative to a single overlay protocol; separating L2 in the network fabric from the protocol used on the network edge via Hierarchical Port Binding.
This talk introduces a Neutron HPB architecture and ML2 implementation currently in use at SAP. We will discuss the issues that HPB solved and the challenges faced during our HPB deployment.
This document provides an overview of several open source backend alternatives for OpenStack Neutron, including OpenDaylight, Ryu Network OS, and Open Contrail. It summarizes Neutron's built-in solution using ML2 and OVS agents, and how each open source alternative integrates with Neutron. Setup instructions are provided to try each alternative using Devstack.
ONUG Tutorial: Bridges and Tunnels Drive Through OpenStack Networkingmarkmcclain
This document summarizes OpenStack networking (Neutron) and discusses its key components and architecture. It describes how Neutron provides network abstraction and virtualization through pluggable backend drivers. It also outlines some common Neutron features like security groups and highlights new capabilities in the Juno release like IPv6 support and distributed virtual routing. The document concludes by looking ahead to further networking developments in OpenStack.
This document discusses OpenStack Neutron and software defined networking. It provides an overview of Neutron and how it allows network as a service capabilities. It describes the packet flow for virtual machines accessing the external network or communicating between virtual machines on the same network. It explains how Neutron integrates with Open vSwitch on the compute nodes to provide networking and discusses the various Neutron agents.
2014 OpenStack Summit - Neutron OVS to LinuxBridge MigrationJames Denton
Presentation titled 'Migrating production workloads from OVS to LinuxBridge'. Presented at the Fall 2014 OpenStack summit in Paris, this slide deck introduced the possibility of migrating live workloads from Open vSwitch to LinuxBridge with minimal downtime.
OVN: Scaleable Virtual Networking for Open vSwitchmestery
OVN is a network virtualization architecture that allows for scalable virtual networking on Open vSwitch. It abstracts virtual networking from physical networking and provides the same features as physical networks. OVN uses distributed logical flows and databases coordinated by local controllers to convert logical flows to physical flows. This allows for high performance, scalable virtual networking without depending on the physical topology.
- OpenStack provides network virtualization and automation capabilities through projects like Neutron, Heat, and plugins like Midonet.
- Neutron evolved networking in OpenStack to allow pluggable networking models beyond the initial Nova networking. It supports overlay technologies and network automation.
- Heat allows you to define infrastructure like servers, networks, and their relationships in templates that can be deployed through the OpenStack API. This provides automation of virtual network deployment.
- Plugins like Midonet provide distributed virtual networking models to improve scalability and performance over overlay approaches like OVS. They also allow automation of physical network configuration.
This document provides an overview and agenda for a presentation on OpenStack networking. It begins with an overview of OpenStack architecture and services like Compute, Networking, Identity and Image services. It then discusses basic network components like controllers, compute nodes and networking plugins. Next, it covers networking process flows and dives deeper into the Neutron networking plugin, including the Modular Layer 2 plugin framework and drivers like Open vSwitch. It concludes with a planned demonstration of networking functionality in an OpenStack lab environment.
In this session we will illustrate the work done during Kilo to improve the Neutron L2 and the L3 agents. We will start with a deep dive into both agents, explaining how they work. We will then give an overview of their deficiencies before Kilo and we will show how we tackled and solved them. We will describe future enhancements and performance gains that will be possible in future releases because of this debt repayment. We will also provide benchmark data to measure the improvement in terms of performance and scalability where applicable.
The document provides details about an OpenStack API development workshop conducted by Liang Bo. The 2-day workshop covers topics like developing with OpenStack, developer tools, OpenStack APIs, SDKs and includes hands-on sessions to build a tiny project using OpenStack APIs. Day 1 covers introduction, developing with OpenStack, tools and OpenStack RESTful APIs. Day 2 focuses on workshops to use OpenStack APIs and SDKs.
OpenStack networking - Neutron deep dive with PLUMgridKamesh Pemmaraju
These are slides from the OpenSTack Meeting in Boston on Marck 18, 2015. The session led by Fernando Sanchez - Principal Systems Engineer, at PLUMgrid. In this talk, Fernando discussed OpenStack architecture with a particular focus on networking. We’ll cover some important considerations for networking in your OpenStack cloud, provide a look at common terminology, and discuss how Open Networking Suite works with OpenStack to alleviate networking challenges.
How to write a Neutron Plugin - if you really need tosalv_orlando
Slides for the talk from Salvatore Orlando and Armando Migliaccio at the Openstack Summit - Fall 2013 in Hong Kong
Talk abstract: http://openstacksummitnovember2013.sched.org/event/c6478ecf54d639de3b8b9958bfe9d450#.UnLEI5ROpU0
Kyle Mestery provided an update on OpenStack Networking (Neutron) priorities for the Liberty release. Key areas of focus include continuing the plugin decomposition effort, improving the API, enabling quality of service features, and integrating network services like load balancing and VPN. Governance changes are also underway to help scale Neutron development.
OpenStack Neutron Havana Overview - Oct 2013Edgar Magana
Presentation about OpenStack Neutron Overview presented during three meet-ups in NYC, Connecticut and Philadelphia during October 2013 by Edgar Magana from PLUMgrid
Networking in OpenStack for non-networking people: Neutron, Open vSwitch and ...Dave Neary
This document discusses networking in OpenStack and Neutron. It begins with an overview of the OSI model and networking in a virtual world using Open vSwitch. It then covers Neutron and how it provides high-level abstractions for networking while abstracting away the internals. The document demonstrates how to create subnets and attach instances using Neutron. It also discusses debugging networking issues through examining devices, tracking packets, and looking at DHCP and routing tables. Resources for further information are provided at the end.
Introduction to Software Defined Networking and OpenStack NeutronSana Khan
Virtualization allows for more efficient use of server resources by running multiple virtual machines on a single physical server. This is done through the use of a hypervisor which creates isolated virtual machines, each with their own operating system and applications. Networking in virtualized environments is enabled through software-defined networking which decouples the network control and forwarding functions from the underlying hardware, allowing for centralized programmatic control of network resources. Neutron is OpenStack's networking component that provides software-defined networking capabilities like network provisioning and virtual port management.
The document discusses OpenStack Neutron and Software Defined Networks (SDN). It begins with an agenda for a demonstration of Neutron including creating networks, spawning VMs, testing connectivity, and creating load balancers. It then provides an overview of Neutron components and architecture, including the modular layer 2 plugin. It demonstrates Neutron APIs and network namespaces. It introduces SDN concepts like the control plane and network virtualization. Finally, it discusses how Neutron enforces SDN through plugins like PLUMgrid that implement the functionality on software edges in compute nodes.
These are the slides from the webinar "OpenStack networking (Neutron)", which covered the topics:
- OpenStack Networking: the Neutron project (NaaS);
- Main features of Neutron;
- Advanced networking functionalities in OpenStack.
This document provides an overview of OpenStack Neutron, the networking component of OpenStack. It describes Neutron's architecture and components, how it uses Linux networking and Open vSwitch, and how network packets flow through the Neutron distributed virtual router architecture. Key concepts covered include Neutron plugins, agents, GRE tunnels, Linux network namespaces, and east-west vs north-south traffic flows in a DVR configuration.
OpenStack Neutron Advanced Services by AkandaSean Roberts
Sean Roberts, VP Development Akanda, gave this talk on 03 September 2015 at the HP Sunnyvale offices. This talk goes into detail of how Akanda delivers OpenStack Neutron Advanced Services. Event details can be found here http://www.meetup.com/openstack/events/215648162/
Scaling OpenStack Neutron in Heterogeneous EnvironmentsMartin Klein
Scaling an Openstack deployment requires serious thought and consideration, commonly it is achieved by multiplying the constrained resource. A notable exception is Neutron, in particular the L2 subsystem. The L2 network needs to scale up while most connected components are scaling out. A common approach to scaling the number of available L2 network segments in a region is the introduction of advanced overlay networks, with the drawback that all connected devices need to implement the overlay protocol. Installations requiring multiple hypervisor types or bare metal have a limited number of overlay protocol options.
Neutron provides an alternative to a single overlay protocol; separating L2 in the network fabric from the protocol used on the network edge via Hierarchical Port Binding.
This talk introduces a Neutron HPB architecture and ML2 implementation currently in use at SAP. We will discuss the issues that HPB solved and the challenges faced during our HPB deployment.
This document provides an overview of several open source backend alternatives for OpenStack Neutron, including OpenDaylight, Ryu Network OS, and Open Contrail. It summarizes Neutron's built-in solution using ML2 and OVS agents, and how each open source alternative integrates with Neutron. Setup instructions are provided to try each alternative using Devstack.
ONUG Tutorial: Bridges and Tunnels Drive Through OpenStack Networkingmarkmcclain
This document summarizes OpenStack networking (Neutron) and discusses its key components and architecture. It describes how Neutron provides network abstraction and virtualization through pluggable backend drivers. It also outlines some common Neutron features like security groups and highlights new capabilities in the Juno release like IPv6 support and distributed virtual routing. The document concludes by looking ahead to further networking developments in OpenStack.
This document discusses OpenStack Neutron and software defined networking. It provides an overview of Neutron and how it allows network as a service capabilities. It describes the packet flow for virtual machines accessing the external network or communicating between virtual machines on the same network. It explains how Neutron integrates with Open vSwitch on the compute nodes to provide networking and discusses the various Neutron agents.
2014 OpenStack Summit - Neutron OVS to LinuxBridge MigrationJames Denton
Presentation titled 'Migrating production workloads from OVS to LinuxBridge'. Presented at the Fall 2014 OpenStack summit in Paris, this slide deck introduced the possibility of migrating live workloads from Open vSwitch to LinuxBridge with minimal downtime.
OVN: Scaleable Virtual Networking for Open vSwitchmestery
OVN is a network virtualization architecture that allows for scalable virtual networking on Open vSwitch. It abstracts virtual networking from physical networking and provides the same features as physical networks. OVN uses distributed logical flows and databases coordinated by local controllers to convert logical flows to physical flows. This allows for high performance, scalable virtual networking without depending on the physical topology.
- OpenStack provides network virtualization and automation capabilities through projects like Neutron, Heat, and plugins like Midonet.
- Neutron evolved networking in OpenStack to allow pluggable networking models beyond the initial Nova networking. It supports overlay technologies and network automation.
- Heat allows you to define infrastructure like servers, networks, and their relationships in templates that can be deployed through the OpenStack API. This provides automation of virtual network deployment.
- Plugins like Midonet provide distributed virtual networking models to improve scalability and performance over overlay approaches like OVS. They also allow automation of physical network configuration.
This document provides an overview and agenda for a presentation on OpenStack networking. It begins with an overview of OpenStack architecture and services like Compute, Networking, Identity and Image services. It then discusses basic network components like controllers, compute nodes and networking plugins. Next, it covers networking process flows and dives deeper into the Neutron networking plugin, including the Modular Layer 2 plugin framework and drivers like Open vSwitch. It concludes with a planned demonstration of networking functionality in an OpenStack lab environment.
In this session we will illustrate the work done during Kilo to improve the Neutron L2 and the L3 agents. We will start with a deep dive into both agents, explaining how they work. We will then give an overview of their deficiencies before Kilo and we will show how we tackled and solved them. We will describe future enhancements and performance gains that will be possible in future releases because of this debt repayment. We will also provide benchmark data to measure the improvement in terms of performance and scalability where applicable.
The document provides details about an OpenStack API development workshop conducted by Liang Bo. The 2-day workshop covers topics like developing with OpenStack, developer tools, OpenStack APIs, SDKs and includes hands-on sessions to build a tiny project using OpenStack APIs. Day 1 covers introduction, developing with OpenStack, tools and OpenStack RESTful APIs. Day 2 focuses on workshops to use OpenStack APIs and SDKs.
- What is NOVA ?
- NOVA architecture
- How instance are spawned in Openstack ?
- Interaction of nova with other openstack projects like neutron, glance and cinder.
This document provides an overview of OpenStack APIs and the WSGI (Web Server Gateway Interface) that powers them. It begins with an introduction to WSGI and how OpenStack services are implemented as WSGI applications. It then demonstrates how the OpenStack APIs can be accessed via libraries like novaclient or directly with HTTP requests. Code examples are provided showing how to authenticate against Keystone and retrieve images using urllib2. The document concludes with explanations of how WSGI, WebOb, and Paste are used to implement the OpenStack "web stack".
CloudConnect 云计算大会 China 2016
OpenStack Swift的性能调优
Performance Tuning of OpenStack Swift
李明宇 奥思数据 创始⼈& CTO
Email: li.mingyu@ostorage.com.cn
Swift is good at storing small objects like photos and documents.
OpenStack APIs: Present and Future (Beta Talk)Wade Minter
OpenStack APIs: Present and Future by H. Wade Minter provides an overview of OpenStack storage (Swift) APIs and how to use them. The document discusses how OpenStack is an open source cloud computing platform producing interrelated projects for cloud infrastructure. It then summarizes the Swift storage component and demonstrates making API calls to authenticate, list containers and objects, upload/download objects, and set metadata using CURL examples. Language bindings like Ruby gems simplify using the OpenStack Storage APIs.
June Boston openStack Summit: Preparing quantum for the data centerKamesh Pemmaraju
Quantum, OpenStack's virtual networking service, is slated to replace Nova's networking service in the upcoming Folsom release. Initial Quantum development has focused on the basic requirements of a green-field Nova cloud deployment. Additional requirements will be discussed that enable Quantum to support private Nova cloud deployments within existing data centers, as well as enterprise virtualization with the oVirt project. Initial work is underway for Folsom, and additional work will follow.
OpenStack security is a huge topic. In these slides I presented at the OpenStack Day, I analyzed cloud security the network to the application layer, going through specific layers, some in common between OpenStack itself and the applications.
Cloud infrastructure have changed both the way the attacks are made both the methodologies for its protection. In this workshop gave at OpenStack day Italy, Giuseppe Paternò, CTO at GARL, explores the components of OpenStack security and other measures to protect both the infrastructure itself and the applications hosted
LinuxCon 2013 Steven Dake on Using Heat for autoscaling OpenShift on OpenstackOpenShift Origin
OpenStack Heat allows modeling relationships between OpenStack resources and managing infrastructure resources throughout application lifecycles. The presentation discusses Heat architecture, autoscaling workflows using Heat and Ceilometer, and demonstrates an OpenShift autoscaling workflow on OpenStack using Heat templates, DIB elements, and CloudWatch alarms. Future work may expand autoscaling to other resources and integrate it more fully across OpenStack projects.
You may have heard that Node.js as JavaScript for the server-side and you may be wondering why anyone would want that!. Or maybe you know exactly what Node.js is, but aren’t sure when or why to use it.
This month Coffee@DBG comes up with “Step into the Node JS Express” to answer all your questions on Node.JS. If you are enthusiastic to know more about it and why it’s making waves in the community, join it now before the seats get filled.
Coffee @ DBG is a Rendezvous of open interactive discussions in technology, where enthusiasts from different companies of Technopark have a get-together to discuss and share their knowledge over a cup of Coffee at DBG.
Coffee@DBG has been the most popular tech event in Technopark happening every month on first Wednesdays which will also provide a platform for programmers to get free consultation on problems they are facing in real work.
First ever talk about Node.JS in Kerala by its early adopters.
Service Function Chaining in Openstack NeutronMichelle Holley
Service Function Chaining (SFC) uses software-defined networking (SDN) capabilities to create a service chain of connected network services (such as L4-7 like firewalls,
network address translation [NAT], intrusion protection) and connect them in a virtual chain. This capability can be used by network operators to set up suites or catalogs
of connected services that enable the use of a single network connection for many services, with different characteristics.
networking-sfc is a service plugin of Openstack neutron. The talk will go over the architecture, implementation, use-cases and latest enhancements to networking-sfc (the APIs and implementation to support service function chaining in neutron).
About the speaker: Farhad Sunavala is currently a principal architect/engineer working on Network Virtualization, Cloud service, and SDN technologies at Huawei Technology USA. He has led several wireless projects in Huawei including virtual EPC, service function chaining, etc. Prior to Huawei, he worked 17 years at Cisco. Farhad received his MS in Electrical and Computer Engineering from University of New Hampshire. His expertise includes L2/L3/L4 networking, Network Virtualization, SDN, Cloud Computing, and
mobile wireless networks. He holds several patents in platforms, virtualization, wireless, service-chaining and cloud computing. Farhad was a core member of networking-sfc.
The document provides an overview and cheat sheet for using the OpenShift command line interface. It defines what OpenShift is, lists common commands for login/authentication, managing projects and resources, building and deploying applications, and provides an example of creating a new project, adding users, building an application from source code and image, and checking the status of deployed resources.
Practical Chaos Engineering will show how to start running chaos experiments in your infrastructure and will try to guide your through the principles of chaos.
Elasticsearch is an open source search and analytics engine that is distributed, horizontally scalable, reliable, and easy to manage. The document discusses how to install and interact with Elasticsearch using various Java clients and frameworks. It covers using the standard Java client directly, the Jest HTTP client, and Spring Data Elasticsearch which provides abstractions and dynamic repositories.
This document provides an overview of several security tools including Nikto, Burp Suite, Wikto, Nmap, Metasploit, Nessus, OpenVAS, and how some of them relate to and integrate with Nikto. It describes Nikto as a web server scanner that checks for vulnerabilities. It then briefly introduces each of the other tools, their purpose, and in some cases how they can work with Nikto, such as Nikto being able to use Nmap scan results or output results to Metasploit's database.
Anwendungsfälle für Elasticsearch JAX 2015Florian Hopf
The document discusses various use cases for Elasticsearch including document storage, full text search, geo search, log file analysis, and analytics. It provides examples of installing Elasticsearch, indexing and retrieving documents, performing searches using query DSL, filtering and sorting results, and aggregating data. Popular users mentioned include GitHub, Stack Overflow, and Microsoft. The presentation aims to demonstrate the flexibility and power of Elasticsearch beyond just full text search.
Presentation of Ceilometer (OpenStack Telemetry) new features in OpenStack Havana and a look at the features coming in IceHouse. Joint presentation done with Julien Danjou at the OpenStack In Action 4 (Dec 5th 2013)
Slides from our talk “REST in Peace” for DrupalCamp Baltics 2015: http://drupalcampbaltics.com/event/rest-peace
Speakers:
- Kate Marshalkina
- Konstantin Komelin
Speech transcript is available here: http://komelin.com/en/articles/rest-peace-api-development-drupal
FIWARE Wednesday Webinars - Short Term History within Smart SystemsFIWARE
FIWARE Wednesday Webinar - Short Term History within Smart Systems (2nd April 2020)
Corresponding webinar recording: https://youtu.be/fX_YAc7G4Dk
This webinar will show how to utilise times series components and monitor and display trends within FIWARE applications.
Chapter: Core Context
Difficulty: 3
Audience: Any Technical
Presenter: Jason Fox (Senior Technical Evangelist, FIWARE Foundation)
Similar to OpenStack Neutron new developers on boarding (20)
Transform Your Communication with Cloud-Based IVR SolutionsTheSMSPoint
Discover the power of Cloud-Based IVR Solutions to streamline communication processes. Embrace scalability and cost-efficiency while enhancing customer experiences with features like automated call routing and voice recognition. Accessible from anywhere, these solutions integrate seamlessly with existing systems, providing real-time analytics for continuous improvement. Revolutionize your communication strategy today with Cloud-Based IVR Solutions. Learn more at: https://thesmspoint.com/channel/cloud-telephony
Neo4j - Product Vision and Knowledge Graphs - GraphSummit ParisNeo4j
Dr. Jesús Barrasa, Head of Solutions Architecture for EMEA, Neo4j
Découvrez les dernières innovations de Neo4j, et notamment les dernières intégrations cloud et les améliorations produits qui font de Neo4j un choix essentiel pour les développeurs qui créent des applications avec des données interconnectées et de l’IA générative.
OpenMetadata Community Meeting - 5th June 2024OpenMetadata
The OpenMetadata Community Meeting was held on June 5th, 2024. In this meeting, we discussed about the data quality capabilities that are integrated with the Incident Manager, providing a complete solution to handle your data observability needs. Watch the end-to-end demo of the data quality features.
* How to run your own data quality framework
* What is the performance impact of running data quality frameworks
* How to run the test cases in your own ETL pipelines
* How the Incident Manager is integrated
* Get notified with alerts when test cases fail
Watch the meeting recording here - https://www.youtube.com/watch?v=UbNOje0kf6E
Zoom is a comprehensive platform designed to connect individuals and teams efficiently. With its user-friendly interface and powerful features, Zoom has become a go-to solution for virtual communication and collaboration. It offers a range of tools, including virtual meetings, team chat, VoIP phone systems, online whiteboards, and AI companions, to streamline workflows and enhance productivity.
Flutter is a popular open source, cross-platform framework developed by Google. In this webinar we'll explore Flutter and its architecture, delve into the Flutter Embedder and Flutter’s Dart language, discover how to leverage Flutter for embedded device development, learn about Automotive Grade Linux (AGL) and its consortium and understand the rationale behind AGL's choice of Flutter for next-gen IVI systems. Don’t miss this opportunity to discover whether Flutter is right for your project.
Essentials of Automations: The Art of Triggers and Actions in FMESafe Software
In this second installment of our Essentials of Automations webinar series, we’ll explore the landscape of triggers and actions, guiding you through the nuances of authoring and adapting workspaces for seamless automations. Gain an understanding of the full spectrum of triggers and actions available in FME, empowering you to enhance your workspaces for efficient automation.
We’ll kick things off by showcasing the most commonly used event-based triggers, introducing you to various automation workflows like manual triggers, schedules, directory watchers, and more. Plus, see how these elements play out in real scenarios.
Whether you’re tweaking your current setup or building from the ground up, this session will arm you with the tools and insights needed to transform your FME usage into a powerhouse of productivity. Join us to discover effective strategies that simplify complex processes, enhancing your productivity and transforming your data management practices with FME. Let’s turn complexity into clarity and make your workspaces work wonders!
WhatsApp offers simple, reliable, and private messaging and calling services for free worldwide. With end-to-end encryption, your personal messages and calls are secure, ensuring only you and the recipient can access them. Enjoy voice and video calls to stay connected with loved ones or colleagues. Express yourself using stickers, GIFs, or by sharing moments on Status. WhatsApp Business enables global customer outreach, facilitating sales growth and relationship building through showcasing products and services. Stay connected effortlessly with group chats for planning outings with friends or staying updated on family conversations.
Introducing Crescat - Event Management Software for Venues, Festivals and Eve...Crescat
Crescat is industry-trusted event management software, built by event professionals for event professionals. Founded in 2017, we have three key products tailored for the live event industry.
Crescat Event for concert promoters and event agencies. Crescat Venue for music venues, conference centers, wedding venues, concert halls and more. And Crescat Festival for festivals, conferences and complex events.
With a wide range of popular features such as event scheduling, shift management, volunteer and crew coordination, artist booking and much more, Crescat is designed for customisation and ease-of-use.
Over 125,000 events have been planned in Crescat and with hundreds of customers of all shapes and sizes, from boutique event agencies through to international concert promoters, Crescat is rigged for success. What's more, we highly value feedback from our users and we are constantly improving our software with updates, new features and improvements.
If you plan events, run a venue or produce festivals and you're looking for ways to make your life easier, then we have a solution for you. Try our software for free or schedule a no-obligation demo with one of our product specialists today at crescat.io
SMS API Integration in Saudi Arabia| Best SMS API ServiceYara Milbes
Discover the benefits and implementation of SMS API integration in the UAE and Middle East. This comprehensive guide covers the importance of SMS messaging APIs, the advantages of bulk SMS APIs, and real-world case studies. Learn how CEQUENS, a leader in communication solutions, can help your business enhance customer engagement and streamline operations with innovative CPaaS, reliable SMS APIs, and omnichannel solutions, including WhatsApp Business. Perfect for businesses seeking to optimize their communication strategies in the digital age.
What is Master Data Management by PiLog Groupaymanquadri279
PiLog Group's Master Data Record Manager (MDRM) is a sophisticated enterprise solution designed to ensure data accuracy, consistency, and governance across various business functions. MDRM integrates advanced data management technologies to cleanse, classify, and standardize master data, thereby enhancing data quality and operational efficiency.
8 Best Automated Android App Testing Tool and Framework in 2024.pdfkalichargn70th171
Regarding mobile operating systems, two major players dominate our thoughts: Android and iPhone. With Android leading the market, software development companies are focused on delivering apps compatible with this OS. Ensuring an app's functionality across various Android devices, OS versions, and hardware specifications is critical, making Android app testing essential.
GraphSummit Paris - The art of the possible with Graph TechnologyNeo4j
Sudhir Hasbe, Chief Product Officer, Neo4j
Join us as we explore breakthrough innovations enabled by interconnected data and AI. Discover firsthand how organizations use relationships in data to uncover contextual insights and solve our most pressing challenges – from optimizing supply chains, detecting fraud, and improving customer experiences to accelerating drug discoveries.
Measures in SQL (SIGMOD 2024, Santiago, Chile)Julian Hyde
SQL has attained widespread adoption, but Business Intelligence tools still use their own higher level languages based upon a multidimensional paradigm. Composable calculations are what is missing from SQL, and we propose a new kind of column, called a measure, that attaches a calculation to a table. Like regular tables, tables with measures are composable and closed when used in queries.
SQL-with-measures has the power, conciseness and reusability of multidimensional languages but retains SQL semantics. Measure invocations can be expanded in place to simple, clear SQL.
To define the evaluation semantics for measures, we introduce context-sensitive expressions (a way to evaluate multidimensional expressions that is consistent with existing SQL semantics), a concept called evaluation context, and several operations for setting and modifying the evaluation context.
A talk at SIGMOD, June 9–15, 2024, Santiago, Chile
Authors: Julian Hyde (Google) and John Fremlin (Google)
https://doi.org/10.1145/3626246.3653374
Using Query Store in Azure PostgreSQL to Understand Query PerformanceGrant Fritchey
Microsoft has added an excellent new extension in PostgreSQL on their Azure Platform. This session, presented at Posette 2024, covers what Query Store is and the types of information you can get out of it.
Graspan: A Big Data System for Big Code AnalysisAftab Hussain
We built a disk-based parallel graph system, Graspan, that uses a novel edge-pair centric computation model to compute dynamic transitive closures on very large program graphs.
We implement context-sensitive pointer/alias and dataflow analyses on Graspan. An evaluation of these analyses on large codebases such as Linux shows that their Graspan implementations scale to millions of lines of code and are much simpler than their original implementations.
These analyses were used to augment the existing checkers; these augmented checkers found 132 new NULL pointer bugs and 1308 unnecessary NULL tests in Linux 4.4.0-rc5, PostgreSQL 8.3.9, and Apache httpd 2.2.18.
- Accepted in ASPLOS ‘17, Xi’an, China.
- Featured in the tutorial, Systemized Program Analyses: A Big Data Perspective on Static Analysis Scalability, ASPLOS ‘17.
- Invited for presentation at SoCal PLS ‘16.
- Invited for poster presentation at PLDI SRC ‘16.
SOCRadar's Aviation Industry Q1 Incident Report is out now!
The aviation industry has always been a prime target for cybercriminals due to its critical infrastructure and high stakes. In the first quarter of 2024, the sector faced an alarming surge in cybersecurity threats, revealing its vulnerabilities and the relentless sophistication of cyber attackers.
SOCRadar’s Aviation Industry, Quarterly Incident Report, provides an in-depth analysis of these threats, detected and examined through our extensive monitoring of hacker forums, Telegram channels, and dark web platforms.
E-commerce Development Services- Hornet DynamicsHornet Dynamics
For any business hoping to succeed in the digital age, having a strong online presence is crucial. We offer Ecommerce Development Services that are customized according to your business requirements and client preferences, enabling you to create a dynamic, safe, and user-friendly online store.
4. Neutron Stadium
● Mission, as defined by the OpenStack governance document
“To implement services and associated libraries to provide
on-demand, scalable, and technology-agnostic network
abstraction.”
● This mission is big and ambitious. To properly tackle it, the Neutron Stadium is
defined as (https://docs.openstack.org/developer/neutron/stadium/index.html):
“… projects that the Neutron PTL and core team are directly
involved in, and manage on a day to day basis.”
6. Neutron Stadium
● Projects have to demonstrate a track record meeting a well defined criteria to
be part of the Stadium
○ Exhaustive documentation
○ Exhaustive OpenStack CI coverage
○ Good release model adherence
○ Adherence to deprecation and stable backport policies
○ Demonstrated ability to do upgrades and rolling upgrades, where applicable
○ Client bindings and CLI developed according to the OpenStack Client plugin model
○ Integrate with Neutron via one of the supported, advertised and maintained public Python APIs
○ Above all: be open source from the ground up
● To be considered to join the Stadium, a project must prove compliance with
the above criteria for at least two OpenStack releases
7. Neutron team
● Current PTL: Kevin Benton (IRC: kevinbenton)
● Liaison with on-boarding process: Miguel Lavalle (IRC: mlavalle)
● IRC channel: #openstack-neutron in Freenode
● Weekly Neutron IRC meeting:
○ Convenes on alternating weeks on Mondays at 2100 UTC and on Tuesdays at 1400 UTC
● Subteams (L3, QoS, CI, etc) meet also regularly
○ See scheduled times and days here: http://eavesdrop.openstack.org/
● Neutron has a good developer reference documentation. Please use it!:
○ https://docs.openstack.org/developer/neutron/index.html
9. Agenda
● Neutron project overview
● Neutron API
● Core resources, extensions, plugins and service plugins
● Reference back-end implementation
● ML2 plug-in
10. Neutron API
Neutron, like all the other OpenStack projects, exposes a ReST API where:
● Requests and responses are sent using HTTP
● HTTP methods (POST, PUT, GET, DELETE) are applied through requests
sent to the API...
● ...to a set of resources represented by URIs (Universal Resource Identifier)
that identify resources
● The HTTP verbs correspond to CRUD (Create, Read, Update and Delete)
operations.
● Every request sent by the user gets a response from the API
● Resources are represented in API requests and responses in JSON
11. Exercise: create a neutron port
$ openstack --debug port create --network private port-1
21. Exercise: update a port
$ openstack --debug port set --name updated-port-name
55fc71a4-eabb-43f9-8335-bdbd1b62599f
22. Exercise: update a port request
$ openstack --debug port set --name updated-port-name
55fc71a4-eabb-43f9-8335-bdbd1b62599f
REQ: curl -g -i -X PUT
http://192.168.33.12:9696/v2.0/ports/55fc71a4-eabb-43f9-8335-bdbd1b62599f -H
"User-Agent: openstacksdk/0.9.14 keystoneauth1/2.19.0 python-requests/2.12.5
CPython/2.7.12" -H "Content-Type: application/json" -H "X-Auth-Token:
{SHA1}2b22d5669c22b8ccda3c70f98a1c3d5f6b119412" -d '{"port": {"name":
"updated-port-name"}}'
RESP: [200] Content-Type: application/json Content-Length: 1140
X-Openstack-Request-Id: req-639af99a-9ba7-4082-bc5c-b75938200a29….
HTTP method
23. Exercise: update a port request
$ openstack --debug port set --name updated-port-name
55fc71a4-eabb-43f9-8335-bdbd1b62599f
REQ: curl -g -i -X PUT
http://192.168.33.12:9696/v2.0/ports/55fc71a4-eabb-43f9-8335-bdbd1b62599f -H
"User-Agent: openstacksdk/0.9.14 keystoneauth1/2.19.0 python-requests/2.12.5
CPython/2.7.12" -H "Content-Type: application/json" -H "X-Auth-Token:
{SHA1}2b22d5669c22b8ccda3c70f98a1c3d5f6b119412" -d '{"port": {"name":
"updated-port-name"}}'
RESP: [200] Content-Type: application/json Content-Length: 1140
X-Openstack-Request-Id: req-639af99a-9ba7-4082-bc5c-b75938200a29….
URI
24. Exercise: update a port request
$ openstack --debug port set --name updated-port-name
55fc71a4-eabb-43f9-8335-bdbd1b62599f
REQ: curl -g -i -X PUT
http://192.168.33.12:9696/v2.0/ports/55fc71a4-eabb-43f9-8335-bdbd1b62599f -H
"User-Agent: openstacksdk/0.9.14 keystoneauth1/2.19.0 python-requests/2.12.5
CPython/2.7.12" -H "Content-Type: application/json" -H "X-Auth-Token:
{SHA1}2b22d5669c22b8ccda3c70f98a1c3d5f6b119412" -d '{"port": {"name":
"updated-port-name"}}'
RESP: [200] Content-Type: application/json Content-Length: 1140
X-Openstack-Request-Id: req-639af99a-9ba7-4082-bc5c-b75938200a29….
Resource representation in JSON
25. Frequently seen response codes
Response code webob.exc exception Meaning
Success
200 HTTPOk OK
201 HTTPCreated Created
204 HTTPNoContent No Content (deleted)
Client error
400 HTTPBadRequest Bad Request
404 HTTPNotFound Not Found
409 HTTPConflict Conflict
Server error
500 HTTPServerError Internal Server Error
26. Agenda
● Neutron project overview
● Neutron API
● Core resources, extensions, plugins and service plugins
● Reference back-end implementation
● ML2 plug-in
28. Neutron plugin architecture
Nova ComputeNova Compute
Nova Compute
Nova Compute
Tenant
Scripts
Horizon
Nova
API Clients Neutron Server
Neutron
Plugin
Create-net
.
.
.
Create-port
virtual switch
Neutron
API
Create-net
.
.
.
Create-port Interfaces from a service
like Nova plug into a
switch managed by the
Neutron plugin
Uniform API
for all clients
DB
Agents or
SDN controller
API + Plugin = Neutron Server
30. Extensions
● Add new resources and sub-resources
Neutron L3 Router /v2.0/routers
/v2.0/floatingips
security-group /v2.0/security-groups
/v2.0/security-group-rules
Quality of Service /v2.0/qos/policies
/v2.0/qos/policies/{policy_id}/bandwidth_limit_rules
/v2.0/qos/policies/{policy_id}/dscp_marking_rules
/v2.0/qos/policies/{policy_id}/minimum_bandwidth_rules
31. Neutron with API extensions and service plugin
Nova ComputeNova Compute
Nova Compute
Nova Compute
Tenant
Scripts
Horizon
Nova
API Clients Neutron Server
Neutron
Plugin
Create-net
.
Create-port
virtual switch
Neutron
API
Create-net
.
Create-port
Interfaces from a service
like Nova plug into a
switch managed by the
Neutron plugin
API + Plugin = Neutron Server
Uniform API
for all clients
API
Extensions
Service
Plugin DB
Agents or
SDN controller
32. Exercise
● $ openstack extension list --network
● Open /etc/neutron/neutron.conf
○ Search for core_plugin
○ Search for service_plugins
33. Exercise
● Enable the DNS integration extension:
○ $ openstack port list
○ $ openstack port show <port-id>
○ Edit the /etc/neutron/neutron.conf file and assign a value different to openstacklocal (its default
value) to the dns_domain parameter in the [default] section
○ Add dns to extension_drivers in the [ml2] section of /etc/neutron/plugins/ml2/ml2_conf.ini
○ $ screen -r stack
○ <ctrl-a>“
○ With the <down-arrow> or <up-arrow> select screen q-svc and press enter
○ <ctrl-c> to stop the Neutron server
○ <up-arrow> once to recall the startup command
○ <enter> to restart the Neutron server
○ <ctrl-a>d to leave the screen command
○ $ openstack port show <port-id>
34. Exercise
● Enable the DNS integration extension:
○ sudo systemctl restart devstack@q-svc.service
35. Agenda
● Neutron project overview
● Neutron API
● Core resources, extensions, plugins and service plugins
● Reference back-end implementation
● ML2 plug-in
36. The back end
Nova ComputeNova Compute
Nova Compute
Nova Compute
Tenant
Scripts
Horizon
Nova
API Clients Neutron Server
Neutron
Plugin
Create-net
.
Create-port
virtual switch
Neutron
API
Create-net
.
Create-port
Interfaces from a service
like Nova plug into a
switch managed by the
Neutron plugin
Uniform API
for all clients
Agents or
SDN controller
API
Extensions
Service
Plugin DB
API + Plugin = Neutron Server
37. The back end
Nova ComputeNova Compute
Nova Compute
Nova Compute
Tenant
Scripts
Horizon
Nova
API Clients Neutron Server
Neutron
Plugin
Create-net
.
Create-port
virtual switch
Neutron
API
Create-net
.
Create-port
Interfaces from a service
like Nova plug into a
switch managed by the
Neutron plugin
Uniform API
for all clients
Agents or
SDN controller
API
Extensions
Service
Plugin DB
API + Plugin = Neutron Server
38. Agents based reference implementation
Agents and server communicate using
RPC implemented over message queue
42. OVS L2 agent: loop events (method rpc_loop)
● OVSDB monitor has updates
● Neutron server messages
○ Security group change
○ Port update
● OVS re-started
43. OVS L2 agent: detect port changes
● OVSDB signals if something has changed in the host
● Agent scans all the ports in the host
● Agent keeps track of the ports it has already processed using a set named
ports
● The difference between ports and the result of the scanning enables the
agent to infer the devices added and deleted
44. OVS L2 agent: process port added
● Request the device details (get_devices_details_and_failed_devices)
● Provision local vlan and install proper flows
● Set up filters
● Call plugin’s update_device_up (update_device_list)
45. Exercise: OVS L2 agent
● Review OVS L2 related code
○ Agent side of the RPC API: /opt/stack/neutron/agent/rpc.py
○ Neutron server side of the RPC API: neutron/plugins/ml2/rpc.py
○ Method rpc_loop in agent:
neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py
● Boot an instance and locate OVS and Linux bridge bridges and interfaces
○ $ openstack image list
○ $ openstack server create --flavor 42 --image <image-id> --nic net-id=<private-net-id> test-vm
○ $ openstack server list
○ $ openstack port list
○ $ sudo ovs-vsctl show
○ $ sudo brctl show
51. Exercise: L3 agent
● Identify the name spaces:
○ $ openstack router list
○ $ openstack network list
○ $ sudo ip netns
○ $ sudo ip netns exec qrouter-<router-id> ip addr list
● Identify router and dhcp ports in OVS:
○ $ openstack port list
○ $ sudo ovs-vsctl show
● Identify iptables entries
○ $ sudo ip netns exec qrouter-<router-id> iptables-save | grep 172
○ $ openstack network list
○ $ openstack floating ip create <external-net-id> --port <instance-port-id>
○ $ sudo ip netns exec qrouter-<router-id> iptables-save | grep 172
○ $ sudo ip netns exec qrouter-<router-id> ip addr list
52. Agenda
● Neutron project overview
● Neutron API
● Core resources, extensions, plugins and service plugins
● Reference back-end implementation
● ML2 plug-in
53. ML2 plug-in architecture
Neutron Server
ML2 Plugin
Type Manager Mechanism Manager
Extension Manager
GRE
TypeDriver
Arista
VLAN
TypeDriver
VXLAN
TypeDriver
Cisco
Nexus
mech_sriov
L2
Population
Linuxbridge
Open
vSwitch
macvtap
54. Multi-segment networks
VXLAN 123567
physnet1 VLAN 37 physnet2 VLAN 413
VM 1 VM 2 VM 3
● Created via multi-provider API extension
● Segments bridged administratively
● Ports associated with network, not specific segment
● Ports bound automatically to segment with connectivity
57. ML2 plug-in create_network method pseudo-code
def create_network(self, context, network):
with db_api.context_manager.writer.using(context):
result = self.create_network_db(context, network)
self.type_manager.create_network_segments(context, network)
mech_context = driver_context.NetworkContext(self, context, result)
self.mechanism_manager.create_network_precommit(mech_context)
self.mechanism_manager.create_network_postcommit(mech_context)
return self._make_network_dict(result)
Part 1:
Start a DB transaction
58. ML2 plug-in create_network method pseudo-code
def create_network(self, context, network):
with db_api.context_manager.writer.using(context):
result = self.create_network_db(context, network)
self.type_manager.create_network_segments(context, network)
mech_context = driver_context.NetworkContext(self, context, result)
self.mechanism_manager.create_network_precommit(mech_context)
self.mechanism_manager.create_network_postcommit(mech_context)
return self._make_network_dict(result)
Part 2:
Code that needs to be
executed inside DB
transaction. It has to be fast
fast, with no blocking calls!
59. ML2 plug-in create_network method pseudo-code
def create_network(self, context, network):
with db_api.context_manager.writer.using(context):
result = self.create_network_db(context, network)
self.type_manager.create_network_segments(context, network)
mech_context = driver_context.NetworkContext(self, context, result)
self.mechanism_manager.create_network_precommit(mech_context)
self.mechanism_manager.create_network_postcommit(mech_context)
return self._make_network_dict(result)
Part 3:
Set up the networking
infrastructure. Since this code
is outside the DB transaction,
the mechanism manager
post_commit can interact with
networking infrastructure. It
can execute blocking calls
60. ML2 plug-in create_network method pseudo-code
def create_network(self, context, network):
with db_api.context_manager.writer.using(context):
result = self.create_network_db(context, network)
self.type_manager.create_network_segments(context, network)
mech_context = driver_context.NetworkContext(self, context, result)
self.mechanism_manager.create_network_precommit(mech_context)
self.mechanism_manager.create_network_postcommit(mech_context)
return self._make_network_dict(result)
Part 4
Build the resource (network in this
example) dictionary that will be
returned to the user through the
ReST API. It has to be structured
properly to avoid generating
additional queries to the DB when
adding extensions attributes!
61. ML2 plug-in create_network: inside DB transaction
def create_network(self, context, network):
with db_api.context_manager.writer.using(context):
result = self.create_network_db(context, network)
self.type_manager.create_network_segments(context, network)
mech_context = driver_context.NetworkContext(self, context, result)
self.mechanism_manager.create_network_precommit(mech_context)
self.mechanism_manager.create_network_postcommit(mech_context)
return self._make_network_dict(result)
62. ML2 plug-in create_network: inside DB transaction
def create_network(self, context, network):
with db_api.context_manager.writer.using(context):
result = self.create_network_db(context, network)
self.type_manager.create_network_segments(context, network)
mech_context = driver_context.NetworkContext(self, context, result)
self.mechanism_manager.create_network_precommit(mech_context)
self.mechanism_manager.create_network_postcommit(mech_context)
return self._make_network_dict(result)
Call the DB plug-in to create
the row in the networks table.
It can be called directly like
here, or as super, since the
ML2 plugin inherits from
NeutronDbPluginV2
63. ML2 plug-in create_network: inside DB transaction
def create_network(self, context, network):
with db_api.context_manager.writer.using(context):
result = self.create_network_db(context, network)
self.type_manager.create_network_segments(context, network)
mech_context = driver_context.NetworkContext(self, context, result)
self.mechanism_manager.create_network_precommit(mech_context)
self.mechanism_manager.create_network_postcommit(mech_context)
return self._make_network_dict(result)
Call the type driver
(through the type
manager) to reserve the
segments
64. ML2 plug-in create_network: inside DB transaction
def create_network(self, context, network):
with db_api.context_manager.writer.using(context):
result = self.create_network_db(context, network)
self.type_manager.create_network_segments(context, network)
mech_context = driver_context.NetworkContext(self, context, result)
self.mechanism_manager.create_network_precommit(mech_context)
self.mechanism_manager.create_network_postcommit(mech_context)
return self._make_network_dict(result)
Create the mechanism
context, that stores the
previous and the current
state of the resource. It is
passed to the mechanism
driver precommit and
postcommit
65. ML2 plug-in create_network: inside DB transaction
def create_network(self, context, network):
with db_api.context_manager.writer.using(context):
result = self.create_network_db(context, network)
self.type_manager.create_network_segments(context, network)
mech_context = driver_context.NetworkContext(self, context, result)
self.mechanism_manager.create_network_precommit(mech_context)
self.mechanism_manager.create_network_postcommit(mech_context)
return self._make_network_dict(result)
Call the mechanism driver
precommit to store in the
DB any state that needs to
be remembered
67. Port binding as a black box
Port binding
Port attributes:
● binding:host_id
● binding:profile
● binding:vnic_type
● Other attributes
Port network segments,
each containing:
● network_type
● physical_network
● segmentation_id
Port attributes:
● binding:vif_type
● binding:vif_details
Port binding levels, each
containing:
● driver
● segment
68. Port binding
● Plug-in calls bind_port() on registered
mechanism drivers in order listed in config,
until one succeeds or all have been tried
● Driver determines if it can bind based on
○ context.network.network_segments
○ context.host
○ context.host_agents()
● Binding requires live L2 agent on port’s host
that:
○ Supports a network type of a segment of the
port’s network
○ Has a mapping for that segment’s
physical_network if applicable
● If bind possible, driver calls context.set_binding().
Otherwise, port’s binding:vif_type set to
VIF_TYPE_BINDING_FAILED
def PortContext(object):
@abstractproperty
def current(self):
pass
@abstractproperty
def network(self):
pass
@abstractmethod
def set_binding(self, segment_id, vif_type,
vif_details, status):
pass
69. Port postcommit and binding in little a more detail
try:
self.mechanism_manager.create_port_postcommit(mech_context)
except ml2_exc.MechanismDriverError:
with excutils.save_and_reraise_exception():
LOG.error(_LE("mechanism_manager.create_port_postcommit "
"failed, deleting port '%s'"), result['id'])
self.delete_port(context, result['id'], l3_port_check=False)
try:
bound_context = self._bind_port_if_needed(mech_context)
except ml2_exc.MechanismDriverError:
with excutils.save_and_reraise_exception():
LOG.error(_LE("_bind_port_if_needed "
"failed, deleting port '%s'"), result['id'])
self.delete_port(context, result['id'], l3_port_check=False)
71. Exercise: ML2 plugin
● ML2 related code:
○ Drivers and context API definitions: neutron/plugins/ml2/driver_api.py
○ Network, subnet and port contexts: neutron/plugins/ml2/driver_context.py
○ Drivers: neutron/plugins/ml2/drivers
○ Drivers managers: neutron/plugins/ml2/managers.py
○ Create port in ML2 plugin: neutron/plugins/ml2/plugin.com
● Port binding related code:
○ get_devices_details_list_and_failed_devices in class RpcCallbacks in
neutron/plugins/ml2.rpc.py
○ get_bound_port_context in ML2 plugin
■ Add a LOG.debug statement before returning the port context. Log the resulting binding
vif_type
■ Re-start the server
■ Create a VM