Radhika, There are several aspects that need to be documented: 1) How to build the software (OpenContrail + hypervisor support). 2) How to install the software (Starting the multiple components of the contrail solution). 3) How to provision a zone to use the contrail plugin. 4) Usage: document any deltas when using this plugin when it comes to the user API (network, etc).
When it comes to building OpenContrail, we currently have that we distribute as devstack fork (https://github.com/dsetia/devstack/tree/master/contrail) that builds and starts the OpenContrail configuration, control and virtual-router components. This script needs to be split out such that we can separate from OpenStack and can be use to build and start the OpenContrail components independently. Deepinder is working on this but it is not complete yet. For a XenServer hypervisor, one also needs to build the virtual-router components on a DDK VM, so that this can then be executed on the target. The management server must have a file "contrail.properties" with the following content: api.hostname = localhost api.port = 8082 This is how the management server plugin locates the contrail API server. Provisioning a zone is relatively simple process: 1. create a zone (networktype: Advanced) 2. create Pods/Clusters as required 3. create physical network using the following parameters: args = {'name': 'ip-fabric', 'zoneid': zone_id, 'isolationmethods': 'L3VPN'} response = client.request('createPhysicalNetwork', args) 4. setup the Public network parameters: response = client.request('listNetworks', {'issystem': 'true', 'traffictype': 'Public'}) uuid = response['listnetworksresponse']['network'][0]['id'] args = {'networkid': uuid, 'zoneid': zone_id, 'vlan': 'untagged', 'startip': PARAMS['public_net']['startip'], 'endip': PARAMS['public_net']['endip'], 'gateway': PARAMS['public_net']['gateway'], 'netmask': PARAMS['public_net']['netmask']} response = client.request('createVlanIpRange', args) 5. Enable the providers JuniperContrailRouter and JuniperContrailVpcRouter (uncommited): args = {'name': provider, 'physicalnetworkid': physnet} response = client.request('addNetworkServiceProvider', args) Step 3 above uses the new isolation mechanism (L3VPN) which is uncommitted. This was a change requested during the plugin code review that is being tested but not yet upstreamed. When it comes to usage: a) The public network is virtualized. The admin of the DC is expected to configure a gateway between the virtualized domain and the "outside world" One of the main goal of the OpenContrail design is to enable DC operators to run the network as a pure IP underlay. This means no VLAN support. The advantage is that one can run network topologies that provide a much higher throughput; but you still need a gateway to the outside world. One can use a RFC 4364 compliant router/switch for this task (it also need to support RFC 4023). The OpenContrail project also provides an option to run the virtual-router software as a gateway; this is for testing purposes only since it is not a cost effective solution for high traffic volumes. Having a gateway in place, one needs to configure the OpenContrail controller and the gateway to speak to each other. This step is independent of CloudStack itself and is the same on OpenStack. b) Guest networks work as expected; c) Static IP is supported (implemented directly on the vrouter); d) VPC code is not upstreamed yet... you should see the code review requests soon; it can be used for a tenant to exchange traffic between its networks without having the traffic flow through a DomainRouter. e) SourceNAT (1:n NAT) requires a virtual machine appliance... f) We don't have today a cloudstack API to allow a tenant network to connect to another tenant (or admin) network; One of the main features of OpenContrail is that it enables this sort of communication to go directly without having to flow through a DomainRouter VM; this is very useful when the admin is providing services to the tenant (e.g. think database-as-a-service). There is a lot of ground to cover... I would also like us to put together a test rig like devstack where all of these pieces can come together. Pedro. On Dec 1, 2013, at 9:29 PM, Radhika Puthiyetath <radhika.puthiyet...@citrix.com> wrote: > Hi Pedro, > > Is there a documentation exist on this feature ? If not, I am interested to > work on it. > > Please let me know how we can collaborate developing content. > > Regards > -Radhika > > -----Original Message----- > From: Pedro Roque Marques [mailto:pedro.r.marq...@gmail.com] > Sent: Tuesday, September 17, 2013 3:42 AM > To: dev@cloudstack.apache.org > Subject: contrail virtual network controller > > Myself and a few others in the Contrail team have been working on a > cloudstack network plugin that interfaces with the contrail VNC > (http://www.opencontrail.org). At the moment the plugin provides isolated > guest networks (and a virtualized "Public" network) as an overlay that is > capable of interconnecting directly with routers/switches that implement the > existing standard for network virtualization (RFC 4364). > > We would like to contribute this code to CloudStack. We intend to continue to > enhance it in order to add full support for functionality one would expect > out of the EC2 VPN API. > > What is the process to do that ? > > thanks, > Pedro.
