Date   

Re: ovsdb neutron compile failed, and propose a possible patch for this issue.

denghui huang
 

Hi all
   
    Step3,
cd ../../ovsdb
mvn clean install

after i patched pom.xml as the following:
diff --git a/ovsdb/pom.xml b/ovsdb/pom.xml
index 02acec7..c3d01ae 100755
--- a/ovsdb/pom.xml
+++ b/ovsdb/pom.xml
@@ -180,7 +180,22 @@
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
<version>1.0</version>
- </dependency>
+ </dependency>
+ <dependency>
+ <groupId>com.google.collections</groupId>
+ <artifactId>google-collections</artifactId>
+ <version>1.0</version>
+ </dependency>
+ <dependency>
+ <groupId>org.sonatype.sisu</groupId>
+ <artifactId>sisu-guava</artifactId>
+ <version>0.9.9</version>
+ </dependency>
+ <dependency>
+ <groupId>com.google.guava</groupId>
+ <artifactId>guava</artifactId>
+ <version>15.0</version>
+ </dependency>
</dependencies>

<profiles>


still have the following error:


steven@steven-Vostro-2420 ~/code/SDN/controller/opendaylight/ovsdb/ovsdb $ mvn clean install
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building ovsdb 0.5.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.3:clean (default-clean) @ ovsdb ---
[INFO] Deleting file set: /home/steven/code/SDN/controller/opendaylight/ovsdb/ovsdb/target (included: [**], excluded: [])
[INFO]
[INFO] --- properties-maven-plugin:1.0-alpha-2:set-system-properties (default) @ ovsdb ---
[INFO] Set 1 system property
[INFO]
[INFO] --- maven-checkstyle-plugin:2.10:check (default) @ ovsdb ---
[INFO] Starting audit...
Audit done.

[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ ovsdb ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /home/steven/code/SDN/controller/opendaylight/ovsdb/ovsdb/src/main/resources
[INFO]
[INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ ovsdb ---
[INFO] Compiling 92 source files to /home/steven/code/SDN/controller/opendaylight/ovsdb/ovsdb/target/classes
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/ovsdb/src/main/java/org/opendaylight/ovsdb/plugin/IPAddressProperty.java:[33,4] error: method does not override or implement a method from a supertype
[ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/ovsdb/src/main/java/org/opendaylight/ovsdb/plugin/L4PortProperty.java:[32,4] error: method does not override or implement a method from a supertype
[INFO] 2 errors
[INFO] -------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6.552s
[INFO] Finished at: Thu Nov 28 23:28:34 CST 2013
[INFO] Final Memory: 29M/235M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project ovsdb: Compilation failure: Compilation failure:
[ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/ovsdb/src/main/java/org/opendaylight/ovsdb/plugin/IPAddressProperty.java:[33,4] error: method does not override or implement a method from a supertype
[ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/ovsdb/src/main/java/org/opendaylight/ovsdb/plugin/L4PortProperty.java:[32,4] error: method does not override or implement a method from a supertype
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException



2013/11/28 huang denghui <huangdenghui@...>

Hi all
 
    ovsdb northbound compiles failed too, error information is the following:
steven@steven-Vostro-2420 ~/code/SDN/controller/opendaylight/ovsdb/northbound/ovsdb $ mvn clean install
[INFO] Scanning for projects...
Downloading: http://nexus.opendaylight.org/content/repositories/central2/org/apache/felix/maven-bundle-plugin/${bundle.plugin.version}/maven-bundle-plugin-${bundle.plugin.version}.pom
Downloading: http://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/apache/felix/maven-bundle-plugin/${bundle.plugin.version}/maven-bundle-plugin-${bundle.plugin.version}.pom
Downloading: http://repo.maven.apache.org/maven2/org/apache/felix/maven-bundle-plugin/${bundle.plugin.version}/maven-bundle-plugin-${bundle.plugin.version}.pom
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]  
[ERROR]   The project org.opendaylight.ovsdb:ovsdb.northbound:0.5.0-SNAPSHOT (/home/steven/code/SDN/controller/opendaylight/ovsdb/northbound/ovsdb/pom.xml) has 3 errors
[ERROR]     Unresolveable build extension: Plugin org.apache.felix:maven-bundle-plugin:${bundle.plugin.version} or one of its dependencies could not be resolved: Failed to collect dependencies for org.apache.felix:maven-bundle-plugin:jar:${bundle.plugin.version} (): Failed to read artifact descriptor for org.apache.felix:maven-bundle-plugin:jar:${bundle.plugin.version}: Could not transfer artifact org.apache.felix:maven-bundle-plugin:pom:${bundle.plugin.version} from/to central2 (http://nexus.opendaylight.org/content/repositories/central2/): Invalid uri 'http://nexus.opendaylight.org/content/repositories/central2//org/apache/felix/maven-bundle-plugin/${bundle.plugin.version}/maven-bundle-plugin-${bundle.plugin.version}.pom': escaped absolute path not valid -> [Help 2]
[ERROR]     Unknown packaging: bundle @ line 19, column 14
[ERROR]     'build.plugins.plugin.version' for org.apache.felix:maven-bundle-plugin must be a valid version but is '${bundle.plugin.version}'. @ line 30, column 18

[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException



2013/11/28 huang denghui <huangdenghui@...>
Hi all
   
    Today, i follow https://wiki.opendaylight.org/view/OVSDB_Integration:Mininet_OVSDB_Tutorial section

Clone the OVSDB Repo and Insert into Controller, to compile ovsdb neutron, but i get the following error.

    steven@steven-Vostro-2420 ~/code/SDN/controller/opendaylight/ovsdb/neutron $ mvn clean install
    [INFO] Scanning for projects...
    [INFO]                                                                        
    [INFO] ------------------------------------------------------------------------
    [INFO] Building ovsdb.neutron 0.5.0-SNAPSHOT
    [INFO] ------------------------------------------------------------------------
    [INFO]
    [INFO] --- maven-clean-plugin:2.3:clean (default-clean) @ ovsdb.neutron ---
    [INFO]
    [INFO] --- properties-maven-plugin:1.0-alpha-2:set-system-properties (default) @ ovsdb.neutron ---
    [INFO] Set 1 system property
    [INFO]
    [INFO] --- maven-checkstyle-plugin:2.10:check (default) @ ovsdb.neutron ---
    [INFO] Starting audit...
    Audit done.
     
    [INFO]
    [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ ovsdb.neutron ---
    [INFO] Using 'UTF-8' encoding to copy filtered resources.
    [INFO] skip non existing resourceDirectory /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/resources
    [INFO]
    [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ ovsdb.neutron ---
    [INFO] Compiling 13 source files to /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/target/classes
    [INFO] -------------------------------------------------------------
    [ERROR] COMPILATION ERROR :
    [INFO] -------------------------------------------------------------
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[83,53] error: cannot access ForwardingSet
    [ERROR]   class file for com.google.common.collect.ForwardingSet not found
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[127,53] error: incompatible types
    [ERROR]     OvsDBSet<String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[172,53] error: incompatible types
    [ERROR]     OvsDBSet<String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[231,62] error: cannot access ForwardingMap
    [ERROR]   class file for com.google.common.collect.ForwardingMap not found
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[252,70] error: incompatible types
    [ERROR]     OvsDBSet<BigInteger>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[268,68] error: incompatible types
    [ERROR]     OvsDBSet<BigInteger>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[347,45] error: incompatible types
    [ERROR]     OvsDBSet<UUID>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[397,31] error: bad operand types for binary operator '=='
    [ERROR]  <null>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[397,52] error: cannot find symbol
    [ERROR]  variable interfaces of type OvsDBSet<UUID>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[403,42] error: cannot find symbol
    [ERROR]  variable interfaces of type OvsDBSet<UUID>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[416,19] error: cannot find symbol
    [ERROR]  variable options of type OvsDBMap<String,String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[417,19] error: cannot find symbol
    [ERROR]  variable options of type OvsDBMap<String,String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[418,19] error: cannot find symbol
    [ERROR]  variable options of type OvsDBMap<String,String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/SouthboundHandler.java:[117,57] error: incompatible types
    [ERROR]     OvsDBSet<UUID>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/SouthboundHandler.java:[165,61] error: incompatible types
    [ERROR]     OvsDBSet<UUID>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[155,27] error: bad operand types for binary operator '=='
    [ERROR]  <null>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[155,48] error: cannot find symbol
    [ERROR]  variable interfaces of type OvsDBSet<UUID>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[161,38] error: cannot find symbol
    [ERROR]  variable interfaces of type OvsDBSet<UUID>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[171,15] error: cannot find symbol
    [ERROR]  variable options of type OvsDBMap<String,String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[224,53] error: incompatible types
    [ERROR]     OvsDBSet<String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[258,53] error: incompatible types
    [ERROR]     OvsDBSet<String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[144,70] error: incompatible types
    [ERROR]     OvsDBMap<String,String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[184,62] error: incompatible types
    [ERROR]     OvsDBMap<String,String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[209,12] error: cannot find symbol
    [ERROR]  variable tags of type OvsDBSet<BigInteger>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[228,53] error: incompatible types
    [ERROR]     OvsDBSet<UUID>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[238,53] error: incompatible types
    [ERROR]     OvsDBSet<String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[245,57] error: incompatible types
    [ERROR]     OvsDBSet<BigInteger>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[283,53] error: incompatible types
    [ERROR]     OvsDBSet<UUID>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/AdminConfigManager.java:[117,57] error: incompatible types
    [INFO] 29 errors
    [INFO] -------------------------------------------------------------
    [INFO] ------------------------------------------------------------------------
    [INFO] BUILD FAILURE
    [INFO] ------------------------------------------------------------------------
    [INFO] Total time: 5.522s
    [INFO] Finished at: Thu Nov 28 20:14:23 CST 2013
    [INFO] Final Memory: 31M/284M
    [INFO] ------------------------------------------------------------------------
    [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project ovsdb.neutron: Compilation failure: Compilation failure:
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[83,53] error: cannot access ForwardingSet
    [ERROR] class file for com.google.common.collect.ForwardingSet not found
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[127,53] error: incompatible types
    [ERROR] OvsDBSet<String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[172,53] error: incompatible types
    [ERROR] OvsDBSet<String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[231,62] error: cannot access ForwardingMap
    [ERROR] class file for com.google.common.collect.ForwardingMap not found
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[252,70] error: incompatible types
    [ERROR] OvsDBSet<BigInteger>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[268,68] error: incompatible types
    [ERROR] OvsDBSet<BigInteger>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[347,45] error: incompatible types
    [ERROR] OvsDBSet<UUID>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[397,31] error: bad operand types for binary operator '=='
    [ERROR] <null>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[397,52] error: cannot find symbol
    [ERROR] variable interfaces of type OvsDBSet<UUID>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[403,42] error: cannot find symbol
    [ERROR] variable interfaces of type OvsDBSet<UUID>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[416,19] error: cannot find symbol
    [ERROR] variable options of type OvsDBMap<String,String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[417,19] error: cannot find symbol
    [ERROR] variable options of type OvsDBMap<String,String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[418,19] error: cannot find symbol
    [ERROR] variable options of type OvsDBMap<String,String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/SouthboundHandler.java:[117,57] error: incompatible types
    [ERROR] OvsDBSet<UUID>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/SouthboundHandler.java:[165,61] error: incompatible types
    [ERROR] OvsDBSet<UUID>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[155,27] error: bad operand types for binary operator '=='
    [ERROR] <null>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[155,48] error: cannot find symbol
    [ERROR] variable interfaces of type OvsDBSet<UUID>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[161,38] error: cannot find symbol
    [ERROR] variable interfaces of type OvsDBSet<UUID>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[171,15] error: cannot find symbol
    [ERROR] variable options of type OvsDBMap<String,String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[224,53] error: incompatible types
    [ERROR] OvsDBSet<String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[258,53] error: incompatible types
    [ERROR] OvsDBSet<String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[144,70] error: incompatible types
    [ERROR] OvsDBMap<String,String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[184,62] error: incompatible types
    [ERROR] OvsDBMap<String,String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[209,12] error: cannot find symbol
    [ERROR] variable tags of type OvsDBSet<BigInteger>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[228,53] error: incompatible types
    [ERROR] OvsDBSet<UUID>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[238,53] error: incompatible types
    [ERROR] OvsDBSet<String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[245,57] error: incompatible types
    [ERROR] OvsDBSet<BigInteger>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[283,53] error: incompatible types
    [ERROR] OvsDBSet<UUID>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/AdminConfigManager.java:[117,57] error: incompatible types
    [ERROR] -> [Help 1]
    [ERROR]
    [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
    [ERROR] Re-run Maven using the -X switch to enable full debug logging.
    [ERROR]
    [ERROR] For more information about the errors and possible solutions, please read the following articles:
    [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException

    After checked with pom.xml in ovsdb/neutron, i found that dependency google-collections is missed, by adding this missed piece, it works,
    So i propose a possible patch (in attachment) for this issue. Hopefully, it really help.  And if it is necessary, i can fire a bug for this, than patch it.



Re: ovsdb neutron compile failed, and propose a possible patch for this issue.

denghui huang
 

Hi all
 
    ovsdb northbound compiles failed too, error information is the following:
steven@steven-Vostro-2420 ~/code/SDN/controller/opendaylight/ovsdb/northbound/ovsdb $ mvn clean install
[INFO] Scanning for projects...
Downloading: http://nexus.opendaylight.org/content/repositories/central2/org/apache/felix/maven-bundle-plugin/${bundle.plugin.version}/maven-bundle-plugin-${bundle.plugin.version}.pom
Downloading: http://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/apache/felix/maven-bundle-plugin/${bundle.plugin.version}/maven-bundle-plugin-${bundle.plugin.version}.pom
Downloading: http://repo.maven.apache.org/maven2/org/apache/felix/maven-bundle-plugin/${bundle.plugin.version}/maven-bundle-plugin-${bundle.plugin.version}.pom
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]  
[ERROR]   The project org.opendaylight.ovsdb:ovsdb.northbound:0.5.0-SNAPSHOT (/home/steven/code/SDN/controller/opendaylight/ovsdb/northbound/ovsdb/pom.xml) has 3 errors
[ERROR]     Unresolveable build extension: Plugin org.apache.felix:maven-bundle-plugin:${bundle.plugin.version} or one of its dependencies could not be resolved: Failed to collect dependencies for org.apache.felix:maven-bundle-plugin:jar:${bundle.plugin.version} (): Failed to read artifact descriptor for org.apache.felix:maven-bundle-plugin:jar:${bundle.plugin.version}: Could not transfer artifact org.apache.felix:maven-bundle-plugin:pom:${bundle.plugin.version} from/to central2 (http://nexus.opendaylight.org/content/repositories/central2/): Invalid uri 'http://nexus.opendaylight.org/content/repositories/central2//org/apache/felix/maven-bundle-plugin/${bundle.plugin.version}/maven-bundle-plugin-${bundle.plugin.version}.pom': escaped absolute path not valid -> [Help 2]
[ERROR]     Unknown packaging: bundle @ line 19, column 14
[ERROR]     'build.plugins.plugin.version' for org.apache.felix:maven-bundle-plugin must be a valid version but is '${bundle.plugin.version}'. @ line 30, column 18
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException



2013/11/28 huang denghui <huangdenghui@...>

Hi all
   
    Today, i follow https://wiki.opendaylight.org/view/OVSDB_Integration:Mininet_OVSDB_Tutorial section

Clone the OVSDB Repo and Insert into Controller, to compile ovsdb neutron, but i get the following error.

    steven@steven-Vostro-2420 ~/code/SDN/controller/opendaylight/ovsdb/neutron $ mvn clean install
    [INFO] Scanning for projects...
    [INFO]                                                                        
    [INFO] ------------------------------------------------------------------------
    [INFO] Building ovsdb.neutron 0.5.0-SNAPSHOT
    [INFO] ------------------------------------------------------------------------
    [INFO]
    [INFO] --- maven-clean-plugin:2.3:clean (default-clean) @ ovsdb.neutron ---
    [INFO]
    [INFO] --- properties-maven-plugin:1.0-alpha-2:set-system-properties (default) @ ovsdb.neutron ---
    [INFO] Set 1 system property
    [INFO]
    [INFO] --- maven-checkstyle-plugin:2.10:check (default) @ ovsdb.neutron ---
    [INFO] Starting audit...
    Audit done.
     
    [INFO]
    [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ ovsdb.neutron ---
    [INFO] Using 'UTF-8' encoding to copy filtered resources.
    [INFO] skip non existing resourceDirectory /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/resources
    [INFO]
    [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ ovsdb.neutron ---
    [INFO] Compiling 13 source files to /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/target/classes
    [INFO] -------------------------------------------------------------
    [ERROR] COMPILATION ERROR :
    [INFO] -------------------------------------------------------------
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[83,53] error: cannot access ForwardingSet
    [ERROR]   class file for com.google.common.collect.ForwardingSet not found
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[127,53] error: incompatible types
    [ERROR]     OvsDBSet<String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[172,53] error: incompatible types
    [ERROR]     OvsDBSet<String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[231,62] error: cannot access ForwardingMap
    [ERROR]   class file for com.google.common.collect.ForwardingMap not found
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[252,70] error: incompatible types
    [ERROR]     OvsDBSet<BigInteger>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[268,68] error: incompatible types
    [ERROR]     OvsDBSet<BigInteger>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[347,45] error: incompatible types
    [ERROR]     OvsDBSet<UUID>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[397,31] error: bad operand types for binary operator '=='
    [ERROR]  <null>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[397,52] error: cannot find symbol
    [ERROR]  variable interfaces of type OvsDBSet<UUID>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[403,42] error: cannot find symbol
    [ERROR]  variable interfaces of type OvsDBSet<UUID>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[416,19] error: cannot find symbol
    [ERROR]  variable options of type OvsDBMap<String,String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[417,19] error: cannot find symbol
    [ERROR]  variable options of type OvsDBMap<String,String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[418,19] error: cannot find symbol
    [ERROR]  variable options of type OvsDBMap<String,String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/SouthboundHandler.java:[117,57] error: incompatible types
    [ERROR]     OvsDBSet<UUID>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/SouthboundHandler.java:[165,61] error: incompatible types
    [ERROR]     OvsDBSet<UUID>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[155,27] error: bad operand types for binary operator '=='
    [ERROR]  <null>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[155,48] error: cannot find symbol
    [ERROR]  variable interfaces of type OvsDBSet<UUID>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[161,38] error: cannot find symbol
    [ERROR]  variable interfaces of type OvsDBSet<UUID>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[171,15] error: cannot find symbol
    [ERROR]  variable options of type OvsDBMap<String,String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[224,53] error: incompatible types
    [ERROR]     OvsDBSet<String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[258,53] error: incompatible types
    [ERROR]     OvsDBSet<String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[144,70] error: incompatible types
    [ERROR]     OvsDBMap<String,String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[184,62] error: incompatible types
    [ERROR]     OvsDBMap<String,String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[209,12] error: cannot find symbol
    [ERROR]  variable tags of type OvsDBSet<BigInteger>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[228,53] error: incompatible types
    [ERROR]     OvsDBSet<UUID>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[238,53] error: incompatible types
    [ERROR]     OvsDBSet<String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[245,57] error: incompatible types
    [ERROR]     OvsDBSet<BigInteger>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[283,53] error: incompatible types
    [ERROR]     OvsDBSet<UUID>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/AdminConfigManager.java:[117,57] error: incompatible types
    [INFO] 29 errors
    [INFO] -------------------------------------------------------------
    [INFO] ------------------------------------------------------------------------
    [INFO] BUILD FAILURE
    [INFO] ------------------------------------------------------------------------
    [INFO] Total time: 5.522s
    [INFO] Finished at: Thu Nov 28 20:14:23 CST 2013
    [INFO] Final Memory: 31M/284M
    [INFO] ------------------------------------------------------------------------
    [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project ovsdb.neutron: Compilation failure: Compilation failure:
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[83,53] error: cannot access ForwardingSet
    [ERROR] class file for com.google.common.collect.ForwardingSet not found
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[127,53] error: incompatible types
    [ERROR] OvsDBSet<String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[172,53] error: incompatible types
    [ERROR] OvsDBSet<String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[231,62] error: cannot access ForwardingMap
    [ERROR] class file for com.google.common.collect.ForwardingMap not found
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[252,70] error: incompatible types
    [ERROR] OvsDBSet<BigInteger>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[268,68] error: incompatible types
    [ERROR] OvsDBSet<BigInteger>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[347,45] error: incompatible types
    [ERROR] OvsDBSet<UUID>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[397,31] error: bad operand types for binary operator '=='
    [ERROR] <null>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[397,52] error: cannot find symbol
    [ERROR] variable interfaces of type OvsDBSet<UUID>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[403,42] error: cannot find symbol
    [ERROR] variable interfaces of type OvsDBSet<UUID>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[416,19] error: cannot find symbol
    [ERROR] variable options of type OvsDBMap<String,String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[417,19] error: cannot find symbol
    [ERROR] variable options of type OvsDBMap<String,String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[418,19] error: cannot find symbol
    [ERROR] variable options of type OvsDBMap<String,String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/SouthboundHandler.java:[117,57] error: incompatible types
    [ERROR] OvsDBSet<UUID>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/SouthboundHandler.java:[165,61] error: incompatible types
    [ERROR] OvsDBSet<UUID>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[155,27] error: bad operand types for binary operator '=='
    [ERROR] <null>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[155,48] error: cannot find symbol
    [ERROR] variable interfaces of type OvsDBSet<UUID>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[161,38] error: cannot find symbol
    [ERROR] variable interfaces of type OvsDBSet<UUID>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[171,15] error: cannot find symbol
    [ERROR] variable options of type OvsDBMap<String,String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[224,53] error: incompatible types
    [ERROR] OvsDBSet<String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[258,53] error: incompatible types
    [ERROR] OvsDBSet<String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[144,70] error: incompatible types
    [ERROR] OvsDBMap<String,String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[184,62] error: incompatible types
    [ERROR] OvsDBMap<String,String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[209,12] error: cannot find symbol
    [ERROR] variable tags of type OvsDBSet<BigInteger>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[228,53] error: incompatible types
    [ERROR] OvsDBSet<UUID>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[238,53] error: incompatible types
    [ERROR] OvsDBSet<String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[245,57] error: incompatible types
    [ERROR] OvsDBSet<BigInteger>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[283,53] error: incompatible types
    [ERROR] OvsDBSet<UUID>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/AdminConfigManager.java:[117,57] error: incompatible types
    [ERROR] -> [Help 1]
    [ERROR]
    [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
    [ERROR] Re-run Maven using the -X switch to enable full debug logging.
    [ERROR]
    [ERROR] For more information about the errors and possible solutions, please read the following articles:
    [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException

    After checked with pom.xml in ovsdb/neutron, i found that dependency google-collections is missed, by adding this missed piece, it works,
    So i propose a possible patch (in attachment) for this issue. Hopefully, it really help.  And if it is necessary, i can fire a bug for this, than patch it.


ovsdb neutron compile failed, and propose a possible patch for this issue.

denghui huang
 

Hi all
   
    Today, i follow https://wiki.opendaylight.org/view/OVSDB_Integration:Mininet_OVSDB_Tutorial section

Clone the OVSDB Repo and Insert into Controller, to compile ovsdb neutron, but i get the following error.

    steven@steven-Vostro-2420 ~/code/SDN/controller/opendaylight/ovsdb/neutron $ mvn clean install
    [INFO] Scanning for projects...
    [INFO]                                                                        
    [INFO] ------------------------------------------------------------------------
    [INFO] Building ovsdb.neutron 0.5.0-SNAPSHOT
    [INFO] ------------------------------------------------------------------------
    [INFO]
    [INFO] --- maven-clean-plugin:2.3:clean (default-clean) @ ovsdb.neutron ---
    [INFO]
    [INFO] --- properties-maven-plugin:1.0-alpha-2:set-system-properties (default) @ ovsdb.neutron ---
    [INFO] Set 1 system property
    [INFO]
    [INFO] --- maven-checkstyle-plugin:2.10:check (default) @ ovsdb.neutron ---
    [INFO] Starting audit...
    Audit done.
     
    [INFO]
    [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ ovsdb.neutron ---
    [INFO] Using 'UTF-8' encoding to copy filtered resources.
    [INFO] skip non existing resourceDirectory /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/resources
    [INFO]
    [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ ovsdb.neutron ---
    [INFO] Compiling 13 source files to /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/target/classes
    [INFO] -------------------------------------------------------------
    [ERROR] COMPILATION ERROR :
    [INFO] -------------------------------------------------------------
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[83,53] error: cannot access ForwardingSet
    [ERROR]   class file for com.google.common.collect.ForwardingSet not found
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[127,53] error: incompatible types
    [ERROR]     OvsDBSet<String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[172,53] error: incompatible types
    [ERROR]     OvsDBSet<String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[231,62] error: cannot access ForwardingMap
    [ERROR]   class file for com.google.common.collect.ForwardingMap not found
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[252,70] error: incompatible types
    [ERROR]     OvsDBSet<BigInteger>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[268,68] error: incompatible types
    [ERROR]     OvsDBSet<BigInteger>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[347,45] error: incompatible types
    [ERROR]     OvsDBSet<UUID>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[397,31] error: bad operand types for binary operator '=='
    [ERROR]  <null>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[397,52] error: cannot find symbol
    [ERROR]  variable interfaces of type OvsDBSet<UUID>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[403,42] error: cannot find symbol
    [ERROR]  variable interfaces of type OvsDBSet<UUID>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[416,19] error: cannot find symbol
    [ERROR]  variable options of type OvsDBMap<String,String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[417,19] error: cannot find symbol
    [ERROR]  variable options of type OvsDBMap<String,String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[418,19] error: cannot find symbol
    [ERROR]  variable options of type OvsDBMap<String,String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/SouthboundHandler.java:[117,57] error: incompatible types
    [ERROR]     OvsDBSet<UUID>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/SouthboundHandler.java:[165,61] error: incompatible types
    [ERROR]     OvsDBSet<UUID>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[155,27] error: bad operand types for binary operator '=='
    [ERROR]  <null>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[155,48] error: cannot find symbol
    [ERROR]  variable interfaces of type OvsDBSet<UUID>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[161,38] error: cannot find symbol
    [ERROR]  variable interfaces of type OvsDBSet<UUID>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[171,15] error: cannot find symbol
    [ERROR]  variable options of type OvsDBMap<String,String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[224,53] error: incompatible types
    [ERROR]     OvsDBSet<String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[258,53] error: incompatible types
    [ERROR]     OvsDBSet<String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[144,70] error: incompatible types
    [ERROR]     OvsDBMap<String,String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[184,62] error: incompatible types
    [ERROR]     OvsDBMap<String,String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[209,12] error: cannot find symbol
    [ERROR]  variable tags of type OvsDBSet<BigInteger>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[228,53] error: incompatible types
    [ERROR]     OvsDBSet<UUID>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[238,53] error: incompatible types
    [ERROR]     OvsDBSet<String>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[245,57] error: incompatible types
    [ERROR]     OvsDBSet<BigInteger>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[283,53] error: incompatible types
    [ERROR]     OvsDBSet<UUID>
    /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/AdminConfigManager.java:[117,57] error: incompatible types
    [INFO] 29 errors
    [INFO] -------------------------------------------------------------
    [INFO] ------------------------------------------------------------------------
    [INFO] BUILD FAILURE
    [INFO] ------------------------------------------------------------------------
    [INFO] Total time: 5.522s
    [INFO] Finished at: Thu Nov 28 20:14:23 CST 2013
    [INFO] Final Memory: 31M/284M
    [INFO] ------------------------------------------------------------------------
    [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project ovsdb.neutron: Compilation failure: Compilation failure:
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[83,53] error: cannot access ForwardingSet
    [ERROR] class file for com.google.common.collect.ForwardingSet not found
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[127,53] error: incompatible types
    [ERROR] OvsDBSet<String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[172,53] error: incompatible types
    [ERROR] OvsDBSet<String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[231,62] error: cannot access ForwardingMap
    [ERROR] class file for com.google.common.collect.ForwardingMap not found
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[252,70] error: incompatible types
    [ERROR] OvsDBSet<BigInteger>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[268,68] error: incompatible types
    [ERROR] OvsDBSet<BigInteger>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[347,45] error: incompatible types
    [ERROR] OvsDBSet<UUID>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[397,31] error: bad operand types for binary operator '=='
    [ERROR] <null>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[397,52] error: cannot find symbol
    [ERROR] variable interfaces of type OvsDBSet<UUID>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[403,42] error: cannot find symbol
    [ERROR] variable interfaces of type OvsDBSet<UUID>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[416,19] error: cannot find symbol
    [ERROR] variable options of type OvsDBMap<String,String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[417,19] error: cannot find symbol
    [ERROR] variable options of type OvsDBMap<String,String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF10ProviderManager.java:[418,19] error: cannot find symbol
    [ERROR] variable options of type OvsDBMap<String,String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/SouthboundHandler.java:[117,57] error: incompatible types
    [ERROR] OvsDBSet<UUID>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/SouthboundHandler.java:[165,61] error: incompatible types
    [ERROR] OvsDBSet<UUID>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[155,27] error: bad operand types for binary operator '=='
    [ERROR] <null>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[155,48] error: cannot find symbol
    [ERROR] variable interfaces of type OvsDBSet<UUID>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[161,38] error: cannot find symbol
    [ERROR] variable interfaces of type OvsDBSet<UUID>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[171,15] error: cannot find symbol
    [ERROR] variable options of type OvsDBMap<String,String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[224,53] error: incompatible types
    [ERROR] OvsDBSet<String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/InternalNetworkManager.java:[258,53] error: incompatible types
    [ERROR] OvsDBSet<String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[144,70] error: incompatible types
    [ERROR] OvsDBMap<String,String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[184,62] error: incompatible types
    [ERROR] OvsDBMap<String,String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[209,12] error: cannot find symbol
    [ERROR] variable tags of type OvsDBSet<BigInteger>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[228,53] error: incompatible types
    [ERROR] OvsDBSet<UUID>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[238,53] error: incompatible types
    [ERROR] OvsDBSet<String>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[245,57] error: incompatible types
    [ERROR] OvsDBSet<BigInteger>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/TenantNetworkManager.java:[283,53] error: incompatible types
    [ERROR] OvsDBSet<UUID>
    [ERROR] /home/steven/code/SDN/controller/opendaylight/ovsdb/neutron/src/main/java/org/opendaylight/ovsdb/neutron/AdminConfigManager.java:[117,57] error: incompatible types
    [ERROR] -> [Help 1]
    [ERROR]
    [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
    [ERROR] Re-run Maven using the -X switch to enable full debug logging.
    [ERROR]
    [ERROR] For more information about the errors and possible solutions, please read the following articles:
    [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException

    After checked with pom.xml in ovsdb/neutron, i found that dependency google-collections is missed, by adding this missed piece, it works,
    So i propose a possible patch (in attachment) for this issue. Hopefully, it really help.  And if it is necessary, i can fire a bug for this, than patch it.


Re: api call flow

Madhu Venugopal
 

Hi Hugo,

Thanks for the summary. This sounds a lot like today's Neutron integration.
Neutron gives Network, Subnet and Port creates from Northbound.
And OVS provides the libvirt triggered new VM-Port attached notification via OVSDB.

Our job in the ODL is to correlate these Northbound and Southbound events and program
appropriate entries :
1. Tunnels (GRE, VXLAN,...)
2. Bridges and Patch ports (if missing).
3. Flow programming (Mac-Vlan based or Flood or others).

I think we can generalize these very easily and make the ovsdb.neutron plugin common for
both Openstack and CloudStack. (ofcourse we can change the name or move it under a more
common bundle.

More on IRC & hangouts ;)

Thanks,
-Madhu

On 11/28/13, 1:53 AM, Hugo Trippaers wrote:
Thanks guys! Really appreciate all the help :-)


So the flow from the CloudStack side is pretty much like this:

1. User creates a network
Isolated guest network, meaning internal ip range dedicated for this tennant and a software based router to get traffic to the outside world (NAT, Firewall etc)
2. CloudStack network gurus get asked to allocate the network
Administrative process, make entries in the database
3. One of the gurus decides to handle this call based on set criteria (network isolation method (gre|vxlan|etc), traffic type (guest, management, storage etc))
This is where the Opendaylight guru would answer the call when ODL is the network provider

4. User creates a virtual machine in that network
This triggers the creation of network resources
5. Opendaylight guru is called to implement the network
Allocate and configure all “physical” resources for the network
6. Opendaylight element receives a plug command to plug the VM into the network
This configures all resources for the new port on the network
7. HypervisorResource configures and creates the vm
This configures the VM on the hypervisor
and this creates the vif (on KVM done by libvirt)
8. Happy user goes off and eats pizza


So we have the Guru dealing with the creation of the network, the element deals with preparing ports and the hypervisor resource dealing with the creation of the VIF.

Steps 5, 6 and 7 is where the ODL magic should happen. With my limited understanding of the neutron interface i’m thinking about the following.
In step 5 create network (push the network json object to ODL)
In step 6 i know which hypervisor is involved so tell ODL to create tunnels for this hypervisor to already existing hypervisors if we have any.
In step 7 the vif will be created by libvirt and should be connected using the flows? (Create port in ODL neutron api?)


Hope this makes any sense :-)


Cheers,

Hugo





On 27 nov. 2013, at 17:08, Brent Salisbury <brent.salisbury@...> wrote:

Hi Hugo,

Below are a couple of example Neutron API calls (GRE/VXLAN) that might
help. I have the OVS logs also if that would help. We should have a
Hangout and see how we can help with CLoudStack integration buddy.

You have the team behind you so please don't hesitate it is the least we
can do for as lucky as we are to have you onboard.


============== GRE ==================

2013-11-1903: 59:
06.625INFOneutron.tests.unit.ml2.drivers.mechanism_logger[
-
]update_port_precommitcalledwithportsettings{
'status': 'DOWN',
'binding: host_id': 'fedora2',
'allowed_address_pairs': [
],
'extra_dhcp_opts': [
],
'device_owner': 'network: dhcp',
'fixed_ips': [
{
'subnet_id': 'fdb81e43-744c-4645-9b0e-12088e372a89',
'ip_address': '10.0.0.2'
}
],
'id': '39913bf1-c8e6-4270-a20a-244960b56cd9',
'security_groups': [
],
'device_id':
'dhcp59398d03-bd37-55aa-92f1-91d1c4e8624a-899ba619-8322-4667-9283-ae0d59ffe
89b',
'name': '',
'admin_state_up': True,
'network_id': '899ba619-8322-4667-9283-ae0d59ffe89b',
'tenant_id': '7827e83d1e3a4c86a11fe51867954941',
'binding: vif_type': 'ovs',
'binding: capabilities': {
'port_filter': False
},
'mac_address': 'fa: 16: 3e: f3: 47: b7'
}(originalsettings{
'status': u'DOWN',
'binding: host_id': 'fedora2',
'allowed_address_pairs': [
],
'extra_dhcp_opts': [
],
'device_owner': 'network: dhcp',
'fixed_ips': [
{
'subnet_id': 'fdb81e43-744c-4645-9b0e-12088e372a89',
'ip_address': '10.0.0.2'
}
],
'id': '39913bf1-c8e6-4270-a20a-244960b56cd9',
'security_groups': [
],
'device_id':
'dhcp59398d03-bd37-55aa-92f1-91d1c4e8624a-899ba619-8322-4667-9283-ae0d59ffe
89b',
'name': '',
'admin_state_up': True,
'network_id': '899ba619-8322-4667-9283-ae0d59ffe89b',
'tenant_id': '7827e83d1e3a4c86a11fe51867954941',
'binding: vif_type': 'ovs',
'binding: capabilities': {
'port_filter': False
},
'mac_address': 'fa: 16: 3e: f3: 47: b7'
})onnetwork{
'status': 'ACTIVE',
'subnets': [
'fdb81e43-744c-4645-9b0e-12088e372a89'
],
'name': 'private',
'provider: physical_network': None,
'admin_state_up': True,
'tenant_id': '7827e83d1e3a4c86a11fe51867954941',
'provider: network_type': 'gre',
'router: external': False,
'shared': False,
'id': '899ba619-8322-4667-9283-ae0d59ffe89b',
'provider: segmentation_id': 1L
}


============= VXLAN ===============

{
'_context_roles': [
'admin'
],
'_context_read_deleted': 'no',
'_context_tenant_id': None,
'args': {
'segmentation_id': 1001,
'physical_network': None,
'port': {
'status': 'ACTIVE',
'binding: host_id': 'ryu1',
'name': '',
'allowed_address_pairs': [
],
'admin_state_up': True,
'network_id': 'f291f8a5-41e9-40db-ba84-eeac8285e594',
'tenant_id': '8f9ef230879747d4808ebf376306a46e',
'extra_dhcp_opts': [
],
'binding: vif_type': 'ovs',
'device_owner': 'network: dhcp',
'binding: capabilities': {
'port_filter': True
},
'mac_address': 'fa: 16: 3e: a4: cd: 57',
'fixed_ips': [
{
'subnet_id': '120a7dc9-a8f6-48dd-8136-2caa47d20cca',
'ip_address': '10.0.0.2'
}
],
'id': 'ed8bdd3e-e820-48f5-bfd7-54fa0dac6804',
'security_groups': [
],
'device_id':
'dhcpc3a4ecdf-fd9b-5291-9047-1f9bab5081f6-f291f8a5-41e9-40db-ba84-eeac8285e
594'
},
'network_type': 'vxlan'
},
'namespace': None,
'_unique_id': 'b5fb1a20556a47c6b237c28ab27bfd20',
'_context_is_admin': True,
'version': '1.1',
'_context_project_id': None,
'_context_timestamp': '2013-10-2707: 11: 59.302676',
'_context_user_id': None,
'method': 'port_update'
}

==================================================



Thanks,
-Brent





On 11/27/13 9:57 AM, "Hugo Trippaers" <hugo@...> wrote:

Ok. So it is pretty tightly coupled with the Neutron way of working
right? So we don¹t have generic apis yet that can be used by other
orchestration platforms? Do we have some documentation online on which
networks type to use etc, like a poor mans guide to Neutron southbound?

So i guess i have to get into the neutron way of working to see if that
is applicable to the way i¹m doing networking now in CS. :-)

Cheers,

Hugo

On 27 nov. 2013, at 15:17, Madhu Venguopal <mavenugo@...> wrote:

Hi Hugo,

Since OpenDaylight has atleast 3 Neutron based south-bounds (OVSDB,
OpenDove & VTN), we centralized the Neutron NB-API
on the controller project. And each of the above 3 south-bound plugin
provides common services for handling Network, Subnet and Port events.
You can see all of these under the controller projects :
-> networkconfig.neutron
-> networkconfig.neutron.implementation
-> networkconfig.neutron.northbound

On the OVSDB side, Please take a look @
-> ovsdb.neutron

- NetworkHandler (handles Network creation events)
- PortHandler (VM / Port creation events).

Now, which hypervisors are part of the tenant network is something that
can derive out of the above 2 events and the
centralized cache maintained in the networkconfig.neutron plugin.

BTW, I dont like to maintain caches in OVSDB unless it is strictly
necessary (fearing the caches going out-of-sync and chasing those
problems are nightmare).
So, I depend on events and dont mind CPU cycles to form the picture
every time an event happens.
So, we dont have a DB, that will give the info on all the hypervisors
that are part of a tenant network.
All you get is all the Ports belong to a Network. From the Neutron Port
and the OVSDB Port database, we can derive the
exact set of hypervisors / nodes that make a given tenant network.

Thanks,
Madhu

On 11/27/13, 6:08 AM, Hugo Trippaers wrote:
Hey guys,

Do we have a document describing the call flow between Neutron and
ODL? Would like to use that as a basis to put the same functionality in
CloudStack.

I¹ve already got some of the skeleton work done for the plugin, but
need to start filling in the blanks.

The main thing that i can¹t seem to figure out is how neutron tells
ODL which hypervisors are part of that tenants network and how neutron
creates the OVS nodes.

Cheers,

Hugo
_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev


Re: api call flow

Hugo Trippaers <hugo@...>
 

Thanks guys! Really appreciate all the help :-)


So the flow from the CloudStack side is pretty much like this:

1. User creates a network
Isolated guest network, meaning internal ip range dedicated for this tennant and a software based router to get traffic to the outside world (NAT, Firewall etc)
2. CloudStack network gurus get asked to allocate the network
Administrative process, make entries in the database
3. One of the gurus decides to handle this call based on set criteria (network isolation method (gre|vxlan|etc), traffic type (guest, management, storage etc))
This is where the Opendaylight guru would answer the call when ODL is the network provider

4. User creates a virtual machine in that network
This triggers the creation of network resources
5. Opendaylight guru is called to implement the network
Allocate and configure all “physical” resources for the network
6. Opendaylight element receives a plug command to plug the VM into the network
This configures all resources for the new port on the network
7. HypervisorResource configures and creates the vm
This configures the VM on the hypervisor
and this creates the vif (on KVM done by libvirt)
8. Happy user goes off and eats pizza


So we have the Guru dealing with the creation of the network, the element deals with preparing ports and the hypervisor resource dealing with the creation of the VIF.

Steps 5, 6 and 7 is where the ODL magic should happen. With my limited understanding of the neutron interface i’m thinking about the following.
In step 5 create network (push the network json object to ODL)
In step 6 i know which hypervisor is involved so tell ODL to create tunnels for this hypervisor to already existing hypervisors if we have any.
In step 7 the vif will be created by libvirt and should be connected using the flows? (Create port in ODL neutron api?)


Hope this makes any sense :-)


Cheers,

Hugo

On 27 nov. 2013, at 17:08, Brent Salisbury <brent.salisbury@...> wrote:


Hi Hugo,

Below are a couple of example Neutron API calls (GRE/VXLAN) that might
help. I have the OVS logs also if that would help. We should have a
Hangout and see how we can help with CLoudStack integration buddy.

You have the team behind you so please don't hesitate it is the least we
can do for as lucky as we are to have you onboard.


============== GRE ==================

2013-11-1903: 59:
06.625INFOneutron.tests.unit.ml2.drivers.mechanism_logger[
-
]update_port_precommitcalledwithportsettings{
'status': 'DOWN',
'binding: host_id': 'fedora2',
'allowed_address_pairs': [
],
'extra_dhcp_opts': [
],
'device_owner': 'network: dhcp',
'fixed_ips': [
{
'subnet_id': 'fdb81e43-744c-4645-9b0e-12088e372a89',
'ip_address': '10.0.0.2'
}
],
'id': '39913bf1-c8e6-4270-a20a-244960b56cd9',
'security_groups': [
],
'device_id':
'dhcp59398d03-bd37-55aa-92f1-91d1c4e8624a-899ba619-8322-4667-9283-ae0d59ffe
89b',
'name': '',
'admin_state_up': True,
'network_id': '899ba619-8322-4667-9283-ae0d59ffe89b',
'tenant_id': '7827e83d1e3a4c86a11fe51867954941',
'binding: vif_type': 'ovs',
'binding: capabilities': {
'port_filter': False
},
'mac_address': 'fa: 16: 3e: f3: 47: b7'
}(originalsettings{
'status': u'DOWN',
'binding: host_id': 'fedora2',
'allowed_address_pairs': [
],
'extra_dhcp_opts': [
],
'device_owner': 'network: dhcp',
'fixed_ips': [
{
'subnet_id': 'fdb81e43-744c-4645-9b0e-12088e372a89',
'ip_address': '10.0.0.2'
}
],
'id': '39913bf1-c8e6-4270-a20a-244960b56cd9',
'security_groups': [
],
'device_id':
'dhcp59398d03-bd37-55aa-92f1-91d1c4e8624a-899ba619-8322-4667-9283-ae0d59ffe
89b',
'name': '',
'admin_state_up': True,
'network_id': '899ba619-8322-4667-9283-ae0d59ffe89b',
'tenant_id': '7827e83d1e3a4c86a11fe51867954941',
'binding: vif_type': 'ovs',
'binding: capabilities': {
'port_filter': False
},
'mac_address': 'fa: 16: 3e: f3: 47: b7'
})onnetwork{
'status': 'ACTIVE',
'subnets': [
'fdb81e43-744c-4645-9b0e-12088e372a89'
],
'name': 'private',
'provider: physical_network': None,
'admin_state_up': True,
'tenant_id': '7827e83d1e3a4c86a11fe51867954941',
'provider: network_type': 'gre',
'router: external': False,
'shared': False,
'id': '899ba619-8322-4667-9283-ae0d59ffe89b',
'provider: segmentation_id': 1L
}


============= VXLAN ===============

{
'_context_roles': [
'admin'
],
'_context_read_deleted': 'no',
'_context_tenant_id': None,
'args': {
'segmentation_id': 1001,
'physical_network': None,
'port': {
'status': 'ACTIVE',
'binding: host_id': 'ryu1',
'name': '',
'allowed_address_pairs': [
],
'admin_state_up': True,
'network_id': 'f291f8a5-41e9-40db-ba84-eeac8285e594',
'tenant_id': '8f9ef230879747d4808ebf376306a46e',
'extra_dhcp_opts': [
],
'binding: vif_type': 'ovs',
'device_owner': 'network: dhcp',
'binding: capabilities': {
'port_filter': True
},
'mac_address': 'fa: 16: 3e: a4: cd: 57',
'fixed_ips': [
{
'subnet_id': '120a7dc9-a8f6-48dd-8136-2caa47d20cca',
'ip_address': '10.0.0.2'
}
],
'id': 'ed8bdd3e-e820-48f5-bfd7-54fa0dac6804',
'security_groups': [
],
'device_id':
'dhcpc3a4ecdf-fd9b-5291-9047-1f9bab5081f6-f291f8a5-41e9-40db-ba84-eeac8285e
594'
},
'network_type': 'vxlan'
},
'namespace': None,
'_unique_id': 'b5fb1a20556a47c6b237c28ab27bfd20',
'_context_is_admin': True,
'version': '1.1',
'_context_project_id': None,
'_context_timestamp': '2013-10-2707: 11: 59.302676',
'_context_user_id': None,
'method': 'port_update'
}

==================================================



Thanks,
-Brent





On 11/27/13 9:57 AM, "Hugo Trippaers" <hugo@...> wrote:

Ok. So it is pretty tightly coupled with the Neutron way of working
right? So we don¹t have generic apis yet that can be used by other
orchestration platforms? Do we have some documentation online on which
networks type to use etc, like a poor mans guide to Neutron southbound?

So i guess i have to get into the neutron way of working to see if that
is applicable to the way i¹m doing networking now in CS. :-)

Cheers,

Hugo

On 27 nov. 2013, at 15:17, Madhu Venguopal <mavenugo@...> wrote:

Hi Hugo,

Since OpenDaylight has atleast 3 Neutron based south-bounds (OVSDB,
OpenDove & VTN), we centralized the Neutron NB-API
on the controller project. And each of the above 3 south-bound plugin
provides common services for handling Network, Subnet and Port events.
You can see all of these under the controller projects :
-> networkconfig.neutron
-> networkconfig.neutron.implementation
-> networkconfig.neutron.northbound

On the OVSDB side, Please take a look @
-> ovsdb.neutron

- NetworkHandler (handles Network creation events)
- PortHandler (VM / Port creation events).

Now, which hypervisors are part of the tenant network is something that
can derive out of the above 2 events and the
centralized cache maintained in the networkconfig.neutron plugin.

BTW, I dont like to maintain caches in OVSDB unless it is strictly
necessary (fearing the caches going out-of-sync and chasing those
problems are nightmare).
So, I depend on events and dont mind CPU cycles to form the picture
every time an event happens.
So, we dont have a DB, that will give the info on all the hypervisors
that are part of a tenant network.
All you get is all the Ports belong to a Network. From the Neutron Port
and the OVSDB Port database, we can derive the
exact set of hypervisors / nodes that make a given tenant network.

Thanks,
Madhu

On 11/27/13, 6:08 AM, Hugo Trippaers wrote:
Hey guys,

Do we have a document describing the call flow between Neutron and
ODL? Would like to use that as a basis to put the same functionality in
CloudStack.

I¹ve already got some of the skeleton work done for the plugin, but
need to start filling in the blanks.

The main thing that i can¹t seem to figure out is how neutron tells
ODL which hypervisors are part of that tenants network and how neutron
creates the OVS nodes.

Cheers,

Hugo
_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev


Neutron ML2 OpenDaylight plugin successfully integrated with OVSDB plugin & OF 1.0 for GRE Overlay

Madhu Venugopal
 

Team,

After couple of weeks of integration effort, we finally have a working Multi-node DevStack setup running Fedora 19
with Neutron ML2 opendaylight plugin integrated and working nicely using the OVSDB (for OVS switch management)
and OF 1.0 (for Flow based forwarding). We have started with GRE tunnel overlay as our first integration point.
VXLAN & Vlan integration will follow (and they should be minor effort). [We also seen interest in LISP integration as well].
We are currently waiting on the availability of OF1.3 plugin to improve the scalability of this solution.

Attached is the screenshot for a visual impact ;) and a few captures.
Brent is working on a nice document with step-by-step instructions and ofcourse we will record a few Youtube videos
covering most of the technical details.

This is an excellent team effort with Kyle, Brent, Florian & Ashwin. You guys are amazing !
We also have other OVSDB project members, Keith & Thomas getting up to speed to get plugged in.
Hugo is working on CloudStack integration. Cant wait !!!

Ofcourse this is just the beginning and we have tons of work left on the integration effort and most of them are being tracked
in our project's Trello page : https://trello.com/b/SbPFDkvW/hydrogen-ovsdb under the Neutron integration section.

Please jump in, contribute and enjoy the crazy discussions that happens @ 4AM EST & PT ;)

Happy Thanks Giving .

Thanks,
Madhu


Re: api call flow

Brent Salisbury
 

Hi Hugo,

Below are a couple of example Neutron API calls (GRE/VXLAN) that might
help. I have the OVS logs also if that would help. We should have a
Hangout and see how we can help with CLoudStack integration buddy.

You have the team behind you so please don't hesitate it is the least we
can do for as lucky as we are to have you onboard.


============== GRE ==================

2013-11-1903: 59:
06.625INFOneutron.tests.unit.ml2.drivers.mechanism_logger[
-
]update_port_precommitcalledwithportsettings{
'status': 'DOWN',
'binding: host_id': 'fedora2',
'allowed_address_pairs': [
],
'extra_dhcp_opts': [
],
'device_owner': 'network: dhcp',
'fixed_ips': [
{
'subnet_id': 'fdb81e43-744c-4645-9b0e-12088e372a89',
'ip_address': '10.0.0.2'
}
],
'id': '39913bf1-c8e6-4270-a20a-244960b56cd9',
'security_groups': [
],
'device_id':
'dhcp59398d03-bd37-55aa-92f1-91d1c4e8624a-899ba619-8322-4667-9283-ae0d59ffe
89b',
'name': '',
'admin_state_up': True,
'network_id': '899ba619-8322-4667-9283-ae0d59ffe89b',
'tenant_id': '7827e83d1e3a4c86a11fe51867954941',
'binding: vif_type': 'ovs',
'binding: capabilities': {
'port_filter': False
},
'mac_address': 'fa: 16: 3e: f3: 47: b7'
}(originalsettings{
'status': u'DOWN',
'binding: host_id': 'fedora2',
'allowed_address_pairs': [
],
'extra_dhcp_opts': [
],
'device_owner': 'network: dhcp',
'fixed_ips': [
{
'subnet_id': 'fdb81e43-744c-4645-9b0e-12088e372a89',
'ip_address': '10.0.0.2'
}
],
'id': '39913bf1-c8e6-4270-a20a-244960b56cd9',
'security_groups': [
],
'device_id':
'dhcp59398d03-bd37-55aa-92f1-91d1c4e8624a-899ba619-8322-4667-9283-ae0d59ffe
89b',
'name': '',
'admin_state_up': True,
'network_id': '899ba619-8322-4667-9283-ae0d59ffe89b',
'tenant_id': '7827e83d1e3a4c86a11fe51867954941',
'binding: vif_type': 'ovs',
'binding: capabilities': {
'port_filter': False
},
'mac_address': 'fa: 16: 3e: f3: 47: b7'
})onnetwork{
'status': 'ACTIVE',
'subnets': [
'fdb81e43-744c-4645-9b0e-12088e372a89'
],
'name': 'private',
'provider: physical_network': None,
'admin_state_up': True,
'tenant_id': '7827e83d1e3a4c86a11fe51867954941',
'provider: network_type': 'gre',
'router: external': False,
'shared': False,
'id': '899ba619-8322-4667-9283-ae0d59ffe89b',
'provider: segmentation_id': 1L
}


============= VXLAN ===============

{
'_context_roles': [
'admin'
],
'_context_read_deleted': 'no',
'_context_tenant_id': None,
'args': {
'segmentation_id': 1001,
'physical_network': None,
'port': {
'status': 'ACTIVE',
'binding: host_id': 'ryu1',
'name': '',
'allowed_address_pairs': [
],
'admin_state_up': True,
'network_id': 'f291f8a5-41e9-40db-ba84-eeac8285e594',
'tenant_id': '8f9ef230879747d4808ebf376306a46e',
'extra_dhcp_opts': [
],
'binding: vif_type': 'ovs',
'device_owner': 'network: dhcp',
'binding: capabilities': {
'port_filter': True
},
'mac_address': 'fa: 16: 3e: a4: cd: 57',
'fixed_ips': [
{
'subnet_id': '120a7dc9-a8f6-48dd-8136-2caa47d20cca',
'ip_address': '10.0.0.2'
}
],
'id': 'ed8bdd3e-e820-48f5-bfd7-54fa0dac6804',
'security_groups': [
],
'device_id':
'dhcpc3a4ecdf-fd9b-5291-9047-1f9bab5081f6-f291f8a5-41e9-40db-ba84-eeac8285e
594'
},
'network_type': 'vxlan'
},
'namespace': None,
'_unique_id': 'b5fb1a20556a47c6b237c28ab27bfd20',
'_context_is_admin': True,
'version': '1.1',
'_context_project_id': None,
'_context_timestamp': '2013-10-2707: 11: 59.302676',
'_context_user_id': None,
'method': 'port_update'
}

==================================================



Thanks,
-Brent

On 11/27/13 9:57 AM, "Hugo Trippaers" <hugo@...> wrote:

Ok. So it is pretty tightly coupled with the Neutron way of working
right? So we don¹t have generic apis yet that can be used by other
orchestration platforms? Do we have some documentation online on which
networks type to use etc, like a poor mans guide to Neutron southbound?

So i guess i have to get into the neutron way of working to see if that
is applicable to the way i¹m doing networking now in CS. :-)

Cheers,

Hugo

On 27 nov. 2013, at 15:17, Madhu Venguopal <mavenugo@...> wrote:

Hi Hugo,

Since OpenDaylight has atleast 3 Neutron based south-bounds (OVSDB,
OpenDove & VTN), we centralized the Neutron NB-API
on the controller project. And each of the above 3 south-bound plugin
provides common services for handling Network, Subnet and Port events.
You can see all of these under the controller projects :
-> networkconfig.neutron
-> networkconfig.neutron.implementation
-> networkconfig.neutron.northbound

On the OVSDB side, Please take a look @
-> ovsdb.neutron

- NetworkHandler (handles Network creation events)
- PortHandler (VM / Port creation events).

Now, which hypervisors are part of the tenant network is something that
can derive out of the above 2 events and the
centralized cache maintained in the networkconfig.neutron plugin.

BTW, I dont like to maintain caches in OVSDB unless it is strictly
necessary (fearing the caches going out-of-sync and chasing those
problems are nightmare).
So, I depend on events and dont mind CPU cycles to form the picture
every time an event happens.
So, we dont have a DB, that will give the info on all the hypervisors
that are part of a tenant network.
All you get is all the Ports belong to a Network. From the Neutron Port
and the OVSDB Port database, we can derive the
exact set of hypervisors / nodes that make a given tenant network.

Thanks,
Madhu

On 11/27/13, 6:08 AM, Hugo Trippaers wrote:
Hey guys,

Do we have a document describing the call flow between Neutron and
ODL? Would like to use that as a basis to put the same functionality in
CloudStack.

I¹ve already got some of the skeleton work done for the plugin, but
need to start filling in the blanks.

The main thing that i can¹t seem to figure out is how neutron tells
ODL which hypervisors are part of that tenants network and how neutron
creates the OVS nodes.

Cheers,

Hugo
_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev


Re: api call flow

Madhu Venugopal
 

Hi Hugo,

The neutron NB APIs that you see here :
https://jenkins.opendaylight.org/controller/job/controller-merge/lastSuccessfulBuild/artifact/opendaylight/northbound/networkconfiguration/neutron/target/site/wsdocs/index.html
are almost transparently passed to the Southbound.

For the specific question of network type, it is in the Network NB-API and look for the " provider_network_type"
(Neutron supports GRE, VXLAN, VLAN & internal).

We can discuss more on this over IRC & try and reuse most of the components for CS as well.

Thanks,
Madhu

On 11/27/13, 6:57 AM, Hugo Trippaers wrote:

Ok.  So it is pretty tightly coupled with the Neutron way of working right? So we don’t have generic apis yet that can be used by other orchestration platforms? Do we have some documentation online on which networks type to use etc, like a poor mans guide to Neutron southbound?

So i guess i have to get into the neutron way of working to see if that is applicable to the way i’m doing networking now in CS.  :-)

Cheers,

Hugo

On 27 nov. 2013, at 15:17, Madhu Venguopal <mavenugo@...> wrote:

Hi Hugo,

Since OpenDaylight has atleast 3 Neutron based south-bounds (OVSDB, OpenDove & VTN), we centralized the Neutron NB-API
on the controller project. And each of the above 3 south-bound plugin provides common services for handling Network, Subnet and Port events.
You can see all of these under the controller projects :
-> networkconfig.neutron
-> networkconfig.neutron.implementation
-> networkconfig.neutron.northbound

On the OVSDB side, Please take a look @
-> ovsdb.neutron

- NetworkHandler (handles Network creation events)
- PortHandler (VM / Port creation events).

Now, which hypervisors are part of the tenant network is something that can derive out of the above 2 events and the
centralized cache maintained in the networkconfig.neutron plugin.

BTW, I dont like to maintain caches in OVSDB unless it is strictly necessary (fearing the caches going out-of-sync and chasing those problems are nightmare).
So, I depend on events and dont mind CPU cycles to form the picture every time an event happens.
So, we dont have a DB, that will give the info on all the hypervisors that are part of a tenant network.
All you get is all the Ports belong to a Network. From the Neutron Port and the OVSDB Port database, we can derive the
exact set of hypervisors / nodes that make a given tenant network.

Thanks,
Madhu

On 11/27/13, 6:08 AM, Hugo Trippaers wrote:
Hey guys,

Do we have a document describing the call flow between Neutron and ODL? Would like to use that as a basis to put the same functionality in CloudStack.

I’ve already got some of the skeleton work done for the plugin, but need to start filling in the blanks.

The main thing that i can’t seem to figure out is how neutron tells ODL which hypervisors are part of that tenants network and how neutron creates the OVS nodes.

Cheers,

Hugo
_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev

      

    


Re: api call flow

Hugo Trippaers <hugo@...>
 

Ok. So it is pretty tightly coupled with the Neutron way of working right? So we don’t have generic apis yet that can be used by other orchestration platforms? Do we have some documentation online on which networks type to use etc, like a poor mans guide to Neutron southbound?

So i guess i have to get into the neutron way of working to see if that is applicable to the way i’m doing networking now in CS. :-)

Cheers,

Hugo

On 27 nov. 2013, at 15:17, Madhu Venguopal <mavenugo@...> wrote:

Hi Hugo,

Since OpenDaylight has atleast 3 Neutron based south-bounds (OVSDB, OpenDove & VTN), we centralized the Neutron NB-API
on the controller project. And each of the above 3 south-bound plugin provides common services for handling Network, Subnet and Port events.
You can see all of these under the controller projects :
-> networkconfig.neutron
-> networkconfig.neutron.implementation
-> networkconfig.neutron.northbound

On the OVSDB side, Please take a look @
-> ovsdb.neutron

- NetworkHandler (handles Network creation events)
- PortHandler (VM / Port creation events).

Now, which hypervisors are part of the tenant network is something that can derive out of the above 2 events and the
centralized cache maintained in the networkconfig.neutron plugin.

BTW, I dont like to maintain caches in OVSDB unless it is strictly necessary (fearing the caches going out-of-sync and chasing those problems are nightmare).
So, I depend on events and dont mind CPU cycles to form the picture every time an event happens.
So, we dont have a DB, that will give the info on all the hypervisors that are part of a tenant network.
All you get is all the Ports belong to a Network. From the Neutron Port and the OVSDB Port database, we can derive the
exact set of hypervisors / nodes that make a given tenant network.

Thanks,
Madhu

On 11/27/13, 6:08 AM, Hugo Trippaers wrote:
Hey guys,

Do we have a document describing the call flow between Neutron and ODL? Would like to use that as a basis to put the same functionality in CloudStack.

I’ve already got some of the skeleton work done for the plugin, but need to start filling in the blanks.

The main thing that i can’t seem to figure out is how neutron tells ODL which hypervisors are part of that tenants network and how neutron creates the OVS nodes.

Cheers,

Hugo
_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev


Re: api call flow

Madhu Venugopal
 

Hi Hugo,

Since OpenDaylight has atleast 3 Neutron based south-bounds (OVSDB, OpenDove & VTN), we centralized the Neutron NB-API
on the controller project. And each of the above 3 south-bound plugin provides common services for handling Network, Subnet and Port events.
You can see all of these under the controller projects :
-> networkconfig.neutron
-> networkconfig.neutron.implementation
-> networkconfig.neutron.northbound

On the OVSDB side, Please take a look @
-> ovsdb.neutron

- NetworkHandler (handles Network creation events)
- PortHandler (VM / Port creation events).

Now, which hypervisors are part of the tenant network is something that can derive out of the above 2 events and the
centralized cache maintained in the networkconfig.neutron plugin.

BTW, I dont like to maintain caches in OVSDB unless it is strictly necessary (fearing the caches going out-of-sync and chasing those problems are nightmare).
So, I depend on events and dont mind CPU cycles to form the picture every time an event happens.
So, we dont have a DB, that will give the info on all the hypervisors that are part of a tenant network.
All you get is all the Ports belong to a Network. From the Neutron Port and the OVSDB Port database, we can derive the
exact set of hypervisors / nodes that make a given tenant network.

Thanks,
Madhu

On 11/27/13, 6:08 AM, Hugo Trippaers wrote:
Hey guys,

Do we have a document describing the call flow between Neutron and ODL? Would like to use that as a basis to put the same functionality in CloudStack.

I’ve already got some of the skeleton work done for the plugin, but need to start filling in the blanks.

The main thing that i can’t seem to figure out is how neutron tells ODL which hypervisors are part of that tenants network and how neutron creates the OVS nodes.

Cheers,

Hugo
_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev


api call flow

Hugo Trippaers <hugo@...>
 

Hey guys,

Do we have a document describing the call flow between Neutron and ODL? Would like to use that as a basis to put the same functionality in CloudStack.

I’ve already got some of the skeleton work done for the plugin, but need to start filling in the blanks.

The main thing that i can’t seem to figure out is how neutron tells ODL which hypervisors are part of that tenants network and how neutron creates the OVS nodes.

Cheers,

Hugo


Neutron integration status and next steps / Trello added

Madhu Venugopal
 

Team,

As most of you know already, we made significant progress on the Neutron integration and we will have the OF1.0 based GRE overlay support
completed anytime now. All the corresponding code has been checked in in the ovsdb.neutron plugin. Please check it out.
Though VXLAN and VLAN are just other Tunneling implementations, there is some work involved in that. Also, there are more than
15 Todo items just on the Neutron integration and I have consolidated everything under a new "Neutron Integration To Do" list
and a "Neutron Integration Doing" list based on popular demand.

https://trello.com/b/SbPFDkvW/hydrogen-ovsdb

As always please feel free to pick items of interest and your comfort. Let us all know about what you picked in the IRC channel to avoid duplicated
effort. Please coordinate with other volunteers of a task if there are multiple volunteers for the same card.

Cheers,
Madhu


Re: ##freemail## Re: [controller-dev] How to use the OpenStack Neutron ML2 MechanismDriver with OpenDaylight

Hideyuki Tai <h-tai@...>
 

Hi Thomas,

 

Thank you very much for sharing this information!

I’ll try the patch.

 

Regards,

Hideyuki Tai

 

 

From: Thomas Bachman [mailto:tbachman@...]
Sent: Wednesday, November 27, 2013 12:24 PM
To: Kyle Mestery (kmestery); Tai, Hideyuki
Cc: controller-dev@...; ovsdb-dev@...
Subject: ##freemail## Re: [ovsdb-dev] [controller-dev] How to use the OpenStack Neutron ML2 MechanismDriver with OpenDaylight

 

Hideyuki Tai,

 

I ran into a similar issue, and with Kyle's help, was able to fix it. In the repo Kyle mentioned, there's a file lib/nova.   You want to add the following patch to that file:

 

 

Once I did this, I was able to run stack.sh successfully.

 

cheers,

 

-Thomas Bachman

 

On Thursday, November 21, 2013 9:34 AM, Kyle Mestery (kmestery) <kmestery@...> wrote:

Hi Hideyuki:

Is this a fresh Ubuntu/Fedora box? Do you have a firewall
enabled? Looks like your credentials are wrong. Make sure
you have updated the IP addresses in the localrc file before
running stack.sh.

Thanks,
Kyle

On Nov 21, 2013, at 8:30 AM, Hideyuki Tai <h-tai@...> wrote:

> Hi kyle,

> Thank you for sharing this information!

> I checked out the devstack tree from here.
>    git clone https://github.com/CiscoSystems/devstack.git
> And, setup my local.conf and run stack.sh.
> However, I got the error " ERROR: Unauthorized (HTTP 401)"

> [odp-dev:~/work/devstack] $ ./stack.sh
> (snip)
> ++ ALT_USERNAME=alt_demo
> ++ ALT_TENANT_NAME=alt_demo
> ++ [[ -z '' ]]
> ++ nova flavor-create m1.nano 42 64 0 1
> ERROR: Unauthorized (HTTP 401)
> + clean
> + local r=1
> ++ jobs -p
> + kill
> [odp-dev:~/work/devstack] $

> And I also saw other error messages in output of stack.sh like this:

> ERROR: Invalid OpenStack Nova credentials.

> What am I missing here?

> Regards,
> Hideyuki Tai


> From: controller-dev-bounces@... [mailto:controller-dev-bounces@...] On Behalf Of Kyle Mestery (kmestery)
> Sent: Thursday, November 14, 2013 12:19 PM
> To: controller-dev@...
> Cc: ovsdb-dev@...
> Subject: [controller-dev] How to use the OpenStack Neutron ML2 MechanismDriver with OpenDaylight

> All:

> After returning from the OpenStack Summit in Hong Kong last week, I've spent some time working on the Neutron ML2 MechanismDriver for ODL. The good news is that after plenty of help from Ryan Moats, I've got it working now! Instructions on how to use it are below. The next steps are to integrate this with something which plugs into the NeutronAPIService APIs I'm using in ODL now. For the OVSDB integration efforts there, we will also require some possible API calls to alert ODL about hosts as the come online.

> To test out the plugin (including devstack support), try the following instructions:

> Here are some very brief instructions on using the (fresh off the presses) OpenStack Neutron ML2 MechanismDriver with ODL:

>     • Setup a fresh VM running either Fedora (preferably 19) or Ubuntu (12.04 or newer).
>     • Checkout a devstack tree from here:
>         • git clone https://github.com/CiscoSystems/devstack.git
>         • git checkout opendaylight
>     • Now, setup your local.conf [1] files. This file should go into the root of your devstack directory. You can copy/paste the example below and modify the sections as the next section indicates:
>         • Make the following changes per the example below:
>             • SERVICE_HOST should be the IP of the host you're running devstack on.
>             • In the ml2_odl section, the "url" should have the IP of the host running ODL.
>     • Once modified, now stack:
>         • ./stack.sh
>     • Once this is complete, you should now have a setup which is sending Neutron API requests to ODL.

> NOTE: This assumes you have a working ODL running somewhere.

> The code to look at the OpenDaylight ML2 MechanismDriver is located here:

> https://github.com/CiscoSystems/neutron/tree/odl_ml2

> If you have any questions, please let me know and reach out to me.

> Thanks!
> Kyle

> [1] local.conf file:
> [[local|localrc]]
> LOGFILE=stack.sh.log
> #OFFLINE=True
> RECLONE=yes

> disable_service n-net
> enable_service q-svc
> #enable_service q-agt
> enable_service q-dhcp
> enable_service q-l3
> enable_service q-meta
> enable_service neutron

> # ODL WITH ML2
> #enable_service odl
> Q_PLUGIN=ml2
> #Q_AGENT=
> Q_ML2_PLUGIN_MECHANISM_DRIVERS=opendaylight,logger
> NEUTRON_REPO=https://github.com/CiscoSystems/neutron.git
> NEUTRON_BRANCH=odl_ml2
> Q_HOST=$SERVICE_HOST

> disable_service rabbit
> enable_service qpid

> HOST_NAME=$(hostname)
> SERVICE_HOST_NAME=${HOST_NAME}
> SERVICE_HOST=192.168.56.101

> FLOATING_RANGE=192.168.100.0/24
> MYSQL_HOST=$SERVICE_HOST
> RABBIT_HOST=$SERVICE_HOST
> GLANCE_HOSTPORT=$SERVICE_HOST:9292
> KEYSTONE_AUTH_HOST=$SERVICE_HOST
> KEYSTONE_SERVICE_HOST=$SERVICE_HOST

> MYSQL_PASSWORD=mysql
> RABBIT_PASSWORD=rabbit
> SERVICE_TOKEN=service
> SERVICE_PASSWORD=admin
> ADMIN_PASSWORD=admin

> [[post-config|/etc/neutron/plugins/ml2/ml2_conf.ini]]
> [ml2_odl]
> url=http://192.168.56.1:8080/controller/nb/v2/neutron
> username=admin
> password=admin

_______________________________________________
ovsdb-dev mailing list


https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev


Re: [controller-dev] How to use the OpenStack Neutron ML2 MechanismDriver with OpenDaylight

Thomas Bachman <tbachman@...>
 

Hideyuki Tai,

I ran into a similar issue, and with Kyle's help, was able to fix it. In the repo Kyle mentioned, there's a file lib/nova.   You want to add the following patch to that file:


Once I did this, I was able to run stack.sh successfully.

cheers,

-Thomas Bachman


On Thursday, November 21, 2013 9:34 AM, Kyle Mestery (kmestery) <kmestery@...> wrote:
Hi Hideyuki:

Is this a fresh Ubuntu/Fedora box? Do you have a firewall
enabled? Looks like your credentials are wrong. Make sure
you have updated the IP addresses in the localrc file before
running stack.sh.

Thanks,
Kyle


On Nov 21, 2013, at 8:30 AM, Hideyuki Tai <h-tai@...> wrote:

> Hi kyle,

> Thank you for sharing this information!

> I checked out the devstack tree from here.
>    git clone https://github.com/CiscoSystems/devstack.git
> And, setup my local.conf and run stack.sh.
> However, I got the error " ERROR: Unauthorized (HTTP 401)"

> [odp-dev:~/work/devstack] $ ./stack.sh
> (snip)
> ++ ALT_USERNAME=alt_demo
> ++ ALT_TENANT_NAME=alt_demo
> ++ [[ -z '' ]]
> ++ nova flavor-create m1.nano 42 64 0 1
> ERROR: Unauthorized (HTTP 401)
> + clean
> + local r=1
> ++ jobs -p
> + kill
> [odp-dev:~/work/devstack] $

> And I also saw other error messages in output of stack.sh like this:

> ERROR: Invalid OpenStack Nova credentials.

> What am I missing here?

> Regards,
> Hideyuki Tai


> From: controller-dev-bounces@... [mailto:controller-dev-bounces@...] On Behalf Of Kyle Mestery (kmestery)
> Sent: Thursday, November 14, 2013 12:19 PM
> To: controller-dev@...
> Cc: ovsdb-dev@...
> Subject: [controller-dev] How to use the OpenStack Neutron ML2 MechanismDriver with OpenDaylight

> All:

> After returning from the OpenStack Summit in Hong Kong last week, I've spent some time working on the Neutron ML2 MechanismDriver for ODL. The good news is that after plenty of help from Ryan Moats, I've got it working now! Instructions on how to use it are below. The next steps are to integrate this with something which plugs into the NeutronAPIService APIs I'm using in ODL now. For the OVSDB integration efforts there, we will also require some possible API calls to alert ODL about hosts as the come online.

> To test out the plugin (including devstack support), try the following instructions:

> Here are some very brief instructions on using the (fresh off the presses) OpenStack Neutron ML2 MechanismDriver with ODL:

>     • Setup a fresh VM running either Fedora (preferably 19) or Ubuntu (12.04 or newer).
>     • Checkout a devstack tree from here:
>         • git clone https://github.com/CiscoSystems/devstack.git
>         • git checkout opendaylight
>     • Now, setup your local.conf [1] files. This file should go into the root of your devstack directory. You can copy/paste the example below and modify the sections as the next section indicates:
>         • Make the following changes per the example below:
>             • SERVICE_HOST should be the IP of the host you're running devstack on.
>             • In the ml2_odl section, the "url" should have the IP of the host running ODL.
>     • Once modified, now stack:
>         • ./stack.sh
>     • Once this is complete, you should now have a setup which is sending Neutron API requests to ODL.

> NOTE: This assumes you have a working ODL running somewhere.

> The code to look at the OpenDaylight ML2 MechanismDriver is located here:

> https://github.com/CiscoSystems/neutron/tree/odl_ml2

> If you have any questions, please let me know and reach out to me.

> Thanks!
> Kyle

> [1] local.conf file:
> [[local|localrc]]
> LOGFILE=stack.sh.log
> #OFFLINE=True
> RECLONE=yes

> disable_service n-net
> enable_service q-svc
> #enable_service q-agt
> enable_service q-dhcp
> enable_service q-l3
> enable_service q-meta
> enable_service neutron

> # ODL WITH ML2
> #enable_service odl
> Q_PLUGIN=ml2
> #Q_AGENT=
> Q_ML2_PLUGIN_MECHANISM_DRIVERS=opendaylight,logger
> NEUTRON_REPO=https://github.com/CiscoSystems/neutron.git
> NEUTRON_BRANCH=odl_ml2
> Q_HOST=$SERVICE_HOST

> disable_service rabbit
> enable_service qpid

> HOST_NAME=$(hostname)
> SERVICE_HOST_NAME=${HOST_NAME}
> SERVICE_HOST=192.168.56.101

> FLOATING_RANGE=192.168.100.0/24
> MYSQL_HOST=$SERVICE_HOST
> RABBIT_HOST=$SERVICE_HOST
> GLANCE_HOSTPORT=$SERVICE_HOST:9292
> KEYSTONE_AUTH_HOST=$SERVICE_HOST
> KEYSTONE_SERVICE_HOST=$SERVICE_HOST

> MYSQL_PASSWORD=mysql
> RABBIT_PASSWORD=rabbit
> SERVICE_TOKEN=service
> SERVICE_PASSWORD=admin
> ADMIN_PASSWORD=admin

> [[post-config|/etc/neutron/plugins/ml2/ml2_conf.ini]]
> [ml2_odl]
> url=http://192.168.56.1:8080/controller/nb/v2/neutron
> username=admin
> password=admin

_______________________________________________
ovsdb-dev mailing list
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev


Re: [OpenDaylight Discuss] Virtuailization addition and affinity service

Suchi Raman <suchi.raman@...>
 

Anees and Benny,

No disagreements with earlier discussions. Affinity abstraction is a high level API that specifies the network path requirements (policy, connectivity, ...) for a set of endpoints. Endpoints may correspond to an application or represent some traffic. The affinity implementation will not assume openflow on the southbound side. 

As for enforcement -- who enforces what and when -- we will use notifications from affinity manager, so that VTN/Dove may reprogram their networks when configuration changes. 

VTN is openflow-based and offers filtering and redirection services natively within each "virtual network" (slice), so the data path for these affinities -- path redirect and access control affinities -- for a VTN-managed network is a direct translation. Translation with Dove may be more involved. I think programming a mixed network (VTN + dove) has other challenges as well that may need to be resolved centrally, but as you say let's table this for later. 

Suchi



On Mon, Nov 25, 2013 at 3:02 PM, Benny Rochwerger <BennyR@...> wrote:
Anees,

In that case I remove my disagreement, however from our point of view it is the affinity service that is providing the abstraction and the enforcement, whether affinity touches the network directly or thru a network virtualization layer  should  transparent  applications the network abstraction API (I.e. affinity in our case)

Benny

Anees A Shaikh <aashaikh@...> wrote:


Benny, your last sentence is what I am getting at -- so I don't think
there is any disagreement.  I'm not arguing that we don't need network
abstractions separate from network virtualization.  And I agree that
affinity and other services could apply beyond the virtualization edition.

But in the context of the virtualization edition, we have implementations
managing the network.  Affinity and other such services should be
providing information about user intent to these implementations -- not
providing their own manipulation of the network, which we've seen
interferes with what the network virtualization services are trying to do.

thanks.

-- Anees

Benny Rochwerger <BennyR@...> wrote on 11/25/2013 02:46:42 AM:

> From: Benny Rochwerger <BennyR@...>
> To: Anees A Shaikh/Watson/IBM@IBMUS,
> "discuss@..." <discuss@...>,
> Cc: "<affinity-dev@...>" <affinity-
> dev@...>, "ovsdb-dev@..."
> <ovsdb-dev@...>, "opendove-
> dev@..." <opendove-dev@...>,
> "<vtn-dev@...>" <vtn-dev@...>
> Date: 11/25/2013 02:47 AM
> Subject: RE: [OpenDaylight Discuss] Virtuailization addition and
> affinity service
>
> Anees,
>
> I have to disagree with you on the need for the Affinity Service to
> touch the network. Yes, we do not need yet another virtualization
> implementation, but this is not about virtualization is about
> abstraction. As you may recall in the original Defense4All proposal
> we talked about the need to have controller services that provide an
> abstraction of the network and give higher level applications (L4-7,
> Security) the capability of monitoring and controlling the network
> without needing to fully understand the L2-3 topology. These is what
> at the time we called the "Traffic Redirection" and "Statistics
> Collection" services.   After presenting our requirements, we were
> told that these type of network abstraction services is exactly with
> Affinity is all about and after a few discussions with the Affinity
> team we agreed that with some minor changes (mainly syntactic) we
> can rely on Affinity to do the low level network control for us (the
> slide set that describes these changes is attached).
>
> The need for a network abstraction is orthogonal to network
> virtualization, our application for example works both in physical
> networks and in virtualized networks (in fact all the deployed PoCs
> we have up to now are physical), so it will be wrong in my opinion
> to look at something like affinity only in the context of virtual
> networks. Having said that, I do believe that when virtual network
> are deployed, affinity (or similar) should leverage the network
> virtualization service, i.e., in that case instead of touching the
> network directly it should ask the network virtulization to do it.
>
> Benny
>
> -----Original Message-----
> From: discuss-bounces@... [mailto:discuss-
> bounces@...] On Behalf Of Anees A Shaikh
> Sent: Saturday, November 23, 2013 5:05 PM
> To: discuss@...
> Cc: <affinity-dev@...>; ovsdb-
> dev@...; opendove-dev@...;
> <vtn-dev@...>
> Subject: [OpenDaylight Discuss] Virtuailization addition and affinity
service
>
> Unfortunately, I couldn't attend the last TSC call where the issue
> of conflicting services in the virtualization edition was discussed
further.
> But in reading Dave's notes, it seems there was some expectation
> that the current approach would need to be revisited: "big piece of
> post-release work to do on finding the proper abstractions under
> which all three projects can complement each other", referring to
> VTN/OpenDOVE/Affinity.
>
> While we may need a way to support multiple virtualization
> implementations simultaneously, this problem applies to the current
> VTN/OpenDOVE/OVSDB projects and not the affinity project in my view.
> Affinity metadata service should never conflict with any of these
> implementations, because it provides a database of user-specified
> affinities / policies, not an additional virtualization
> implementation -- i.e., it should not touch the network (unless its
> scope is changing significantly).
>
> If folks from these projects, have a different view, let's discuss it
further.
>
> thanks.
>
> -- Anees
>
> _______________________________________________
> Discuss mailing list
> Discuss@...
> https://lists.opendaylight.org/mailman/listinfo/discuss
> [attachment "Defense4All Proposal Overview - 130903 - Plexxi.pdf"
> deleted by Anees A Shaikh/Watson/IBM]

_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss


Re: [integration-dev] OVSDB system test

Brent Salisbury
 

That’s awesome, thanks Luis. We were thinking about keeping a running collection in a directory in the project so this is much appreciated.

Thanks,
-Brent


From: Luis Gomez <luis.gomez@...>
Date: Monday, November 25, 2013 9:09 PM
To: brent <brent.salisbury@...>, Madhu Venugopal <mavenugo@...>, "ovsdb-dev@..." <ovsdb-dev@...>, Aswin Nair <aswinnair@...>
Cc: "'integration-dev@...'" <integration-dev@...>
Subject: RE: [integration-dev] [ovsdb-dev] OVSDB system test

Hi Brent, here is the collection I created for system test:

 

https://www.getpostman.com/collections/cb05d301b45c5b8a0554

 

BR/Luis

 

 

From: Brent Salisbury [mailto:brent.salisbury@...]
Sent: Monday, November 25, 2013 2:46 PM
To: Madhu Venguopal; Luis Gomez; ovsdb-dev@...; Aswin Nair
Cc: 'integration-dev@...'
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test

 

Luis, you are the man buddy. We will get you more docs and functions in coming days sir.

 

Thanks,

-Brent

 

 

From: Madhu Venugopal <mavenugo@...>
Date: Monday, November 25, 2013 5:43 PM
To: Luis Gomez <luis.gomez@...>, brent <brent.salisbury@...>, "ovsdb-dev@..." <ovsdb-dev@...>
Cc: "'integration-dev@...'" <integration-dev@...>
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test

 


Excellent. Thanks Luis.

Thanks,
Madhu

On 11/25/13, 1:02 PM, Luis Gomez wrote:

OK, thanks to the Postman examples I have the system test nailed down with the steps below:

 

- Configure mininet in passive mode (sudo ovs-vsctl set-manager ptcp:6640)

- Start mininet with topology tree,2 (the standard we use in system test): h1,h2 – s2 – s1 – s3 – h3,h4

- Controller connects to OVS node in mininet VM

- We create a new bridge s4

- We delete s1 ports s1-eth1 and s1-eth2

- We add s4 ports s4-eth1 and s4-eth2 replacing s1 connections

- We delete s1

- We ping and everything works!

So the test will fully replace switch s1 by new switch s4.

 

Thanks very much for your support.

 

BR/Luis

 

 

 

From: Madhu Venguopal [mailto:mavenugo@...]
Sent: Sunday, November 24, 2013 10:39 PM
To: Luis Gomez; Brent Salisbury; ovsdb-dev@...
Cc: 'integration-dev@...'
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test

 

Hi Luis,

Exactly. The correct solution is to identify the appropriate Controller-ip-address to set based on the reachability information
towards the switch via OVSDB. And as Brent suggested, this is work in progress.

Please use the config.ini in the meanwhile.

I will also add some points later to Brent's on the original email.

Thanks,
Madhu

On 11/24/13, 10:25 PM, Luis Gomez wrote:

Hi Brent,

 

Thanks for your quick answer. I will try the examples from Postman and let you know. For the question about which controller IP should be configured in the OVS bridge, I still think ideally it should be the IP address of the interface the controller uses to reach the OVS node, this is to be consistent with the idea of sending and receiving on the same interface. But maybe this is difficult to code and in that case the config.ini file seems a good workaround as well.

 

BR/Luis

 

 

From: Brent Salisbury [mailto:brent.salisbury@...]
Sent: Sunday, November 24, 2013 8:49 PM
To: Luis Gomez; ovsdb-dev@...
Cc: 'integration-dev@...'
Subject: Re: [ovsdb-dev] OVSDB system test

 

Hi Luis,

 

Thanks so much for the feedback, this is really awesome! I threw in some thoughts, Im sure the others have additional input due to their better knowledge of the core controller but here are some starters.

 

Since we automatically connect the OVS bridge instance to the controller we currently add all of the interfaces on the controller to the set-controller target until we decided the best way to tackle this. We just chatted about this in IRC (#opendaylight-ovsdb) over the weekend and we concluded a reasonable plan is to choose the interface on the controller containing the hosts default route and set the default target to that iface for each OVS bridge. It is on my list to code this evening so it will be patched shortly. The other would be a behavior if there was not a default route on the interface. It will likely be a random choice at that point since as you pointed out it gets very squirrely with multiples :) Please let us know if you have any other suggestions.

 

- In the meantime we have recommended explicitly setting the interface to bind in the config.ini file.

 

### config.ini path/location ###

distribution/opendaylight/target/distribution.opendaylight-osgipackage/opendaylight/configuration/config.ini

### config.ini file ###

# Open Flow related system parameters

# TCP port on which the controller is listening (default 6633)

# of.listenPort=6633

# IP address of the controller (default: wild card)  <== Uncomment and add the desired address for socket binding.

# of.address = 

 

--Adjust that entry to an address you can bind to your host:

### config.ini file ###

of.address = 172.16.58.1 <==  I need to test this and see if it will accept a list also. 

 

2. The following methods for example are wired from the IPluginInBridgeDomainConfigService. Modifying ports/bridges is still yet to be implemented. I was looking at it last night and 

 

        help.append("---OVSDB CLI---\n");

        help.append("\t ovsconnect <ConnectionName> <ip-address>                        - Connect to OVSDB\n");

        help.append("\t addBridge <Node> <BridgeName>                                   - Add Bridge\n");

        help.append("\t getBridgeDomains <Node>                                         - Get Bridges\n");

        help.append("\t deleteBridgeDomain <Node> <BridgeName>                          - Delete a Bridge\n");

        help.append("\t addPort <Node> <BridgeName> <PortName> <type> <options pairs>   - Add Port\n");

        help.append("\t deletePort <Node> <BridgeName> <PortName>                       - Delete Port\n");

        help.append("\t addPortVlan <Node> <BridgeName> <PortName> <vlan>               - Add Port, Vlan\n");

        help.append("\t addTunnel <Node> <Bridge> <Port> <tunnel-type> <remote-ip>      - Add Tunnel\n");

        help.append("          printCache <Node>   

 

- On the configuration options we need to hash them out on how to match OVSDB specific or attributes not addressed by the ConfigConstants enum. Just putting them all into a CUSTOM object is sort of cantankerous. But I have not had a chance to get advice on this from the team. For example probably a bad idea but just pseudo code:

 

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getController());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getDatapath_id());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getExternal_ids());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getFail_mode());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getOther_config());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getPorts());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getStatus());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getStp_enable());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getDatapath_type());

 

3. Thanks a bunch for pointing out the page. I just updated the Postman collection. I also linked a screen capture below to how it looks in the raw postman view. We will work on more documentation in coming days.

 

 

- Its ironic you mentioned the get ports for a given bridge. I coded list bridges for the "NodeConnector" method last night thinking it was just that. But then I asked Madhu and got clarity that the method is in fact for listing the connection between two nodes (per javadoc: Returns a NodeConnector mapped to a Port (if available) that is created using addPort). So maybe the best route is to just list them in the 

 

- I am also a bit confused on the method getBridgeDomainNode.  The Javadoc for getBridgeDomainNode says "Returns a Node dedicated to a Bridge Domain (if available) that is created using createBridgeDomain.". I could probably think of a couple of things that could be but clarity on datapath, logical isolation and what not would help.

 

- Please let me know if you have any time this week to review some more of this and it would be great if you had a little time to walk through some of your questions or potential issues you see with us. It is super helpful for us being heads down in code to get such awesome feedback from you!

 

Regards,

-Brent

 

 

From: Luis Gomez <luis.gomez@...>
Date: Sunday, November 24, 2013 10:40 PM
To: "ovsdb-dev@..." <ovsdb-dev@...>
Cc: "'integration-dev@...'" <integration-dev@...>
Subject: [ovsdb-dev] OVSDB system test

 

Hi folks,

 

Just started writing system test plan for OVSDB and I found one issue, one possible improvement and one general question.

 

1) Lets starts with the issue: with a controller with 2 IP interfaces (like the one we use for system test) connected to mininet OVS switch in passive mode (sudo ovs-vsctl set-manager ptcp:6640), when I add a bridge using:

 

POST http://10.125.136.52:8080/controller/nb/v2/networkconfig/bridgedomain/bridge/OVS/MINI1/s3

 

this one gets configured with the 2 IP addresses of the controller:

 

    Bridge "s3"

        Controller "tcp:10.125.136.38:6633"

        Controller "tcp:10.125.136.52:6633"

            is_connected: true

        Port "s3"

            Interface "s3"

                type: internal

 

and this generates some instability in the controller (it adds and deletes the switch all the time):

 

2013-11-24 18:49:17.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 is connected to the Controller

2013-11-24 18:49:17.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:17.896 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:17.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 is connected to the Controller

2013-11-24 18:49:18.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.898 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:18.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33820 is connected to the Controller

2013-11-24 18:49:19.893 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33820 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.894 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:19.896 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

…..

 

And same behavior is observed when I start mininet with “sudo mn --controller=remote,ip=10.125.136.52 --topo linear,2” and then I make the connection to the OVS switch: both OF switches try to connect to both controller interfaces.

 

The solution would be to configure only the IP of the controller that is used (by linux routing) to reach the mininet VM? In this example 10.125.136.52.

 

Also this is not a strange scenario, I think the controller in a normal deployment will have at least 2 interfaces (operation and traffic) so it is good to fix this behavior.

 

 

2) The improvement is on the BridgeDomain NB API, if Ilook at the different methods available: I can add (POST) and remove (DELETE) bridge and ports configuration, but I do not see any method to list (GET) bridge/configuration. It would be nice to get a view of the bridge/port configuration from the controller NB.

 

 

3) And finally the question: The BridgeDomain POST method has a request body that it says it is documented under wiki.opendaylight.org project pages https://wiki.opendaylight.org/view/OVSDB_Integration:Mininet_OVSDB_Tutorial, however this page is not yet finished. Can you please share some examples of custom values for this field?

 

 

Thanks/Luis

 

_______________________________________________ ovsdb-dev mailing list ovsdb-dev@...https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev





_______________________________________________
integration-dev mailing list
integration-dev@...
https://lists.opendaylight.org/mailman/listinfo/integration-dev

 

 


Re: [integration-dev] OVSDB system test

Luis Gomez <luis.gomez@...>
 

Hi Brent, here is the collection I created for system test:

 

https://www.getpostman.com/collections/cb05d301b45c5b8a0554

 

BR/Luis

 

 

From: Brent Salisbury [mailto:brent.salisbury@...]
Sent: Monday, November 25, 2013 2:46 PM
To: Madhu Venguopal; Luis Gomez; ovsdb-dev@...; Aswin Nair
Cc: 'integration-dev@...'
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test

 

Luis, you are the man buddy. We will get you more docs and functions in coming days sir.

 

Thanks,

-Brent

 

 

From: Madhu Venugopal <mavenugo@...>
Date: Monday, November 25, 2013 5:43 PM
To: Luis Gomez <luis.gomez@...>, brent <brent.salisbury@...>, "ovsdb-dev@..." <ovsdb-dev@...>
Cc: "'integration-dev@...'" <integration-dev@...>
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test

 


Excellent. Thanks Luis.

Thanks,
Madhu

On 11/25/13, 1:02 PM, Luis Gomez wrote:

OK, thanks to the Postman examples I have the system test nailed down with the steps below:

 

- Configure mininet in passive mode (sudo ovs-vsctl set-manager ptcp:6640)

- Start mininet with topology tree,2 (the standard we use in system test): h1,h2 – s2 – s1 – s3 – h3,h4

- Controller connects to OVS node in mininet VM

- We create a new bridge s4

- We delete s1 ports s1-eth1 and s1-eth2

- We add s4 ports s4-eth1 and s4-eth2 replacing s1 connections

- We delete s1

- We ping and everything works!

So the test will fully replace switch s1 by new switch s4.

 

Thanks very much for your support.

 

BR/Luis

 

 

 

From: Madhu Venguopal [mailto:mavenugo@...]
Sent: Sunday, November 24, 2013 10:39 PM
To: Luis Gomez; Brent Salisbury; ovsdb-dev@...
Cc: 'integration-dev@...'
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test

 

Hi Luis,

Exactly. The correct solution is to identify the appropriate Controller-ip-address to set based on the reachability information
towards the switch via OVSDB. And as Brent suggested, this is work in progress.

Please use the config.ini in the meanwhile.

I will also add some points later to Brent's on the original email.

Thanks,
Madhu

On 11/24/13, 10:25 PM, Luis Gomez wrote:

Hi Brent,

 

Thanks for your quick answer. I will try the examples from Postman and let you know. For the question about which controller IP should be configured in the OVS bridge, I still think ideally it should be the IP address of the interface the controller uses to reach the OVS node, this is to be consistent with the idea of sending and receiving on the same interface. But maybe this is difficult to code and in that case the config.ini file seems a good workaround as well.

 

BR/Luis

 

 

From: Brent Salisbury [mailto:brent.salisbury@...]
Sent: Sunday, November 24, 2013 8:49 PM
To: Luis Gomez; ovsdb-dev@...
Cc: 'integration-dev@...'
Subject: Re: [ovsdb-dev] OVSDB system test

 

Hi Luis,

 

Thanks so much for the feedback, this is really awesome! I threw in some thoughts, Im sure the others have additional input due to their better knowledge of the core controller but here are some starters.

 

Since we automatically connect the OVS bridge instance to the controller we currently add all of the interfaces on the controller to the set-controller target until we decided the best way to tackle this. We just chatted about this in IRC (#opendaylight-ovsdb) over the weekend and we concluded a reasonable plan is to choose the interface on the controller containing the hosts default route and set the default target to that iface for each OVS bridge. It is on my list to code this evening so it will be patched shortly. The other would be a behavior if there was not a default route on the interface. It will likely be a random choice at that point since as you pointed out it gets very squirrely with multiples :) Please let us know if you have any other suggestions.

 

- In the meantime we have recommended explicitly setting the interface to bind in the config.ini file.

 

### config.ini path/location ###

distribution/opendaylight/target/distribution.opendaylight-osgipackage/opendaylight/configuration/config.ini

### config.ini file ###

# Open Flow related system parameters

# TCP port on which the controller is listening (default 6633)

# of.listenPort=6633

# IP address of the controller (default: wild card)  <== Uncomment and add the desired address for socket binding.

# of.address = 

 

--Adjust that entry to an address you can bind to your host:

### config.ini file ###

of.address = 172.16.58.1 <==  I need to test this and see if it will accept a list also. 

 

2. The following methods for example are wired from the IPluginInBridgeDomainConfigService. Modifying ports/bridges is still yet to be implemented. I was looking at it last night and 

 

        help.append("---OVSDB CLI---\n");

        help.append("\t ovsconnect <ConnectionName> <ip-address>                        - Connect to OVSDB\n");

        help.append("\t addBridge <Node> <BridgeName>                                   - Add Bridge\n");

        help.append("\t getBridgeDomains <Node>                                         - Get Bridges\n");

        help.append("\t deleteBridgeDomain <Node> <BridgeName>                          - Delete a Bridge\n");

        help.append("\t addPort <Node> <BridgeName> <PortName> <type> <options pairs>   - Add Port\n");

        help.append("\t deletePort <Node> <BridgeName> <PortName>                       - Delete Port\n");

        help.append("\t addPortVlan <Node> <BridgeName> <PortName> <vlan>               - Add Port, Vlan\n");

        help.append("\t addTunnel <Node> <Bridge> <Port> <tunnel-type> <remote-ip>      - Add Tunnel\n");

        help.append("          printCache <Node>   

 

- On the configuration options we need to hash them out on how to match OVSDB specific or attributes not addressed by the ConfigConstants enum. Just putting them all into a CUSTOM object is sort of cantankerous. But I have not had a chance to get advice on this from the team. For example probably a bad idea but just pseudo code:

 

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getController());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getDatapath_id());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getExternal_ids());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getFail_mode());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getOther_config());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getPorts());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getStatus());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getStp_enable());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getDatapath_type());

 

3. Thanks a bunch for pointing out the page. I just updated the Postman collection. I also linked a screen capture below to how it looks in the raw postman view. We will work on more documentation in coming days.

 

 

- Its ironic you mentioned the get ports for a given bridge. I coded list bridges for the "NodeConnector" method last night thinking it was just that. But then I asked Madhu and got clarity that the method is in fact for listing the connection between two nodes (per javadoc: Returns a NodeConnector mapped to a Port (if available) that is created using addPort). So maybe the best route is to just list them in the 

 

- I am also a bit confused on the method getBridgeDomainNode.  The Javadoc for getBridgeDomainNode says "Returns a Node dedicated to a Bridge Domain (if available) that is created using createBridgeDomain.". I could probably think of a couple of things that could be but clarity on datapath, logical isolation and what not would help.

 

- Please let me know if you have any time this week to review some more of this and it would be great if you had a little time to walk through some of your questions or potential issues you see with us. It is super helpful for us being heads down in code to get such awesome feedback from you!

 

Regards,

-Brent

 

 

From: Luis Gomez <luis.gomez@...>
Date: Sunday, November 24, 2013 10:40 PM
To: "ovsdb-dev@..." <ovsdb-dev@...>
Cc: "'integration-dev@...'" <integration-dev@...>
Subject: [ovsdb-dev] OVSDB system test

 

Hi folks,

 

Just started writing system test plan for OVSDB and I found one issue, one possible improvement and one general question.

 

1) Lets starts with the issue: with a controller with 2 IP interfaces (like the one we use for system test) connected to mininet OVS switch in passive mode (sudo ovs-vsctl set-manager ptcp:6640), when I add a bridge using:

 

POST http://10.125.136.52:8080/controller/nb/v2/networkconfig/bridgedomain/bridge/OVS/MINI1/s3

 

this one gets configured with the 2 IP addresses of the controller:

 

    Bridge "s3"

        Controller "tcp:10.125.136.38:6633"

        Controller "tcp:10.125.136.52:6633"

            is_connected: true

        Port "s3"

            Interface "s3"

                type: internal

 

and this generates some instability in the controller (it adds and deletes the switch all the time):

 

2013-11-24 18:49:17.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 is connected to the Controller

2013-11-24 18:49:17.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:17.896 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:17.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 is connected to the Controller

2013-11-24 18:49:18.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.898 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:18.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33820 is connected to the Controller

2013-11-24 18:49:19.893 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33820 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.894 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:19.896 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

…..

 

And same behavior is observed when I start mininet with “sudo mn --controller=remote,ip=10.125.136.52 --topo linear,2” and then I make the connection to the OVS switch: both OF switches try to connect to both controller interfaces.

 

The solution would be to configure only the IP of the controller that is used (by linux routing) to reach the mininet VM? In this example 10.125.136.52.

 

Also this is not a strange scenario, I think the controller in a normal deployment will have at least 2 interfaces (operation and traffic) so it is good to fix this behavior.

 

 

2) The improvement is on the BridgeDomain NB API, if Ilook at the different methods available: I can add (POST) and remove (DELETE) bridge and ports configuration, but I do not see any method to list (GET) bridge/configuration. It would be nice to get a view of the bridge/port configuration from the controller NB.

 

 

3) And finally the question: The BridgeDomain POST method has a request body that it says it is documented under wiki.opendaylight.org project pages https://wiki.opendaylight.org/view/OVSDB_Integration:Mininet_OVSDB_Tutorial, however this page is not yet finished. Can you please share some examples of custom values for this field?

 

 

Thanks/Luis

 

_______________________________________________ ovsdb-dev mailing list ovsdb-dev@... https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev





_______________________________________________
integration-dev mailing list
integration-dev@...
https://lists.opendaylight.org/mailman/listinfo/integration-dev

 

 


Re: [integration-dev] OVSDB system test

Luis Gomez <luis.gomez@...>
 

Sorry again, it does actually work, I just remembered the patches have to be bidirectional!

 

 

From: integration-dev-bounces@... [mailto:integration-dev-bounces@...] On Behalf Of Luis Gomez
Sent: Monday, November 25, 2013 5:45 PM
To: Brent Salisbury; Madhu Venguopal; ovsdb-dev@...; Aswin Nair
Cc: 'integration-dev@...'
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test

 

Actually I was too fast on the test cases, the ping after replacing one switch by another does not work but I think it is an issue in simple forwarding app. Have you also seen this behavior?

 

BR/Luis

 

 

From: Brent Salisbury [mailto:brent.salisbury@...]
Sent: Monday, November 25, 2013 2:46 PM
To: Madhu Venguopal; Luis Gomez; ovsdb-dev@...; Aswin Nair
Cc: 'integration-dev@...'
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test

 

Luis, you are the man buddy. We will get you more docs and functions in coming days sir.

 

Thanks,

-Brent

 

 

From: Madhu Venugopal <mavenugo@...>
Date: Monday, November 25, 2013 5:43 PM
To: Luis Gomez <luis.gomez@...>, brent <brent.salisbury@...>, "ovsdb-dev@..." <ovsdb-dev@...>
Cc: "'integration-dev@...'" <integration-dev@...>
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test

 


Excellent. Thanks Luis.

Thanks,
Madhu

On 11/25/13, 1:02 PM, Luis Gomez wrote:

OK, thanks to the Postman examples I have the system test nailed down with the steps below:

 

- Configure mininet in passive mode (sudo ovs-vsctl set-manager ptcp:6640)

- Start mininet with topology tree,2 (the standard we use in system test): h1,h2 – s2 – s1 – s3 – h3,h4

- Controller connects to OVS node in mininet VM

- We create a new bridge s4

- We delete s1 ports s1-eth1 and s1-eth2

- We add s4 ports s4-eth1 and s4-eth2 replacing s1 connections

- We delete s1

- We ping and everything works!

So the test will fully replace switch s1 by new switch s4.

 

Thanks very much for your support.

 

BR/Luis

 

 

 

From: Madhu Venguopal [mailto:mavenugo@...]
Sent: Sunday, November 24, 2013 10:39 PM
To: Luis Gomez; Brent Salisbury; ovsdb-dev@...
Cc: 'integration-dev@...'
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test

 

Hi Luis,

Exactly. The correct solution is to identify the appropriate Controller-ip-address to set based on the reachability information
towards the switch via OVSDB. And as Brent suggested, this is work in progress.

Please use the config.ini in the meanwhile.

I will also add some points later to Brent's on the original email.

Thanks,
Madhu

On 11/24/13, 10:25 PM, Luis Gomez wrote:

Hi Brent,

 

Thanks for your quick answer. I will try the examples from Postman and let you know. For the question about which controller IP should be configured in the OVS bridge, I still think ideally it should be the IP address of the interface the controller uses to reach the OVS node, this is to be consistent with the idea of sending and receiving on the same interface. But maybe this is difficult to code and in that case the config.ini file seems a good workaround as well.

 

BR/Luis

 

 

From: Brent Salisbury [mailto:brent.salisbury@...]
Sent: Sunday, November 24, 2013 8:49 PM
To: Luis Gomez; ovsdb-dev@...
Cc: 'integration-dev@...'
Subject: Re: [ovsdb-dev] OVSDB system test

 

Hi Luis,

 

Thanks so much for the feedback, this is really awesome! I threw in some thoughts, Im sure the others have additional input due to their better knowledge of the core controller but here are some starters.

 

Since we automatically connect the OVS bridge instance to the controller we currently add all of the interfaces on the controller to the set-controller target until we decided the best way to tackle this. We just chatted about this in IRC (#opendaylight-ovsdb) over the weekend and we concluded a reasonable plan is to choose the interface on the controller containing the hosts default route and set the default target to that iface for each OVS bridge. It is on my list to code this evening so it will be patched shortly. The other would be a behavior if there was not a default route on the interface. It will likely be a random choice at that point since as you pointed out it gets very squirrely with multiples :) Please let us know if you have any other suggestions.

 

- In the meantime we have recommended explicitly setting the interface to bind in the config.ini file.

 

### config.ini path/location ###

distribution/opendaylight/target/distribution.opendaylight-osgipackage/opendaylight/configuration/config.ini

### config.ini file ###

# Open Flow related system parameters

# TCP port on which the controller is listening (default 6633)

# of.listenPort=6633

# IP address of the controller (default: wild card)  <== Uncomment and add the desired address for socket binding.

# of.address = 

 

--Adjust that entry to an address you can bind to your host:

### config.ini file ###

of.address = 172.16.58.1 <==  I need to test this and see if it will accept a list also. 

 

2. The following methods for example are wired from the IPluginInBridgeDomainConfigService. Modifying ports/bridges is still yet to be implemented. I was looking at it last night and 

 

        help.append("---OVSDB CLI---\n");

        help.append("\t ovsconnect <ConnectionName> <ip-address>                        - Connect to OVSDB\n");

        help.append("\t addBridge <Node> <BridgeName>                                   - Add Bridge\n");

        help.append("\t getBridgeDomains <Node>                                         - Get Bridges\n");

        help.append("\t deleteBridgeDomain <Node> <BridgeName>                          - Delete a Bridge\n");

        help.append("\t addPort <Node> <BridgeName> <PortName> <type> <options pairs>   - Add Port\n");

        help.append("\t deletePort <Node> <BridgeName> <PortName>                       - Delete Port\n");

        help.append("\t addPortVlan <Node> <BridgeName> <PortName> <vlan>               - Add Port, Vlan\n");

        help.append("\t addTunnel <Node> <Bridge> <Port> <tunnel-type> <remote-ip>      - Add Tunnel\n");

        help.append("          printCache <Node>   

 

- On the configuration options we need to hash them out on how to match OVSDB specific or attributes not addressed by the ConfigConstants enum. Just putting them all into a CUSTOM object is sort of cantankerous. But I have not had a chance to get advice on this from the team. For example probably a bad idea but just pseudo code:

 

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getController());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getDatapath_id());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getExternal_ids());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getFail_mode());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getOther_config());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getPorts());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getStatus());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getStp_enable());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getDatapath_type());

 

3. Thanks a bunch for pointing out the page. I just updated the Postman collection. I also linked a screen capture below to how it looks in the raw postman view. We will work on more documentation in coming days.

 

 

- Its ironic you mentioned the get ports for a given bridge. I coded list bridges for the "NodeConnector" method last night thinking it was just that. But then I asked Madhu and got clarity that the method is in fact for listing the connection between two nodes (per javadoc: Returns a NodeConnector mapped to a Port (if available) that is created using addPort). So maybe the best route is to just list them in the 

 

- I am also a bit confused on the method getBridgeDomainNode.  The Javadoc for getBridgeDomainNode says "Returns a Node dedicated to a Bridge Domain (if available) that is created using createBridgeDomain.". I could probably think of a couple of things that could be but clarity on datapath, logical isolation and what not would help.

 

- Please let me know if you have any time this week to review some more of this and it would be great if you had a little time to walk through some of your questions or potential issues you see with us. It is super helpful for us being heads down in code to get such awesome feedback from you!

 

Regards,

-Brent

 

 

From: Luis Gomez <luis.gomez@...>
Date: Sunday, November 24, 2013 10:40 PM
To: "ovsdb-dev@..." <ovsdb-dev@...>
Cc: "'integration-dev@...'" <integration-dev@...>
Subject: [ovsdb-dev] OVSDB system test

 

Hi folks,

 

Just started writing system test plan for OVSDB and I found one issue, one possible improvement and one general question.

 

1) Lets starts with the issue: with a controller with 2 IP interfaces (like the one we use for system test) connected to mininet OVS switch in passive mode (sudo ovs-vsctl set-manager ptcp:6640), when I add a bridge using:

 

POST http://10.125.136.52:8080/controller/nb/v2/networkconfig/bridgedomain/bridge/OVS/MINI1/s3

 

this one gets configured with the 2 IP addresses of the controller:

 

    Bridge "s3"

        Controller "tcp:10.125.136.38:6633"

        Controller "tcp:10.125.136.52:6633"

            is_connected: true

        Port "s3"

            Interface "s3"

                type: internal

 

and this generates some instability in the controller (it adds and deletes the switch all the time):

 

2013-11-24 18:49:17.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 is connected to the Controller

2013-11-24 18:49:17.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:17.896 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:17.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 is connected to the Controller

2013-11-24 18:49:18.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.898 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:18.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33820 is connected to the Controller

2013-11-24 18:49:19.893 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33820 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.894 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:19.896 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

…..

 

And same behavior is observed when I start mininet with “sudo mn --controller=remote,ip=10.125.136.52 --topo linear,2” and then I make the connection to the OVS switch: both OF switches try to connect to both controller interfaces.

 

The solution would be to configure only the IP of the controller that is used (by linux routing) to reach the mininet VM? In this example 10.125.136.52.

 

Also this is not a strange scenario, I think the controller in a normal deployment will have at least 2 interfaces (operation and traffic) so it is good to fix this behavior.

 

 

2) The improvement is on the BridgeDomain NB API, if Ilook at the different methods available: I can add (POST) and remove (DELETE) bridge and ports configuration, but I do not see any method to list (GET) bridge/configuration. It would be nice to get a view of the bridge/port configuration from the controller NB.

 

 

3) And finally the question: The BridgeDomain POST method has a request body that it says it is documented under wiki.opendaylight.org project pages https://wiki.opendaylight.org/view/OVSDB_Integration:Mininet_OVSDB_Tutorial, however this page is not yet finished. Can you please share some examples of custom values for this field?

 

 

Thanks/Luis

 

_______________________________________________ ovsdb-dev mailing list ovsdb-dev@... https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev




_______________________________________________
integration-dev mailing list
integration-dev@...
https://lists.opendaylight.org/mailman/listinfo/integration-dev

 

 


Re: [integration-dev] OVSDB system test

Luis Gomez <luis.gomez@...>
 

Actually I was too fast on the test cases, the ping after replacing one switch by another does not work but I think it is an issue in simple forwarding app. Have you also seen this behavior?

 

BR/Luis

 

 

From: Brent Salisbury [mailto:brent.salisbury@...]
Sent: Monday, November 25, 2013 2:46 PM
To: Madhu Venguopal; Luis Gomez; ovsdb-dev@...; Aswin Nair
Cc: 'integration-dev@...'
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test

 

Luis, you are the man buddy. We will get you more docs and functions in coming days sir.

 

Thanks,

-Brent

 

 

From: Madhu Venugopal <mavenugo@...>
Date: Monday, November 25, 2013 5:43 PM
To: Luis Gomez <luis.gomez@...>, brent <brent.salisbury@...>, "ovsdb-dev@..." <ovsdb-dev@...>
Cc: "'integration-dev@...'" <integration-dev@...>
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test

 


Excellent. Thanks Luis.

Thanks,
Madhu

On 11/25/13, 1:02 PM, Luis Gomez wrote:

OK, thanks to the Postman examples I have the system test nailed down with the steps below:

 

- Configure mininet in passive mode (sudo ovs-vsctl set-manager ptcp:6640)

- Start mininet with topology tree,2 (the standard we use in system test): h1,h2 – s2 – s1 – s3 – h3,h4

- Controller connects to OVS node in mininet VM

- We create a new bridge s4

- We delete s1 ports s1-eth1 and s1-eth2

- We add s4 ports s4-eth1 and s4-eth2 replacing s1 connections

- We delete s1

- We ping and everything works!

So the test will fully replace switch s1 by new switch s4.

 

Thanks very much for your support.

 

BR/Luis

 

 

 

From: Madhu Venguopal [mailto:mavenugo@...]
Sent: Sunday, November 24, 2013 10:39 PM
To: Luis Gomez; Brent Salisbury; ovsdb-dev@...
Cc: 'integration-dev@...'
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test

 

Hi Luis,

Exactly. The correct solution is to identify the appropriate Controller-ip-address to set based on the reachability information
towards the switch via OVSDB. And as Brent suggested, this is work in progress.

Please use the config.ini in the meanwhile.

I will also add some points later to Brent's on the original email.

Thanks,
Madhu

On 11/24/13, 10:25 PM, Luis Gomez wrote:

Hi Brent,

 

Thanks for your quick answer. I will try the examples from Postman and let you know. For the question about which controller IP should be configured in the OVS bridge, I still think ideally it should be the IP address of the interface the controller uses to reach the OVS node, this is to be consistent with the idea of sending and receiving on the same interface. But maybe this is difficult to code and in that case the config.ini file seems a good workaround as well.

 

BR/Luis

 

 

From: Brent Salisbury [mailto:brent.salisbury@...]
Sent: Sunday, November 24, 2013 8:49 PM
To: Luis Gomez; ovsdb-dev@...
Cc: 'integration-dev@...'
Subject: Re: [ovsdb-dev] OVSDB system test

 

Hi Luis,

 

Thanks so much for the feedback, this is really awesome! I threw in some thoughts, Im sure the others have additional input due to their better knowledge of the core controller but here are some starters.

 

Since we automatically connect the OVS bridge instance to the controller we currently add all of the interfaces on the controller to the set-controller target until we decided the best way to tackle this. We just chatted about this in IRC (#opendaylight-ovsdb) over the weekend and we concluded a reasonable plan is to choose the interface on the controller containing the hosts default route and set the default target to that iface for each OVS bridge. It is on my list to code this evening so it will be patched shortly. The other would be a behavior if there was not a default route on the interface. It will likely be a random choice at that point since as you pointed out it gets very squirrely with multiples :) Please let us know if you have any other suggestions.

 

- In the meantime we have recommended explicitly setting the interface to bind in the config.ini file.

 

### config.ini path/location ###

distribution/opendaylight/target/distribution.opendaylight-osgipackage/opendaylight/configuration/config.ini

### config.ini file ###

# Open Flow related system parameters

# TCP port on which the controller is listening (default 6633)

# of.listenPort=6633

# IP address of the controller (default: wild card)  <== Uncomment and add the desired address for socket binding.

# of.address = 

 

--Adjust that entry to an address you can bind to your host:

### config.ini file ###

of.address = 172.16.58.1 <==  I need to test this and see if it will accept a list also. 

 

2. The following methods for example are wired from the IPluginInBridgeDomainConfigService. Modifying ports/bridges is still yet to be implemented. I was looking at it last night and 

 

        help.append("---OVSDB CLI---\n");

        help.append("\t ovsconnect <ConnectionName> <ip-address>                        - Connect to OVSDB\n");

        help.append("\t addBridge <Node> <BridgeName>                                   - Add Bridge\n");

        help.append("\t getBridgeDomains <Node>                                         - Get Bridges\n");

        help.append("\t deleteBridgeDomain <Node> <BridgeName>                          - Delete a Bridge\n");

        help.append("\t addPort <Node> <BridgeName> <PortName> <type> <options pairs>   - Add Port\n");

        help.append("\t deletePort <Node> <BridgeName> <PortName>                       - Delete Port\n");

        help.append("\t addPortVlan <Node> <BridgeName> <PortName> <vlan>               - Add Port, Vlan\n");

        help.append("\t addTunnel <Node> <Bridge> <Port> <tunnel-type> <remote-ip>      - Add Tunnel\n");

        help.append("          printCache <Node>   

 

- On the configuration options we need to hash them out on how to match OVSDB specific or attributes not addressed by the ConfigConstants enum. Just putting them all into a CUSTOM object is sort of cantankerous. But I have not had a chance to get advice on this from the team. For example probably a bad idea but just pseudo code:

 

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getController());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getDatapath_id());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getExternal_ids());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getFail_mode());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getOther_config());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getPorts());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getStatus());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getStp_enable());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getDatapath_type());

 

3. Thanks a bunch for pointing out the page. I just updated the Postman collection. I also linked a screen capture below to how it looks in the raw postman view. We will work on more documentation in coming days.

 

 

- Its ironic you mentioned the get ports for a given bridge. I coded list bridges for the "NodeConnector" method last night thinking it was just that. But then I asked Madhu and got clarity that the method is in fact for listing the connection between two nodes (per javadoc: Returns a NodeConnector mapped to a Port (if available) that is created using addPort). So maybe the best route is to just list them in the 

 

- I am also a bit confused on the method getBridgeDomainNode.  The Javadoc for getBridgeDomainNode says "Returns a Node dedicated to a Bridge Domain (if available) that is created using createBridgeDomain.". I could probably think of a couple of things that could be but clarity on datapath, logical isolation and what not would help.

 

- Please let me know if you have any time this week to review some more of this and it would be great if you had a little time to walk through some of your questions or potential issues you see with us. It is super helpful for us being heads down in code to get such awesome feedback from you!

 

Regards,

-Brent

 

 

From: Luis Gomez <luis.gomez@...>
Date: Sunday, November 24, 2013 10:40 PM
To: "ovsdb-dev@..." <ovsdb-dev@...>
Cc: "'integration-dev@...'" <integration-dev@...>
Subject: [ovsdb-dev] OVSDB system test

 

Hi folks,

 

Just started writing system test plan for OVSDB and I found one issue, one possible improvement and one general question.

 

1) Lets starts with the issue: with a controller with 2 IP interfaces (like the one we use for system test) connected to mininet OVS switch in passive mode (sudo ovs-vsctl set-manager ptcp:6640), when I add a bridge using:

 

POST http://10.125.136.52:8080/controller/nb/v2/networkconfig/bridgedomain/bridge/OVS/MINI1/s3

 

this one gets configured with the 2 IP addresses of the controller:

 

    Bridge "s3"

        Controller "tcp:10.125.136.38:6633"

        Controller "tcp:10.125.136.52:6633"

            is_connected: true

        Port "s3"

            Interface "s3"

                type: internal

 

and this generates some instability in the controller (it adds and deletes the switch all the time):

 

2013-11-24 18:49:17.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 is connected to the Controller

2013-11-24 18:49:17.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:17.896 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:17.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 is connected to the Controller

2013-11-24 18:49:18.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.898 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:18.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33820 is connected to the Controller

2013-11-24 18:49:19.893 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33820 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.894 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:19.896 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

…..

 

And same behavior is observed when I start mininet with “sudo mn --controller=remote,ip=10.125.136.52 --topo linear,2” and then I make the connection to the OVS switch: both OF switches try to connect to both controller interfaces.

 

The solution would be to configure only the IP of the controller that is used (by linux routing) to reach the mininet VM? In this example 10.125.136.52.

 

Also this is not a strange scenario, I think the controller in a normal deployment will have at least 2 interfaces (operation and traffic) so it is good to fix this behavior.

 

 

2) The improvement is on the BridgeDomain NB API, if Ilook at the different methods available: I can add (POST) and remove (DELETE) bridge and ports configuration, but I do not see any method to list (GET) bridge/configuration. It would be nice to get a view of the bridge/port configuration from the controller NB.

 

 

3) And finally the question: The BridgeDomain POST method has a request body that it says it is documented under wiki.opendaylight.org project pages https://wiki.opendaylight.org/view/OVSDB_Integration:Mininet_OVSDB_Tutorial, however this page is not yet finished. Can you please share some examples of custom values for this field?

 

 

Thanks/Luis

 

_______________________________________________ ovsdb-dev mailing list ovsdb-dev@... https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev





_______________________________________________
integration-dev mailing list
integration-dev@...
https://lists.opendaylight.org/mailman/listinfo/integration-dev

 

 


Re: [integration-dev] OVSDB system test

Brent Salisbury
 

Luis, you are the man buddy. We will get you more docs and functions in coming days sir.

Thanks,
-Brent


From: Madhu Venugopal <mavenugo@...>
Date: Monday, November 25, 2013 5:43 PM
To: Luis Gomez <luis.gomez@...>, brent <brent.salisbury@...>, "ovsdb-dev@..." <ovsdb-dev@...>
Cc: "'integration-dev@...'" <integration-dev@...>
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test


Excellent. Thanks Luis.

Thanks,
Madhu

On 11/25/13, 1:02 PM, Luis Gomez wrote:

OK, thanks to the Postman examples I have the system test nailed down with the steps below:

 

- Configure mininet in passive mode (sudo ovs-vsctl set-manager ptcp:6640)

- Start mininet with topology tree,2 (the standard we use in system test): h1,h2 – s2 – s1 – s3 – h3,h4

- Controller connects to OVS node in mininet VM

- We create a new bridge s4

- We delete s1 ports s1-eth1 and s1-eth2

- We add s4 ports s4-eth1 and s4-eth2 replacing s1 connections

- We delete s1

- We ping and everything works!

So the test will fully replace switch s1 by new switch s4.

 

Thanks very much for your support.

 

BR/Luis

 

 

 

From: Madhu Venguopal [mailto:mavenugo@...]
Sent: Sunday, November 24, 2013 10:39 PM
To: Luis Gomez; Brent Salisbury; ovsdb-dev@...
Cc: 'integration-dev@...'
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test

 

Hi Luis,

Exactly. The correct solution is to identify the appropriate Controller-ip-address to set based on the reachability information
towards the switch via OVSDB. And as Brent suggested, this is work in progress.

Please use the config.ini in the meanwhile.

I will also add some points later to Brent's on the original email.

Thanks,
Madhu

On 11/24/13, 10:25 PM, Luis Gomez wrote:

Hi Brent,

 

Thanks for your quick answer. I will try the examples from Postman and let you know. For the question about which controller IP should be configured in the OVS bridge, I still think ideally it should be the IP address of the interface the controller uses to reach the OVS node, this is to be consistent with the idea of sending and receiving on the same interface. But maybe this is difficult to code and in that case the config.ini file seems a good workaround as well.

 

BR/Luis

 

 

From: Brent Salisbury [mailto:brent.salisbury@...]
Sent: Sunday, November 24, 2013 8:49 PM
To: Luis Gomez; ovsdb-dev@...
Cc: 'integration-dev@...'
Subject: Re: [ovsdb-dev] OVSDB system test

 

Hi Luis,

 

Thanks so much for the feedback, this is really awesome! I threw in some thoughts, Im sure the others have additional input due to their better knowledge of the core controller but here are some starters.

 

Since we automatically connect the OVS bridge instance to the controller we currently add all of the interfaces on the controller to the set-controller target until we decided the best way to tackle this. We just chatted about this in IRC (#opendaylight-ovsdb) over the weekend and we concluded a reasonable plan is to choose the interface on the controller containing the hosts default route and set the default target to that iface for each OVS bridge. It is on my list to code this evening so it will be patched shortly. The other would be a behavior if there was not a default route on the interface. It will likely be a random choice at that point since as you pointed out it gets very squirrely with multiples :) Please let us know if you have any other suggestions.

 

- In the meantime we have recommended explicitly setting the interface to bind in the config.ini file.

 

### config.ini path/location ###

distribution/opendaylight/target/distribution.opendaylight-osgipackage/opendaylight/configuration/config.ini

### config.ini file ###

# Open Flow related system parameters

# TCP port on which the controller is listening (default 6633)

# of.listenPort=6633

# IP address of the controller (default: wild card)  <== Uncomment and add the desired address for socket binding.

# of.address = 

 

--Adjust that entry to an address you can bind to your host:

### config.ini file ###

of.address = 172.16.58.1 <==  I need to test this and see if it will accept a list also. 

 

2. The following methods for example are wired from the IPluginInBridgeDomainConfigService. Modifying ports/bridges is still yet to be implemented. I was looking at it last night and 

 

        help.append("---OVSDB CLI---\n");

        help.append("\t ovsconnect <ConnectionName> <ip-address>                        - Connect to OVSDB\n");

        help.append("\t addBridge <Node> <BridgeName>                                   - Add Bridge\n");

        help.append("\t getBridgeDomains <Node>                                         - Get Bridges\n");

        help.append("\t deleteBridgeDomain <Node> <BridgeName>                          - Delete a Bridge\n");

        help.append("\t addPort <Node> <BridgeName> <PortName> <type> <options pairs>   - Add Port\n");

        help.append("\t deletePort <Node> <BridgeName> <PortName>                       - Delete Port\n");

        help.append("\t addPortVlan <Node> <BridgeName> <PortName> <vlan>               - Add Port, Vlan\n");

        help.append("\t addTunnel <Node> <Bridge> <Port> <tunnel-type> <remote-ip>      - Add Tunnel\n");

        help.append("          printCache <Node>   

 

- On the configuration options we need to hash them out on how to match OVSDB specific or attributes not addressed by the ConfigConstants enum. Just putting them all into a CUSTOM object is sort of cantankerous. But I have not had a chance to get advice on this from the team. For example probably a bad idea but just pseudo code:

 

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getController());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getDatapath_id());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getExternal_ids());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getFail_mode());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getOther_config());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getPorts());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getStatus());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getStp_enable());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getDatapath_type());

 

3. Thanks a bunch for pointing out the page. I just updated the Postman collection. I also linked a screen capture below to how it looks in the raw postman view. We will work on more documentation in coming days.

 

 

- Its ironic you mentioned the get ports for a given bridge. I coded list bridges for the "NodeConnector" method last night thinking it was just that. But then I asked Madhu and got clarity that the method is in fact for listing the connection between two nodes (per javadoc: Returns a NodeConnector mapped to a Port (if available) that is created using addPort). So maybe the best route is to just list them in the 

 

- I am also a bit confused on the method getBridgeDomainNode.  The Javadoc for getBridgeDomainNode says "Returns a Node dedicated to a Bridge Domain (if available) that is created using createBridgeDomain.". I could probably think of a couple of things that could be but clarity on datapath, logical isolation and what not would help.

 

- Please let me know if you have any time this week to review some more of this and it would be great if you had a little time to walk through some of your questions or potential issues you see with us. It is super helpful for us being heads down in code to get such awesome feedback from you!

 

Regards,

-Brent

 

 

From: Luis Gomez <luis.gomez@...>
Date: Sunday, November 24, 2013 10:40 PM
To: "ovsdb-dev@..." <ovsdb-dev@...>
Cc: "'integration-dev@...'" <integration-dev@...>
Subject: [ovsdb-dev] OVSDB system test

 

Hi folks,

 

Just started writing system test plan for OVSDB and I found one issue, one possible improvement and one general question.

 

1) Lets starts with the issue: with a controller with 2 IP interfaces (like the one we use for system test) connected to mininet OVS switch in passive mode (sudo ovs-vsctl set-manager ptcp:6640), when I add a bridge using:

 

POST http://10.125.136.52:8080/controller/nb/v2/networkconfig/bridgedomain/bridge/OVS/MINI1/s3

 

this one gets configured with the 2 IP addresses of the controller:

 

    Bridge "s3"

        Controller "tcp:10.125.136.38:6633"

        Controller "tcp:10.125.136.52:6633"

            is_connected: true

        Port "s3"

            Interface "s3"

                type: internal

 

and this generates some instability in the controller (it adds and deletes the switch all the time):

 

2013-11-24 18:49:17.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 is connected to the Controller

2013-11-24 18:49:17.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:17.896 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:17.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 is connected to the Controller

2013-11-24 18:49:18.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.898 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:18.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33820 is connected to the Controller

2013-11-24 18:49:19.893 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33820 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.894 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:19.896 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

…..

 

And same behavior is observed when I start mininet with “sudo mn --controller=remote,ip=10.125.136.52 --topo linear,2” and then I make the connection to the OVS switch: both OF switches try to connect to both controller interfaces.

 

The solution would be to configure only the IP of the controller that is used (by linux routing) to reach the mininet VM? In this example 10.125.136.52.

 

Also this is not a strange scenario, I think the controller in a normal deployment will have at least 2 interfaces (operation and traffic) so it is good to fix this behavior.

 

 

2) The improvement is on the BridgeDomain NB API, if Ilook at the different methods available: I can add (POST) and remove (DELETE) bridge and ports configuration, but I do not see any method to list (GET) bridge/configuration. It would be nice to get a view of the bridge/port configuration from the controller NB.

 

 

3) And finally the question: The BridgeDomain POST method has a request body that it says it is documented under wiki.opendaylight.org project pages https://wiki.opendaylight.org/view/OVSDB_Integration:Mininet_OVSDB_Tutorial, however this page is not yet finished. Can you please share some examples of custom values for this field?

 

 

Thanks/Luis

 

_______________________________________________ ovsdb-dev mailing list ovsdb-dev@... https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev




_______________________________________________
integration-dev mailing list
integration-dev@...
https://lists.opendaylight.org/mailman/listinfo/integration-dev

 


4741 - 4760 of 4855