Hi Shiva, I send to you my report. Please try build it. Thanks
2013/7/27 Shiva Teja <shivate...@gmail.com> > Oops, > > *paste it somewhere > > > On Sat, Jul 27, 2013 at 10:06 PM, Shiva Teja <shivate...@gmail.com> wrote: > > > Hi, > > > > Can you send the paste it somewhere and give a link? I can try. > > > > > > On Sat, Jul 27, 2013 at 9:46 PM, Nguyen Anh Tu <ng.t...@gmail.com> > wrote: > > > >> Hi guys, > >> > >> I build my GSoC mid-term review and get an error here: > >> > >> Validation failed: > >> CloudStack_GSoC_Guide.xml:67: validity error : Element itemizedlist > >> content > >> does not follow the DTD, expecting (blockinfo? , (title , > titleabbrev?)? , > >> (caution | important | note | tip | warning | literallayout | > >> programlisting | programlistingco | screen | screenco | screenshot | > >> synopsis | cmdsynopsis | funcsynopsis | classsynopsis | fieldsynopsis | > >> constructorsynopsis | destructorsynopsis | methodsynopsis | formalpara | > >> para | simpara | address | blockquote | graphic | graphicco | > mediaobject > >> | > >> mediaobjectco | informalequation | informalexample | informalfigure | > >> informaltable | anchor | bridgehead | remark | highlights | abstract | > >> authorblurb | epigraph | indexterm | beginpage)* , listitem+), got > >> (listitem mediaobject listitem mediaobject ) > >> > >> Sound like I use <itemizedlist> in wrong way. But I don't know what > >> exactly > >> causes the error. > >> > >> Urgent. Anyone can help? Thank so much! > >> > >> -- > >> > >> N.g.U.y.e.N.A.n.H.t.U > >> > > > > > -- N.g.U.y.e.N.A.n.H.t.U
<?xml version='1.0' encoding='utf-8' ?> <!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"; [ <!ENTITY % BOOK_ENTITIES SYSTEM "CloudStack_GSoC_Guide.ent"> %BOOK_ENTITIES; ]> <!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> <section id="gsoc-midsummer-nguyen"> <title>Mid-Summer Progress Updates for Nguyen Anh Tu - "Add Xen/XCP support for GRE SDN controller"</title> <para>This section describes my progress with the project titled "Add Xen/XCP support for GRE SDN controller"</para> <section id="Introduction"> <title>Introduction</title> <para>It has been a half way of GSoC2013 journey which I am getting more familiar with its activities. Personally, the previous one-and-a-half month has surprisingly passed by in a blink with lots of pressure. In this first time joining in GSoC2013, I have found it totally new and interesting in its working methods and challenges. Along with those stressful moments, I appreciated all wonderful experiences and knowledge that I have luckily gained from this commitment. It is time to review it all and present in time order. </para> <para>My project named “Add Xen/XCP support for GRE SDN controller”, the proposal can be found here: <ulink url="http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/ngtuna/1";>Proposal</ulink> </para> <para>Specifically, I need to improve the current GRE SDN controller to work with XCP, a free version of XenServer. Then, as things I talked with my two mentor Sebastien Goasguen and Hugo, I continuously work in next missions as below: </para> <itemizedlist> <listitem><para>re-factor GRE source code by following NiciraNVP plugin design.</para></listitem> <listitem><para>add GRE support for KVM hypervisor.</para></listitem> <listitem><para>develop a new ODL plugin using Opendaylight controller for controlling and managing network services via OpenFlow protocol.</para></listitem> </itemizedlist> <para>At the beginning, I started to explore frameworks and tools that CloudStack uses such as Spring framework, marven, git and Reviewboard. In my country developers are more familiar with svn than git, however these tools are also such easy to use so I don't write more about them. I want to note about using Spring in CloudStack and what happen in the Management Server startup process. </para> </section> <section id="Spring"> <title>Spring in CloudStack</title> <para>Spring provides a Container which contains pre-loaded components CloudStack use. At startup, these components are loaded to Container via two ways: </para> <itemizedlist> <listitem><para>components are declared as beans in componentcontext.xml and applicationcontext.xml</para></listitem> <mediaobject> <imageobject> <imagedata fileref="./images/bean.png" /> </imageobject> <textobject><phrase>bean.png: Bean declaration.</phrase></textobject> </mediaobject> <listitem><para>components are marked with @Component annotation</para></listitem> <mediaobject> <imageobject> <imagedata fileref="./images/component.png" /> </imageobject> <textobject><phrase>component.png: Component declaration.</phrase></textobject> </mediaobject> </itemizedlist> <para>As I know recently @Component is not recommended.</para> <para>The fundamental functionality provided by the Spring Container is Dependency Injection (DI). To decouple Java components from other Java components the dependency to a certain other class should get injected into them rather that the class inself creates or finds this object. The general concept between dependency injection is called Inversion of Control. A class should not configure itself but should be configured from outside. A design based on independent classes / components increases the re-usability and possibility to test the software. Example of using DI in CloudStack is showed below:</para> <mediaobject> <imageobject> <imagedata fileref="./images/inject.png" /> </imageobject> <textobject><phrase>inject.png: Injection.</phrase></textobject> </mediaobject> </section> <section id="MsStartup"> <title>Management Server Startup</title> <para>The MS startup process is defined in cloud-client-ui/WEB-INF/web.xml. The following items will be loaded sequentially:</para> <itemizedlist> <listitem><para>Log4jConfigListener.</para></listitem> <listitem><para>ContextLoaderListener.</para></listitem> <listitem><para>CloudStartupServlet.</para></listitem> <listitem><para>ConsoleServlet.</para></listitem> <listitem><para>ApiServlet.</para></listitem> </itemizedlist> <para>In which, CloudStartupServlet will call to ComponentContext to init all of defined components life cycle including configure() and start() phase. The components will be loaded sequentially corresponding to seven levels.</para> <mediaobject> <imageobject> <imagedata fileref="./images/level.png" /> </imageobject> <imageobject> <imagedata fileref="./images/configure_phase.png" /> </imageobject> <textobject><phrase>configure_phase.png: Configure phase.</phrase></textobject> <imageobject> <imagedata fileref="./images/starting_phase.png" /> </imageobject> <textobject><phrase>starting_phase.png: Starting phase.</phrase></textobject> </mediaobject> </section> <section id="networking"> <title>Network Architecture</title> <para>Networking is the most important component in CloudStack, which serves network services from layer 2 to layer 7. In GsoC, fortunately I have a chance to learn about CloudsStack network architecture. It's really amazing. CloudStack's networking is divided to three parts:</para> <para><emphasis role="bold">NetworkGuru</emphasis></para> <para>NetworkGuru are responsible for:</para> <itemizedlist> <listitem><para>Design and implementation of virtual networks.</para></listitem> <listitem><para>IP adress management.</para></listitem> </itemizedlist> <para>See full description about Network Guru on my wiki post: <ulink url="https://cwiki.apache.org/confluence/display/CLOUDSTACK/Add+Xen+and+XCP+support+for+GRE+SDN+controller";>Add Xen/XCP support for GRE SDN controller</ulink></para> <para><emphasis role="bold">NetworkElement</emphasis></para> <para>NetworkElement in my opinion is the most important in CloudStack's networking. It represents components that are present in network. Such components can provide any kind of network service or support the virtual networking infrastructure and their interface is defined by com.cloud.network.element.NetworkElement. There are two things we attend in NetworkElement: services and elements.</para> <para>CloudStack currently support network services below:</para> <itemizedlist> <listitem><para>Dhcp service.</para></listitem> <listitem><para>Connectivity service.</para></listitem> <listitem><para>Firewall service.</para></listitem> <listitem><para>Load Balancing service.</para></listitem> <listitem><para>Network ACL service.</para></listitem> <listitem><para>Port Forwarding service.</para></listitem> <listitem><para>SourceNat service.</para></listitem> <listitem><para>StaticNat service.</para></listitem> <listitem><para>UerData service.</para></listitem> <listitem><para>Vpc service.</para></listitem> </itemizedlist> <para>Many Element implemented these above services. They are:</para> <itemizedlist> <listitem><para>MidonetElement.</para></listitem> <listitem><para>BigSwitchVnsElement.</para></listitem> <listitem><para>NiciraNvpElement.</para></listitem> <listitem><para>BaremetalElement.</para></listitem> <listitem><para>VirtualRouterElement.</para></listitem> <listitem><para>VpcVirtualRouterElement.</para></listitem> <listitem><para>CiscoVnmcElement.</para></listitem> <listitem><para>JuniperSrxExternalFirewallElement.</para></listitem> <listitem><para>ElasticLbElement.</para></listitem> <listitem><para>F5ExternalLbElement.</para></listitem> <listitem><para>CloudZoneNetworkElement.</para></listitem> <listitem><para>BaremetalPxeElement.</para></listitem> <listitem><para>BaremetalUserdataElement.</para></listitem> <listitem><para>DnsNotifier.</para></listitem> <listitem><para>OvsElement.</para></listitem> <listitem><para>SecurityGroupElement.</para></listitem> </itemizedlist> <para>See full description about Network Element on my wiki post: <ulink url="https://cwiki.apache.org/confluence/display/CLOUDSTACK/Add+Xen+and+XCP+support+for+GRE+SDN+controller";>Add Xen/XCP support for GRE SDN controller</ulink></para> <para>In addition, Elements willing to support network services have to implement corresponding methods from ServicesProvider interfaces. For example, NiciraNvpElement want to support staticNat rule so it has to override applyStaticNats method.</para> <para><emphasis role="bold">NetworkManager</emphasis></para> <para>Network Manager handle the resources managed by the network elements. They are also implemented as many other "resource" managers in CloudStack.</para> <para>For instance, the manager for setting up L2-in-L3 networks with Open vSwitch is OvsTunnelManagerImpl, whereas Virtual Router lifecycle is managed by VirtualApplianceManagerImpl.</para> <para>In the project, I'm going to implement L3 services for sdn controller, so I need to understand how network services implement.</para> </section> <section id="networkservices"> <title>Network Services</title> <para>As I said in previous session, network services are represented in ServiceProvider interfaces. There are currently 12 service providers including: Dhcp, Firewall, IpDeployer, LoadBalancing, NetworkACL, PortForwarding, RemoteAccessVpn, Site2siteVpn, SourceNat, StaticNat, UserData and Vpc. In this session, I'll focus on L3 services implemented in CloudStack such as FirewallRule, PortForwardingRule, StaticNatRules, etc. All services are implemented at NetworkElement and every elements including network plugins (nicira nvp, bigswitch vns,...), which is willing to support them, must override from NetworkElement. For a clearly exlaination, I'll take the StaticNat service implemented in Nicira NVP plugin, source code comes from NiciraNvpElement.java.</para> <para>NiciraNvpElement firstly has to check whether it can handle the StaticNat service via canHandle() method:</para> <mediaobject> <imageobject> <imagedata fileref="./images/canhandle.png" /> </imageobject> <imageobject> <imagedata fileref="./images/canhandledetail.png" /> </imageobject> <textobject><phrase>canhandledetail.png: canHandle() method.</phrase></textobject> </mediaobject> <para>After checking, NiciraNvp make a staticNat rely on their own Logical Router, that I won't report detail here.</para> <para>The sequence diagram for applying a L3 service is described below:</para> <mediaobject> <imageobject> <imagedata fileref="./images/network_service.png" /> </imageobject> <textobject><phrase>network_service.png: Network services implementation sequence diagram.</phrase></textobject> </mediaobject> <para>After understanding network architecture and services implementation, I decided to improve Ovs plugin to support L3 services. Because it's the native sdn controller, I want to use Virtual Router for L3 services deployment. This work will be done when I call L3 services execution from OvsElement to VirtualRouterManager. With Xen hosts, VirtualRouterElement execute L3 services via xapi plugin calls. I make a flow which describes more detail about the process below</para> <mediaobject> <imageobject> <imagedata fileref="./images/l3_services.png" /> </imageobject> <textobject><phrase>l3_services.png: Layer 3 services implementation in Ovs plugin.</phrase></textobject> </mediaobject> </section> <section id="opendaylight"> <title>Opendaylight Controller</title> <para>The project need to add an open source Openflow controller, and I decided to choose Opendaylight.</para> <para>Opendaylight (ODL) is an interesting experience that I have in GSoC. Before starting project, I still confused between many open source OpenFlow controller such as POX, NOX, Beacon, Floodlight, Opendaylight... Honestly, I do not have large knowledge of OpenFlow protocol and also open source SDN controller at the beginning of project. When the project was in progress, I chose Floodlight, a safe solution because of its rich of functionality and good documents. However, Sebastien Goasguen, CloudStack GSoC manager, recommended me to try Opendaylight. From the collected information, I found that Opendaylight are getting a lot of attentions from the community.</para> <para>At the moment, ODL has three main projects:</para> <itemizedlist> <listitem><para>Opendaylight Controller.</para></listitem> <listitem><para>Opendaylight Network Virtualization Platform.</para></listitem> <listitem><para>Opendaylight Virtual Tennant Network.</para></listitem> </itemizedlist> <para>It also has six incubating projects:</para> <itemizedlist> <listitem><para>YANG Tools.</para></listitem> <listitem><para>LISP Flow Mapping.</para></listitem> <listitem><para>OVSDB Integration.</para></listitem> <listitem><para>Openflow Protocol Library.</para></listitem> <listitem><para>BGP-LS/PCEP.</para></listitem> <listitem><para>Defense4All.</para></listitem> </itemizedlist> <para>For integrating Opendaylight to control and manage network services, I chose ODL Controller project, which is developed by Cisco programmers. The ODL controller is a pure software and as a JVM it can be run on any OS as long as it supports Java. The structure of the ODL controller is shown below:</para> <mediaobject> <imageobject> <imagedata fileref="./images/odl_structure.jpg" /> </imageobject> <textobject><phrase>odl_structure.jpg: Opendaylight Controller architecture.</phrase></textobject> </mediaobject> <para>The structure is separated to three layers:</para> <itemizedlist> <listitem><para><emphasis role="bold">Network Apps and Orchestration</emphasis>: the top layer consists of applications that utilize the network for normal network communications. Also included in this layer are business and network logic applications that control and monitor network behavior.</para></listitem> <listitem><para><emphasis role="bold">Controller Platform</emphasis>: the middle layer is the framework in which the SDN abstractions can manifest; providing a set of common APIs to the application layer (commonly referred to as the northbound interface), while implementing one or more protocols for command and control of the physical hardware within the network (typically referred to as the southbound interface).</para></listitem> <listitem><para><emphasis role="bold">Physical and Virtual Network Devices</emphasis>: The bottom layer consists of the physical and virtual devices, switches, routers, etc., that make up the connective fabric between all endpoints within the network.</para></listitem> </itemizedlist> <para>This controller is implemented strictly in software and is contained within its own Java Virtual Machine (JVM).</para> <para>Source code can be cloned from git: git clone https://git.opendaylight.org/gerrit/p/controller.git</para> <para>Applications make request to ODL Northbound API via HTTP. Currently, ODL supports not too much services. All REST API we can find here: <ulink url="https://wiki.opendaylight.org/view/OpenDaylight_Controller:REST_Reference_and_Authentication";>ODL Controller REST API</ulink></para> <para>For example, we can add query list of exist flows configured on a Node in a give container.</para> <para>GET http://<emphasis>controller-ip</emphasis>/controller/nb/v2/flow/{containerName}/{nodeType}/{nodeId}</para> <itemizedlist> <listitem><para>{containername}: name of the container. The container name for the base controller is “default”.</para></listitem> <listitem><para>{nodeType}: type of the node being programmed.</para></listitem> <listitem><para>{nodeId}: node identifier.</para></listitem> </itemizedlist> <para>Or we can add a new flow</para> <para>POST http://<emphasis>controller-ip</emphasis>/controller/nb/v2/flow/{containerName}/{nodeType}/{nodeId}/{name}</para> <para>with request body in XML or JSON format</para> <para>{ "actions" : [ "...", ... ], "nwDst" : "...", "hardTimeout" : "...", "installInHw" : "...", "tosBits" : "...", "cookie" : "...", "node" : { "id" : "...", "type" : "..." }, "dlDst" : "...", "name" : "...", "nwSrc" : "...", "vlanPriority" : "...", "protocol" : "...", "priority" : "...", "vlanId" : "...", "tpDst" : "...", "etherType" : "...", "tpSrc" : "...", "ingressPort" : "...", "idleTimeout" : "...", "dlSrc" : "..." }</para> <para>The following python client writen by Dwcarder describe more specific about using REST API:<ulink url="https://github.com/dwcarder/python-OpenDaylight/blob/master/OpenDaylight.py";>https://github.com/dwcarder/python-OpenDaylight/blob/master/OpenDaylight.py</ulink></para> <para>In project, I learnt how to make HTTP request from CloudStack to ODL for controlling and managing network services. However, there is a problem that ODL currently don't support L2 configuration, while integration ODL to CloudStack requires this. I found an incubating project, led by Brent Salisbury and Evan Zeller from the University of Kentucky, is currently trying to integrate OpenvSwitch database management protocol to ODL, which will allow ODL to view, modify and delete OpenvSwitch object such as bridges and ports by way of the OpenvSwitch databse. In short, this project mainly creates a module acts like OVSDB-client and uses JSON-RPC for remote management. I talked to them and jumped into this project. Thus, I'll do an extra work on ODL community to improve ODL Controller support L2 configuration while still integrate ODL to CloudStack by making a new ODL plugin with the same behavior of NiciraNvp and Ovs.</para> <para>Full information about the incubating project can be found here:<ulink url="https://wiki.opendaylight.org/view/Project_Proposals:OVSDB-Integration";>https://wiki.opendaylight.org/view/Project_Proposals:OVSDB-Integration</ulink></para> <para>The next session I will take a short description about XenAPI (also called Xapi), which applications use to interact virtualization resources in Xen hosts.</para> </section> <section id="xapi"> <title>Xen API</title> <para>There are many tool stacks we can use to manage Xen hosts, such as: XL, Xapi, libvirt or Xend. Of which, Xapi is the default. Xapi (or Xen API) is called from applications to control and manage virtualization resources in Xen hosts via XML-RPC. Xapi is the core component of XCP and XenServer and writen by Ocaml language.</para> <para>It's possible to talk directly to Xapi using XML-RPC. This is a way to make remote procedure calls using http requests. In fact, it's possible to send and receive messages using telnet but this is not recommended. The XML-RPC calls are the fixed standard, but we also have bindings to that XML-RPC for Python, C and Java.</para> <para>For example about using XML-RPC calls, I make a simple request written by python to list all VMs on a Xen host. Checkout here: <ulink url="https://gist.github.com/ngtuna/6094938";>https://gist.github.com/ngtuna/6094938</ulink></para> <para>We can find Xapi source code from: <ulink url="https://github.com/xen-org/xen-api";>https://github.com/xen-org/xen-api</ulink></para> <para>Xapi come with some main classes, each of them refer to a virtual resource object in Xen such as:</para> <itemizedlist> <listitem><para>VM: refer to virtual machine.</para></listitem> <listitem><para>VIF: refer to virtual NIC.</para></listitem> <listitem><para>VDI: refer to virtual volume or hard disk.</para></listitem> <listitem><para>...</para></listitem> </itemizedlist> <para>Full information about Xapi source code we can find here. <ulink url="http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/api/";>http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/api/</ulink> Click on each item we can see more detail.</para> <para><emphasis role="bold">Xapi plugin</emphasis></para> <para>Xapi has an extension mechanism that allows one to install a Python script (usually but it can be any executable) on the Xen host, and then call that through the Xapi. Writing a Xapi plugin in Python is simplified by using the XenAPIPlugin module, which is by default installed in dom0 in XCP. In my GsoC project, I have to call some plugin scripts to control and manage virtual switches. For example, I inserted a new function to get network name-label in vmops script.</para> <para>Then, we can call it directly from XE command line or via XML-RPC. Here is a simple call from XE:</para> <para>$xe host-call-plugin host-uuid=<emphasis>host-uuid</emphasis> plugin=vmops fn=getLabel</para> <para>If the plugins has some arguments, it should be inserted with "args:" keyword.</para> <para>In ACS, almost plugins are called from CitrixResourceBase.java. With my above function, I inserted a new method into CitrixResourceBase.java and called to the plugin as below:</para> <mediaobject> <imageobject> <imagedata fileref="./images/getlabel.png" /> </imageobject> </mediaobject> <para>In which, Connection class will init a session to Xen host and callHostPlugin method executes a XML-RPC call to plugin.</para> <para>Note that every Xapi plugin scripts must be placed into /etc/xapi.d/plugins.</para> </section> <section id="whativedone"> <title>What I've done</title> <para>In one-and-a-half month, I take understand all of above knowledge and finish two things:</para> <itemizedlist> <listitem><para>improve gre controller to support XCP.</para></listitem> <listitem><para>re-factor GRE source code by following NiciraNVP plugin design.</para></listitem> </itemizedlist> <para><emphasis role="bold">improve gre controller to support XCP</emphasis></para> <para>From the understanding of how the native SDN works, a small patch has been made to help it works with Xen Cloud Platform (XCP) version 1.6. Without the patch, this controller can serve XenServer only, the commercial version of XCP. All things I have to do in next period are: trying SDN with XCP, debugging to find out what errors are and why they occur. After some efforts, I figured out following problems:</para> <itemizedlist> <listitem><para>The SDN controller has to know what interface it'll deploy GRE tunnels. To do this check, it looks into network to find out the PIF's interface. It has a network name-label, which user defined in the deploy zone phase. If not, it will be replaced by a default label. However, XCP's network has no user-defined or default name-label. Therefore in this step I have made a trick. I used whatever name-label found in the XCP host to bypass this check.</para></listitem> <listitem><para>When creating an OVS bridge, the controller creates a new dom0 vif, plugs to the bridge and immediately unplugs it. This action aims to ask XenServer create the bridge without running ovs-vsctl or brctl script. Finding it is not very important to XCP hosts, I ignored this step for saving times. Moreover, it also generated an error from xenopsd daemon.</para></listitem> <listitem><para>The script playing a direct role to interact with openvswitch is ovstunnel. It requires a lib named cloudstack_pluginlib, which does not exist in XCP. Thus, I inserted this file into copying process from CloudStack to XCP when add-host phase occurs.</para></listitem> <listitem><para>The "setup_ovs_bridge" function in ovstunnel takes a look into XenServer version to act a blocking IPv6. However, product_version parameter does not exist on XCP. It uses platform_version parameter instead. So, I decided to ignore this step.</para></listitem> </itemizedlist> <para>The patch is already committed to sdnextensions branch. It is also the primary branch I have been working on this GSoC period.</para> <para><emphasis role="bold">re-factor GRE source code by following NiciraNVP plugin design</emphasis></para> <para>GRE source code was re-factored with following changes:</para> <itemizedlist> <listitem><para>add Connectivity service checking: All of L2 configuration methods now have to check whether Ovs plugin can handle Connectivity service..</para></listitem> <listitem><para>move commands / answers to a new package: com.cloud.agent.api.</para></listitem> <listitem><para>add new NetworkProvider: Ovs.</para></listitem> <listitem><para>add L3 services to Ovs Capabilities: Ovs Capability now is set enabled to such L3 services as SourceNat, StaticNat, PortForwarding, RedundantRouter, Gateway. L2 service Connectivity is also set enabled.</para></listitem> <listitem><para>add L3 services prototype code to OvsElement.java</para></listitem> </itemizedlist> <para>In next days, I will done the following things:</para> <itemizedlist> <listitem><para>implement L3 services with Virtual Router.</para></listitem> <listitem><para>improve Ovs to support KVM hypervisor.</para></listitem> <listitem><para>add new ODL plugin using ODL controller to control and manager network services.</para></listitem> </itemizedlist> </section> </section>
