restconf/mdsal wildcard queries
Tony, Robert,
Anil mentioned there is a possibility to add wildcard queries to mdsal? Is that a feature that can be added for Be?
The idea is to be able to search for something using a field in the model that is not a key. For instance, the ovsdb.yang imports the network-topology and adds a Node to the datastore. The model augments the node to include ip-addresses. We would like the ability to issue a restconf query to return the node with that ip-address.
Today to do this we would implement an RPC to terminate in our backend code. Then retrieve all the Nodes in the datastore, loop over them and look for the specific matching data. We figure this is a common block of code that might be able to be implemented in the mdsal itself.
Thanks, Sam
|
|
Khal, no, those exceptions are OK. In the 7.12.1 schema datapath and iface type fields were added so you have to have the matching ovs version installed which most don't. I don't recall the exact ovs version that brought in the new fields but I think anything 2.3.1 and earlier will have the below exception. Did you see my last response when you mentioned it was the openflow inventory that you were not seeing? That is why you don't see the switches. The southbound feature is what will get the ovsdb nodes into the inventory. You can see that in your logs since you have the exceptions below that go along with that. From there, though ,the odl-ovsdb-openstack feature needs to be running to set the Controller target for the bridges. This will cause the bridges to connect to ODL and the openflwoplugin will populate the openflow switch inventory. Ok, yeah, I thought the controller address was being set manually in your setup. If it isn't then the switches will not connect to odl openflowplugin and no inventory update.
The odl-ovsd-openstack feature does that. When the nodes connect, the netvirt app will set the controller target address so that the switches connect. At that point there will be switches added to the inventory by openflowplugin. Sam ----- Original Message ----- From: "Khaldoon Al Zoubi" <khaldoon.alzoubi@...> To: "Sam Hague" <shague@...> Cc: ovsdb-dev@... Sent: Thursday, July 2, 2015 2:46:50 PM Subject: RE: [ovsdb-dev] ODL Inventory
Hi Sam,
Do you think the following two exceptions explain some of the problem I have. Thanks.
2015-07-02 13:40:13,110 | DEBUG | n-invoker-impl-0 | OpenVSwitchUpdateCommand | 251 - org.opendaylight.ovsdb.southbound-impl - 1.1.0.SNAPSHOT | Datapath types not supported by this version of ovsdb org.opendaylight.ovsdb.lib.error.SchemaVersionMismatchException: The schema version used to access this Table/Column does not match the required version. Current Version: 7.6.0 Added in Version: 7.12.1 at org.opendaylight.ovsdb.lib.schema.typed.TyperUtils.checkVersion(TyperUtils.java:217)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.lib.schema.typed.TyperUtils.checkColumnSchemaVersion(TyperUtils.java:203)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.lib.schema.typed.TyperUtils.access$100(TyperUtils.java:37)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.lib.schema.typed.TyperUtils$1.processGetColumn(TyperUtils.java:307)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.lib.schema.typed.TyperUtils$1.invoke(TyperUtils.java:379)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at com.sun.proxy.$Proxy116.getDatapathTypesColumn(Unknown Source)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.southbound.transactions.md.OpenVSwitchUpdateCommand.setDataPathTypes(OpenVSwitchUpdateCommand.java:221)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.southbound.transactions.md.OpenVSwitchUpdateCommand.execute(OpenVSwitchUpdateCommand.java:81)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.southbound.transactions.md.OvsdbOperationalCommandAggregator.execute(OvsdbOperationalCommandAggregator.java:30)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.southbound.transactions.md.TransactionInvokerImpl.run(TransactionInvokerImpl.java:77)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)[:1.7.0_79] at java.util.concurrent.FutureTask.run(FutureTask.java:262)[:1.7.0_79] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_79] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)[:1.7.0_79] at java.lang.Thread.run(Thread.java:745)[:1.7.0_79] 2015-07-02 13:40:13,118 | DEBUG | n-invoker-impl-0 | OpenVSwitchUpdateCommand | 251 - org.opendaylight.ovsdb.southbound-impl - 1.1.0.SNAPSHOT | Iface types not supported by this version of ovsdb org.opendaylight.ovsdb.lib.error.SchemaVersionMismatchException: The schema version used to access this Table/Column does not match the required version. Current Version: 7.6.0 Added in Version: 7.12.1 at org.opendaylight.ovsdb.lib.schema.typed.TyperUtils.checkVersion(TyperUtils.java:217)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.lib.schema.typed.TyperUtils.checkColumnSchemaVersion(TyperUtils.java:203)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.lib.schema.typed.TyperUtils.access$100(TyperUtils.java:37)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.lib.schema.typed.TyperUtils$1.processGetColumn(TyperUtils.java:307)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.lib.schema.typed.TyperUtils$1.invoke(TyperUtils.java:379)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at com.sun.proxy.$Proxy116.getIfaceTypesColumn(Unknown Source)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.southbound.transactions.md.OpenVSwitchUpdateCommand.setInterfaceTypes(OpenVSwitchUpdateCommand.java:198)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.southbound.transactions.md.OpenVSwitchUpdateCommand.execute(OpenVSwitchUpdateCommand.java:82)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.southbound.transactions.md.OvsdbOperationalCommandAggregator.execute(OvsdbOperationalCommandAggregator.java:30)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.southbound.transactions.md.TransactionInvokerImpl.run(TransactionInvokerImpl.java:77)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)[:1.7.0_79] at java.util.concurrent.FutureTask.run(FutureTask.java:262)[:1.7.0_79] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_79] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)[:1.7.0_79] at java.lang.Thread.run(Thread.java:745)[:1.7.0_79]
-----Original Message----- From: Sam Hague [mailto:shague@...] Sent: Wednesday, July 01, 2015 1:33 PM To: Khaldoon Al Zoubi Cc: ovsdb-dev@... Subject: Re: [ovsdb-dev] ODL Inventory
----- Original Message -----
From: "Khaldoon Al Zoubi" <khaldoon.alzoubi@...> To: "Sam Hague" <shague@...> Cc: ovsdb-dev@... Sent: Tuesday, June 30, 2015 3:46:14 PM Subject: RE: [ovsdb-dev] ODL Inventory
Hi Sam,
The ovsdb loads the config and operational topology correctly, which is good I need that. But, what is not working for me is that openflowplugin is not adding switches to inventory. Ok, yeah, I thought the controller address was being set manually in your setup. If it isn't then the switches will not connect to odl openflowplugin and no inventory update.
The odl-ovsd-openstack feature does that. When the nodes connect, the netvirt app will set the controller target address so that the switches connect. At that point there will be switches added to the inventory by openflowplugin.
Thanks.
-----Original Message----- From: Sam Hague [mailto:shague@...] Sent: Tuesday, June 30, 2015 12:39 PM To: Khaldoon Al Zoubi Cc: ovsdb-dev@... Subject: Re: [ovsdb-dev] ODL Inventory
Khal,
the openstack modules do not write anything to operational. It relies on the southbound to do that and openstack listens for those changes when they happen. After that the openstack netvirt modules will do things like add bridges, but it is the southbound which will update the operational topology. If you are looking for the openflow nodes, then the openflowplugin does that (look in the earlier email where I mentioned that)
1. Did you verify the southbound feature loaded? feature:list -i | grep ovsdb. look for southbound. 2. Try the postman calls. look in the ovsdb/resources/commons dir for the southbound postman. Use the "Get config topology" and "get operational topology" restconf calls and see if you get the ovsdb:1 node. 3. Add the ovs-vsctl set-manager tcp:<odlip>:6640 and verify if the ovsdb node connected to odl, ovs-vsctl show. 4. Then try the postman calls again to see if the node shows up.
Sam
----- Original Message -----
From: "Khaldoon Al Zoubi" <khaldoon.alzoubi@...> To: "Sam Hague" <shague@...> Cc: ovsdb-dev@... Sent: Tuesday, June 30, 2015 12:27:13 PM Subject: RE: [ovsdb-dev] ODL Inventory
Hi Sam,
I commented out the openstack bundles in odl-ovsdb-openstack (please see below) to test if odl-ovsdb-southbound-impl-ui will be able to load the inventory operational node into datastore. Well, it didn't do it. Is that mean that the openstack bundles are doing extra work to populate the inventory? Thanks.
-------- <feature name="odl-ovsdb-openstack" description="OpenDaylight :: OVSDB :: OpenStack Network Virtualization" version='${openstack.netvirt.version}'> <feature version='${mdsal.version}'>odl-mdsal-broker</feature> <feature version="${openflowplugin.version}">odl-openflowplugin-nsf-model</feature> <feature version="${networkconfig.neutron.version}">odl-neutron-service</feature> <feature version="1.1.0-SNAPSHOT">odl-ovsdb-southbound-impl-ui</feature> <feature version="${openflowplugin.version}">odl-openflowplugin-flow-services</feature> <feature version="${openflowplugin.version}">odl-openflowplugin-nxm-extensions</feature> <!-- <bundle>mvn:org.opendaylight.ovsdb/utils.servicehelper/${ovsdb.utils.servicehelper.version}</bundle> <bundle>mvn:org.opendaylight.ovsdb/openstack.net-virt/${openstack.netvirt.version}</bundle> <bundle>mvn:org.opendaylight.ovsdb/openstack.net-virt-providers/${openstack.netvirt.providers.version}</bundle> <configfile finalname="etc/opendaylight/karaf/netvirt-impl-default-config.xml">mvn:org.opendaylight.ovsdb/openstack.net-virt/${project.version}/xml/config</configfile> <configfile finalname="etc/opendaylight/karaf/netvirt-providers-impl-default-config.xml">mvn:org.opendaylight.ovsdb/openstack.net-virt-providers/${project.version}/xml/config</configfile> --> </feature>
-----Original Message----- From: Khaldoon Al Zoubi Sent: Thursday, June 25, 2015 3:45 PM To: 'Sam Hague' Cc: ovsdb-dev@... Subject: RE: [ovsdb-dev] ODL Inventory
Thanks Sam. Actually, this what I thought I need to do (only include odl-ovsdb-southbound-impl in my features.xml), but I am not sure what part I am missing. I believe the devstack & ODL connection works since I am able to see neutron elements in datastore when executing commands like (neutron net-create net-1). So feature odl-neutron-service works.
However, when I am running ODL purely from the OVSDB project it works and I can see the operational nodes. So, I am missing something in my project.
Thanks Sam as always.
Regards, Khal
-----Original Message----- From: Sam Hague [mailto:shague@...] Sent: Thursday, June 25, 2015 2:41 PM To: Khaldoon Al Zoubi Cc: ovsdb-dev@... Subject: Re: [ovsdb-dev] ODL Inventory
Khal,
the OVSDB southbound plugin [1] will populate the topology with the ovsdb node information, including the bridges and ports. With devstack as part of the local.conf config the ODL address is specified. In the final steps of the stack.sh the OVSDB Manager entry is set to that address and the OVSDB nodes will connect to ODL. The OVSDB southbound plugin will see that connection and begin to populate the MDSAL operational datastore - stores the node, the bridge, the ports as termination points.
From there the netvirt [2] application listens for the operational updates. netvirt also listens on the neutron events coming from the northbound side. With these two sets of events netvirt will satisfy the neutron requests.
The openflow nodes inventory is populated via the openflowplugin. When the OVSDB nodes connect and netvirt sees that it will create the required bridges, i.e, br-int, and then set the Controller address. Those bridges will then connect to ODL openflowplugin port and openflowplugin will add the switches to the inventory.
So you just need the odl-ovsdb-southbound-impl or odl-ovsdb-southbound-impl-ui feature to get the southbound plugin which will get the inventory for you.
Thanks, Sam
[1] ovsdb/southbound/southbound-impl [2] ovsdb/openstack
----- Original Message -----
From: "Khaldoon Al Zoubi" <khaldoon.alzoubi@...> To: ovsdb-dev@... Sent: Thursday, June 25, 2015 12:15:05 PM Subject: [ovsdb-dev] ODL Inventory
Hi,
I can’t figure out how OVSDB populate ODL Inventory based on openstack (i.e. specifically after ./stack.sh is complete). Also, is there a feature I can include in my project to do that.
Thanks much.
Khal
_______________________________________________ ovsdb-dev mailing list ovsdb-dev@... https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
|
|
Intent to participate in Be release - OVSDB
The ovsdb project formally joins the OpenDaylight Beryllium Simultaneous Release and agrees to the activities and timeline documented on the Beryllium Release Plan Page.
Thanks, Sam
|
|
Khaldoon Al Zoubi <khaldoon.alzoubi@...>
Hi Sam,
Do you think the following two exceptions explain some of the problem I have. Thanks.
2015-07-02 13:40:13,110 | DEBUG | n-invoker-impl-0 | OpenVSwitchUpdateCommand | 251 - org.opendaylight.ovsdb.southbound-impl - 1.1.0.SNAPSHOT | Datapath types not supported by this version of ovsdb org.opendaylight.ovsdb.lib.error.SchemaVersionMismatchException: The schema version used to access this Table/Column does not match the required version. Current Version: 7.6.0 Added in Version: 7.12.1 at org.opendaylight.ovsdb.lib.schema.typed.TyperUtils.checkVersion(TyperUtils.java:217)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.lib.schema.typed.TyperUtils.checkColumnSchemaVersion(TyperUtils.java:203)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.lib.schema.typed.TyperUtils.access$100(TyperUtils.java:37)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.lib.schema.typed.TyperUtils$1.processGetColumn(TyperUtils.java:307)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.lib.schema.typed.TyperUtils$1.invoke(TyperUtils.java:379)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at com.sun.proxy.$Proxy116.getDatapathTypesColumn(Unknown Source)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.southbound.transactions.md.OpenVSwitchUpdateCommand.setDataPathTypes(OpenVSwitchUpdateCommand.java:221)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.southbound.transactions.md.OpenVSwitchUpdateCommand.execute(OpenVSwitchUpdateCommand.java:81)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.southbound.transactions.md.OvsdbOperationalCommandAggregator.execute(OvsdbOperationalCommandAggregator.java:30)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.southbound.transactions.md.TransactionInvokerImpl.run(TransactionInvokerImpl.java:77)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)[:1.7.0_79] at java.util.concurrent.FutureTask.run(FutureTask.java:262)[:1.7.0_79] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_79] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)[:1.7.0_79] at java.lang.Thread.run(Thread.java:745)[:1.7.0_79] 2015-07-02 13:40:13,118 | DEBUG | n-invoker-impl-0 | OpenVSwitchUpdateCommand | 251 - org.opendaylight.ovsdb.southbound-impl - 1.1.0.SNAPSHOT | Iface types not supported by this version of ovsdb org.opendaylight.ovsdb.lib.error.SchemaVersionMismatchException: The schema version used to access this Table/Column does not match the required version. Current Version: 7.6.0 Added in Version: 7.12.1 at org.opendaylight.ovsdb.lib.schema.typed.TyperUtils.checkVersion(TyperUtils.java:217)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.lib.schema.typed.TyperUtils.checkColumnSchemaVersion(TyperUtils.java:203)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.lib.schema.typed.TyperUtils.access$100(TyperUtils.java:37)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.lib.schema.typed.TyperUtils$1.processGetColumn(TyperUtils.java:307)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.lib.schema.typed.TyperUtils$1.invoke(TyperUtils.java:379)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at com.sun.proxy.$Proxy116.getIfaceTypesColumn(Unknown Source)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.southbound.transactions.md.OpenVSwitchUpdateCommand.setInterfaceTypes(OpenVSwitchUpdateCommand.java:198)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.southbound.transactions.md.OpenVSwitchUpdateCommand.execute(OpenVSwitchUpdateCommand.java:82)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.southbound.transactions.md.OvsdbOperationalCommandAggregator.execute(OvsdbOperationalCommandAggregator.java:30)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at org.opendaylight.ovsdb.southbound.transactions.md.TransactionInvokerImpl.run(TransactionInvokerImpl.java:77)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)[:1.7.0_79] at java.util.concurrent.FutureTask.run(FutureTask.java:262)[:1.7.0_79] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_79] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)[:1.7.0_79] at java.lang.Thread.run(Thread.java:745)[:1.7.0_79]
toggle quoted messageShow quoted text
-----Original Message----- From: Sam Hague [mailto:shague@...] Sent: Wednesday, July 01, 2015 1:33 PM To: Khaldoon Al Zoubi Cc: ovsdb-dev@... Subject: Re: [ovsdb-dev] ODL Inventory ----- Original Message ----- From: "Khaldoon Al Zoubi" <khaldoon.alzoubi@...> To: "Sam Hague" <shague@...> Cc: ovsdb-dev@... Sent: Tuesday, June 30, 2015 3:46:14 PM Subject: RE: [ovsdb-dev] ODL Inventory
Hi Sam,
The ovsdb loads the config and operational topology correctly, which is good I need that. But, what is not working for me is that openflowplugin is not adding switches to inventory. Ok, yeah, I thought the controller address was being set manually in your setup. If it isn't then the switches will not connect to odl openflowplugin and no inventory update. The odl-ovsd-openstack feature does that. When the nodes connect, the netvirt app will set the controller target address so that the switches connect. At that point there will be switches added to the inventory by openflowplugin. Thanks.
-----Original Message----- From: Sam Hague [mailto:shague@...] Sent: Tuesday, June 30, 2015 12:39 PM To: Khaldoon Al Zoubi Cc: ovsdb-dev@... Subject: Re: [ovsdb-dev] ODL Inventory
Khal,
the openstack modules do not write anything to operational. It relies on the southbound to do that and openstack listens for those changes when they happen. After that the openstack netvirt modules will do things like add bridges, but it is the southbound which will update the operational topology. If you are looking for the openflow nodes, then the openflowplugin does that (look in the earlier email where I mentioned that)
1. Did you verify the southbound feature loaded? feature:list -i | grep ovsdb. look for southbound. 2. Try the postman calls. look in the ovsdb/resources/commons dir for the southbound postman. Use the "Get config topology" and "get operational topology" restconf calls and see if you get the ovsdb:1 node. 3. Add the ovs-vsctl set-manager tcp:<odlip>:6640 and verify if the ovsdb node connected to odl, ovs-vsctl show. 4. Then try the postman calls again to see if the node shows up.
Sam
----- Original Message -----
From: "Khaldoon Al Zoubi" <khaldoon.alzoubi@...> To: "Sam Hague" <shague@...> Cc: ovsdb-dev@... Sent: Tuesday, June 30, 2015 12:27:13 PM Subject: RE: [ovsdb-dev] ODL Inventory
Hi Sam,
I commented out the openstack bundles in odl-ovsdb-openstack (please see below) to test if odl-ovsdb-southbound-impl-ui will be able to load the inventory operational node into datastore. Well, it didn't do it. Is that mean that the openstack bundles are doing extra work to populate the inventory? Thanks.
-------- <feature name="odl-ovsdb-openstack" description="OpenDaylight :: OVSDB :: OpenStack Network Virtualization" version='${openstack.netvirt.version}'> <feature version='${mdsal.version}'>odl-mdsal-broker</feature> <feature version="${openflowplugin.version}">odl-openflowplugin-nsf-model</feature> <feature version="${networkconfig.neutron.version}">odl-neutron-service</feature> <feature version="1.1.0-SNAPSHOT">odl-ovsdb-southbound-impl-ui</feature> <feature version="${openflowplugin.version}">odl-openflowplugin-flow-services</feature> <feature version="${openflowplugin.version}">odl-openflowplugin-nxm-extensions</feature> <!-- <bundle>mvn:org.opendaylight.ovsdb/utils.servicehelper/${ovsdb.utils.servicehelper.version}</bundle> <bundle>mvn:org.opendaylight.ovsdb/openstack.net-virt/${openstack.netvirt.version}</bundle> <bundle>mvn:org.opendaylight.ovsdb/openstack.net-virt-providers/${openstack.netvirt.providers.version}</bundle> <configfile finalname="etc/opendaylight/karaf/netvirt-impl-default-config.xml">mvn:org.opendaylight.ovsdb/openstack.net-virt/${project.version}/xml/config</configfile> <configfile finalname="etc/opendaylight/karaf/netvirt-providers-impl-default-config.xml">mvn:org.opendaylight.ovsdb/openstack.net-virt-providers/${project.version}/xml/config</configfile> --> </feature>
-----Original Message----- From: Khaldoon Al Zoubi Sent: Thursday, June 25, 2015 3:45 PM To: 'Sam Hague' Cc: ovsdb-dev@... Subject: RE: [ovsdb-dev] ODL Inventory
Thanks Sam. Actually, this what I thought I need to do (only include odl-ovsdb-southbound-impl in my features.xml), but I am not sure what part I am missing. I believe the devstack & ODL connection works since I am able to see neutron elements in datastore when executing commands like (neutron net-create net-1). So feature odl-neutron-service works.
However, when I am running ODL purely from the OVSDB project it works and I can see the operational nodes. So, I am missing something in my project.
Thanks Sam as always.
Regards, Khal
-----Original Message----- From: Sam Hague [mailto:shague@...] Sent: Thursday, June 25, 2015 2:41 PM To: Khaldoon Al Zoubi Cc: ovsdb-dev@... Subject: Re: [ovsdb-dev] ODL Inventory
Khal,
the OVSDB southbound plugin [1] will populate the topology with the ovsdb node information, including the bridges and ports. With devstack as part of the local.conf config the ODL address is specified. In the final steps of the stack.sh the OVSDB Manager entry is set to that address and the OVSDB nodes will connect to ODL. The OVSDB southbound plugin will see that connection and begin to populate the MDSAL operational datastore - stores the node, the bridge, the ports as termination points.
From there the netvirt [2] application listens for the operational updates. netvirt also listens on the neutron events coming from the northbound side. With these two sets of events netvirt will satisfy the neutron requests.
The openflow nodes inventory is populated via the openflowplugin. When the OVSDB nodes connect and netvirt sees that it will create the required bridges, i.e, br-int, and then set the Controller address. Those bridges will then connect to ODL openflowplugin port and openflowplugin will add the switches to the inventory.
So you just need the odl-ovsdb-southbound-impl or odl-ovsdb-southbound-impl-ui feature to get the southbound plugin which will get the inventory for you.
Thanks, Sam
[1] ovsdb/southbound/southbound-impl [2] ovsdb/openstack
----- Original Message -----
From: "Khaldoon Al Zoubi" <khaldoon.alzoubi@...> To: ovsdb-dev@... Sent: Thursday, June 25, 2015 12:15:05 PM Subject: [ovsdb-dev] ODL Inventory
Hi,
I can’t figure out how OVSDB populate ODL Inventory based on openstack (i.e. specifically after ./stack.sh is complete). Also, is there a feature I can include in my project to do that.
Thanks much.
Khal
_______________________________________________ ovsdb-dev mailing list ovsdb-dev@... https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
|
|
toggle quoted messageShow quoted text
----- Original Message ----- From: "Khaldoon Al Zoubi" <khaldoon.alzoubi@...> To: "Sam Hague" <shague@...> Cc: ovsdb-dev@... Sent: Tuesday, June 30, 2015 3:46:14 PM Subject: RE: [ovsdb-dev] ODL Inventory
Hi Sam,
The ovsdb loads the config and operational topology correctly, which is good I need that. But, what is not working for me is that openflowplugin is not adding switches to inventory. Ok, yeah, I thought the controller address was being set manually in your setup. If it isn't then the switches will not connect to odl openflowplugin and no inventory update. The odl-ovsd-openstack feature does that. When the nodes connect, the netvirt app will set the controller target address so that the switches connect. At that point there will be switches added to the inventory by openflowplugin. Thanks.
-----Original Message----- From: Sam Hague [mailto:shague@...] Sent: Tuesday, June 30, 2015 12:39 PM To: Khaldoon Al Zoubi Cc: ovsdb-dev@... Subject: Re: [ovsdb-dev] ODL Inventory
Khal,
the openstack modules do not write anything to operational. It relies on the southbound to do that and openstack listens for those changes when they happen. After that the openstack netvirt modules will do things like add bridges, but it is the southbound which will update the operational topology. If you are looking for the openflow nodes, then the openflowplugin does that (look in the earlier email where I mentioned that)
1. Did you verify the southbound feature loaded? feature:list -i | grep ovsdb. look for southbound. 2. Try the postman calls. look in the ovsdb/resources/commons dir for the southbound postman. Use the "Get config topology" and "get operational topology" restconf calls and see if you get the ovsdb:1 node. 3. Add the ovs-vsctl set-manager tcp:<odlip>:6640 and verify if the ovsdb node connected to odl, ovs-vsctl show. 4. Then try the postman calls again to see if the node shows up.
Sam
----- Original Message -----
From: "Khaldoon Al Zoubi" <khaldoon.alzoubi@...> To: "Sam Hague" <shague@...> Cc: ovsdb-dev@... Sent: Tuesday, June 30, 2015 12:27:13 PM Subject: RE: [ovsdb-dev] ODL Inventory
Hi Sam,
I commented out the openstack bundles in odl-ovsdb-openstack (please see below) to test if odl-ovsdb-southbound-impl-ui will be able to load the inventory operational node into datastore. Well, it didn't do it. Is that mean that the openstack bundles are doing extra work to populate the inventory? Thanks.
-------- <feature name="odl-ovsdb-openstack" description="OpenDaylight :: OVSDB :: OpenStack Network Virtualization" version='${openstack.netvirt.version}'> <feature version='${mdsal.version}'>odl-mdsal-broker</feature> <feature version="${openflowplugin.version}">odl-openflowplugin-nsf-model</feature> <feature version="${networkconfig.neutron.version}">odl-neutron-service</feature> <feature version="1.1.0-SNAPSHOT">odl-ovsdb-southbound-impl-ui</feature> <feature version="${openflowplugin.version}">odl-openflowplugin-flow-services</feature> <feature version="${openflowplugin.version}">odl-openflowplugin-nxm-extensions</feature> <!-- <bundle>mvn:org.opendaylight.ovsdb/utils.servicehelper/${ovsdb.utils.servicehelper.version}</bundle> <bundle>mvn:org.opendaylight.ovsdb/openstack.net-virt/${openstack.netvirt.version}</bundle> <bundle>mvn:org.opendaylight.ovsdb/openstack.net-virt-providers/${openstack.netvirt.providers.version}</bundle> <configfile finalname="etc/opendaylight/karaf/netvirt-impl-default-config.xml">mvn:org.opendaylight.ovsdb/openstack.net-virt/${project.version}/xml/config</configfile> <configfile finalname="etc/opendaylight/karaf/netvirt-providers-impl-default-config.xml">mvn:org.opendaylight.ovsdb/openstack.net-virt-providers/${project.version}/xml/config</configfile> --> </feature>
-----Original Message----- From: Khaldoon Al Zoubi Sent: Thursday, June 25, 2015 3:45 PM To: 'Sam Hague' Cc: ovsdb-dev@... Subject: RE: [ovsdb-dev] ODL Inventory
Thanks Sam. Actually, this what I thought I need to do (only include odl-ovsdb-southbound-impl in my features.xml), but I am not sure what part I am missing. I believe the devstack & ODL connection works since I am able to see neutron elements in datastore when executing commands like (neutron net-create net-1). So feature odl-neutron-service works.
However, when I am running ODL purely from the OVSDB project it works and I can see the operational nodes. So, I am missing something in my project.
Thanks Sam as always.
Regards, Khal
-----Original Message----- From: Sam Hague [mailto:shague@...] Sent: Thursday, June 25, 2015 2:41 PM To: Khaldoon Al Zoubi Cc: ovsdb-dev@... Subject: Re: [ovsdb-dev] ODL Inventory
Khal,
the OVSDB southbound plugin [1] will populate the topology with the ovsdb node information, including the bridges and ports. With devstack as part of the local.conf config the ODL address is specified. In the final steps of the stack.sh the OVSDB Manager entry is set to that address and the OVSDB nodes will connect to ODL. The OVSDB southbound plugin will see that connection and begin to populate the MDSAL operational datastore - stores the node, the bridge, the ports as termination points.
From there the netvirt [2] application listens for the operational updates. netvirt also listens on the neutron events coming from the northbound side. With these two sets of events netvirt will satisfy the neutron requests.
The openflow nodes inventory is populated via the openflowplugin. When the OVSDB nodes connect and netvirt sees that it will create the required bridges, i.e, br-int, and then set the Controller address. Those bridges will then connect to ODL openflowplugin port and openflowplugin will add the switches to the inventory.
So you just need the odl-ovsdb-southbound-impl or odl-ovsdb-southbound-impl-ui feature to get the southbound plugin which will get the inventory for you.
Thanks, Sam
[1] ovsdb/southbound/southbound-impl [2] ovsdb/openstack
----- Original Message -----
From: "Khaldoon Al Zoubi" <khaldoon.alzoubi@...> To: ovsdb-dev@... Sent: Thursday, June 25, 2015 12:15:05 PM Subject: [ovsdb-dev] ODL Inventory
Hi,
I can’t figure out how OVSDB populate ODL Inventory based on openstack (i.e. specifically after ./stack.sh is complete). Also, is there a feature I can include in my project to do that.
Thanks much.
Khal
_______________________________________________ ovsdb-dev mailing list ovsdb-dev@... https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
|
|
Khaldoon Al Zoubi <khaldoon.alzoubi@...>
Hi Sam,
The ovsdb loads the config and operational topology correctly, which is good I need that. But, what is not working for me is that openflowplugin is not adding switches to inventory.
Thanks.
toggle quoted messageShow quoted text
-----Original Message----- From: Sam Hague [mailto:shague@...] Sent: Tuesday, June 30, 2015 12:39 PM To: Khaldoon Al Zoubi Cc: ovsdb-dev@... Subject: Re: [ovsdb-dev] ODL Inventory Khal, the openstack modules do not write anything to operational. It relies on the southbound to do that and openstack listens for those changes when they happen. After that the openstack netvirt modules will do things like add bridges, but it is the southbound which will update the operational topology. If you are looking for the openflow nodes, then the openflowplugin does that (look in the earlier email where I mentioned that) 1. Did you verify the southbound feature loaded? feature:list -i | grep ovsdb. look for southbound. 2. Try the postman calls. look in the ovsdb/resources/commons dir for the southbound postman. Use the "Get config topology" and "get operational topology" restconf calls and see if you get the ovsdb:1 node. 3. Add the ovs-vsctl set-manager tcp:<odlip>:6640 and verify if the ovsdb node connected to odl, ovs-vsctl show. 4. Then try the postman calls again to see if the node shows up. Sam ----- Original Message ----- From: "Khaldoon Al Zoubi" <khaldoon.alzoubi@...> To: "Sam Hague" <shague@...> Cc: ovsdb-dev@... Sent: Tuesday, June 30, 2015 12:27:13 PM Subject: RE: [ovsdb-dev] ODL Inventory
Hi Sam,
I commented out the openstack bundles in odl-ovsdb-openstack (please see below) to test if odl-ovsdb-southbound-impl-ui will be able to load the inventory operational node into datastore. Well, it didn't do it. Is that mean that the openstack bundles are doing extra work to populate the inventory? Thanks.
-------- <feature name="odl-ovsdb-openstack" description="OpenDaylight :: OVSDB :: OpenStack Network Virtualization" version='${openstack.netvirt.version}'> <feature version='${mdsal.version}'>odl-mdsal-broker</feature> <feature version="${openflowplugin.version}">odl-openflowplugin-nsf-model</feature> <feature version="${networkconfig.neutron.version}">odl-neutron-service</feature> <feature version="1.1.0-SNAPSHOT">odl-ovsdb-southbound-impl-ui</feature> <feature version="${openflowplugin.version}">odl-openflowplugin-flow-services</feature> <feature version="${openflowplugin.version}">odl-openflowplugin-nxm-extensions</feature> <!-- <bundle>mvn:org.opendaylight.ovsdb/utils.servicehelper/${ovsdb.utils.servicehelper.version}</bundle> <bundle>mvn:org.opendaylight.ovsdb/openstack.net-virt/${openstack.netvirt.version}</bundle> <bundle>mvn:org.opendaylight.ovsdb/openstack.net-virt-providers/${openstack.netvirt.providers.version}</bundle> <configfile finalname="etc/opendaylight/karaf/netvirt-impl-default-config.xml">mvn:org.opendaylight.ovsdb/openstack.net-virt/${project.version}/xml/config</configfile> <configfile finalname="etc/opendaylight/karaf/netvirt-providers-impl-default-config.xml">mvn:org.opendaylight.ovsdb/openstack.net-virt-providers/${project.version}/xml/config</configfile> --> </feature>
-----Original Message----- From: Khaldoon Al Zoubi Sent: Thursday, June 25, 2015 3:45 PM To: 'Sam Hague' Cc: ovsdb-dev@... Subject: RE: [ovsdb-dev] ODL Inventory
Thanks Sam. Actually, this what I thought I need to do (only include odl-ovsdb-southbound-impl in my features.xml), but I am not sure what part I am missing. I believe the devstack & ODL connection works since I am able to see neutron elements in datastore when executing commands like (neutron net-create net-1). So feature odl-neutron-service works.
However, when I am running ODL purely from the OVSDB project it works and I can see the operational nodes. So, I am missing something in my project.
Thanks Sam as always.
Regards, Khal
-----Original Message----- From: Sam Hague [mailto:shague@...] Sent: Thursday, June 25, 2015 2:41 PM To: Khaldoon Al Zoubi Cc: ovsdb-dev@... Subject: Re: [ovsdb-dev] ODL Inventory
Khal,
the OVSDB southbound plugin [1] will populate the topology with the ovsdb node information, including the bridges and ports. With devstack as part of the local.conf config the ODL address is specified. In the final steps of the stack.sh the OVSDB Manager entry is set to that address and the OVSDB nodes will connect to ODL. The OVSDB southbound plugin will see that connection and begin to populate the MDSAL operational datastore - stores the node, the bridge, the ports as termination points.
From there the netvirt [2] application listens for the operational updates. netvirt also listens on the neutron events coming from the northbound side. With these two sets of events netvirt will satisfy the neutron requests.
The openflow nodes inventory is populated via the openflowplugin. When the OVSDB nodes connect and netvirt sees that it will create the required bridges, i.e, br-int, and then set the Controller address. Those bridges will then connect to ODL openflowplugin port and openflowplugin will add the switches to the inventory.
So you just need the odl-ovsdb-southbound-impl or odl-ovsdb-southbound-impl-ui feature to get the southbound plugin which will get the inventory for you.
Thanks, Sam
[1] ovsdb/southbound/southbound-impl [2] ovsdb/openstack
----- Original Message -----
From: "Khaldoon Al Zoubi" <khaldoon.alzoubi@...> To: ovsdb-dev@... Sent: Thursday, June 25, 2015 12:15:05 PM Subject: [ovsdb-dev] ODL Inventory
Hi,
I can’t figure out how OVSDB populate ODL Inventory based on openstack (i.e. specifically after ./stack.sh is complete). Also, is there a feature I can include in my project to do that.
Thanks much.
Khal
_______________________________________________ ovsdb-dev mailing list ovsdb-dev@... https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
|
|
Khal,
the openstack modules do not write anything to operational. It relies on the southbound to do that and openstack listens for those changes when they happen. After that the openstack netvirt modules will do things like add bridges, but it is the southbound which will update the operational topology. If you are looking for the openflow nodes, then the openflowplugin does that (look in the earlier email where I mentioned that)
1. Did you verify the southbound feature loaded? feature:list -i | grep ovsdb. look for southbound. 2. Try the postman calls. look in the ovsdb/resources/commons dir for the southbound postman. Use the "Get config topology" and "get operational topology" restconf calls and see if you get the ovsdb:1 node. 3. Add the ovs-vsctl set-manager tcp:<odlip>:6640 and verify if the ovsdb node connected to odl, ovs-vsctl show. 4. Then try the postman calls again to see if the node shows up.
Sam
toggle quoted messageShow quoted text
----- Original Message ----- From: "Khaldoon Al Zoubi" <khaldoon.alzoubi@...> To: "Sam Hague" <shague@...> Cc: ovsdb-dev@... Sent: Tuesday, June 30, 2015 12:27:13 PM Subject: RE: [ovsdb-dev] ODL Inventory
Hi Sam,
I commented out the openstack bundles in odl-ovsdb-openstack (please see below) to test if odl-ovsdb-southbound-impl-ui will be able to load the inventory operational node into datastore. Well, it didn't do it. Is that mean that the openstack bundles are doing extra work to populate the inventory? Thanks.
-------- <feature name="odl-ovsdb-openstack" description="OpenDaylight :: OVSDB :: OpenStack Network Virtualization" version='${openstack.netvirt.version}'> <feature version='${mdsal.version}'>odl-mdsal-broker</feature> <feature version="${openflowplugin.version}">odl-openflowplugin-nsf-model</feature> <feature version="${networkconfig.neutron.version}">odl-neutron-service</feature> <feature version="1.1.0-SNAPSHOT">odl-ovsdb-southbound-impl-ui</feature> <feature version="${openflowplugin.version}">odl-openflowplugin-flow-services</feature> <feature version="${openflowplugin.version}">odl-openflowplugin-nxm-extensions</feature> <!-- <bundle>mvn:org.opendaylight.ovsdb/utils.servicehelper/${ovsdb.utils.servicehelper.version}</bundle> <bundle>mvn:org.opendaylight.ovsdb/openstack.net-virt/${openstack.netvirt.version}</bundle> <bundle>mvn:org.opendaylight.ovsdb/openstack.net-virt-providers/${openstack.netvirt.providers.version}</bundle> <configfile finalname="etc/opendaylight/karaf/netvirt-impl-default-config.xml">mvn:org.opendaylight.ovsdb/openstack.net-virt/${project.version}/xml/config</configfile> <configfile finalname="etc/opendaylight/karaf/netvirt-providers-impl-default-config.xml">mvn:org.opendaylight.ovsdb/openstack.net-virt-providers/${project.version}/xml/config</configfile> --> </feature>
-----Original Message----- From: Khaldoon Al Zoubi Sent: Thursday, June 25, 2015 3:45 PM To: 'Sam Hague' Cc: ovsdb-dev@... Subject: RE: [ovsdb-dev] ODL Inventory
Thanks Sam. Actually, this what I thought I need to do (only include odl-ovsdb-southbound-impl in my features.xml), but I am not sure what part I am missing. I believe the devstack & ODL connection works since I am able to see neutron elements in datastore when executing commands like (neutron net-create net-1). So feature odl-neutron-service works.
However, when I am running ODL purely from the OVSDB project it works and I can see the operational nodes. So, I am missing something in my project.
Thanks Sam as always.
Regards, Khal
-----Original Message----- From: Sam Hague [mailto:shague@...] Sent: Thursday, June 25, 2015 2:41 PM To: Khaldoon Al Zoubi Cc: ovsdb-dev@... Subject: Re: [ovsdb-dev] ODL Inventory
Khal,
the OVSDB southbound plugin [1] will populate the topology with the ovsdb node information, including the bridges and ports. With devstack as part of the local.conf config the ODL address is specified. In the final steps of the stack.sh the OVSDB Manager entry is set to that address and the OVSDB nodes will connect to ODL. The OVSDB southbound plugin will see that connection and begin to populate the MDSAL operational datastore - stores the node, the bridge, the ports as termination points.
From there the netvirt [2] application listens for the operational updates. netvirt also listens on the neutron events coming from the northbound side. With these two sets of events netvirt will satisfy the neutron requests.
The openflow nodes inventory is populated via the openflowplugin. When the OVSDB nodes connect and netvirt sees that it will create the required bridges, i.e, br-int, and then set the Controller address. Those bridges will then connect to ODL openflowplugin port and openflowplugin will add the switches to the inventory.
So you just need the odl-ovsdb-southbound-impl or odl-ovsdb-southbound-impl-ui feature to get the southbound plugin which will get the inventory for you.
Thanks, Sam
[1] ovsdb/southbound/southbound-impl [2] ovsdb/openstack
----- Original Message -----
From: "Khaldoon Al Zoubi" <khaldoon.alzoubi@...> To: ovsdb-dev@... Sent: Thursday, June 25, 2015 12:15:05 PM Subject: [ovsdb-dev] ODL Inventory
Hi,
I can’t figure out how OVSDB populate ODL Inventory based on openstack (i.e. specifically after ./stack.sh is complete). Also, is there a feature I can include in my project to do that.
Thanks much.
Khal
_______________________________________________ ovsdb-dev mailing list ovsdb-dev@... https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
|
|
Khaldoon Al Zoubi <khaldoon.alzoubi@...>
Hi Sam,
I commented out the openstack bundles in odl-ovsdb-openstack (please see below) to test if odl-ovsdb-southbound-impl-ui will be able to load the inventory operational node into datastore. Well, it didn't do it. Is that mean that the openstack bundles are doing extra work to populate the inventory? Thanks.
-------- <feature name="odl-ovsdb-openstack" description="OpenDaylight :: OVSDB :: OpenStack Network Virtualization" version='${openstack.netvirt.version}'> <feature version='${mdsal.version}'>odl-mdsal-broker</feature> <feature version="${openflowplugin.version}">odl-openflowplugin-nsf-model</feature> <feature version="${networkconfig.neutron.version}">odl-neutron-service</feature> <feature version="1.1.0-SNAPSHOT">odl-ovsdb-southbound-impl-ui</feature> <feature version="${openflowplugin.version}">odl-openflowplugin-flow-services</feature> <feature version="${openflowplugin.version}">odl-openflowplugin-nxm-extensions</feature> <!-- <bundle>mvn:org.opendaylight.ovsdb/utils.servicehelper/${ovsdb.utils.servicehelper.version}</bundle> <bundle>mvn:org.opendaylight.ovsdb/openstack.net-virt/${openstack.netvirt.version}</bundle> <bundle>mvn:org.opendaylight.ovsdb/openstack.net-virt-providers/${openstack.netvirt.providers.version}</bundle> <configfile finalname="etc/opendaylight/karaf/netvirt-impl-default-config.xml">mvn:org.opendaylight.ovsdb/openstack.net-virt/${project.version}/xml/config</configfile> <configfile finalname="etc/opendaylight/karaf/netvirt-providers-impl-default-config.xml">mvn:org.opendaylight.ovsdb/openstack.net-virt-providers/${project.version}/xml/config</configfile> --> </feature>
toggle quoted messageShow quoted text
-----Original Message----- From: Khaldoon Al Zoubi Sent: Thursday, June 25, 2015 3:45 PM To: 'Sam Hague' Cc: ovsdb-dev@... Subject: RE: [ovsdb-dev] ODL Inventory Thanks Sam. Actually, this what I thought I need to do (only include odl-ovsdb-southbound-impl in my features.xml), but I am not sure what part I am missing. I believe the devstack & ODL connection works since I am able to see neutron elements in datastore when executing commands like (neutron net-create net-1). So feature odl-neutron-service works. However, when I am running ODL purely from the OVSDB project it works and I can see the operational nodes. So, I am missing something in my project. Thanks Sam as always. Regards, Khal -----Original Message----- From: Sam Hague [mailto:shague@...] Sent: Thursday, June 25, 2015 2:41 PM To: Khaldoon Al Zoubi Cc: ovsdb-dev@... Subject: Re: [ovsdb-dev] ODL Inventory Khal, the OVSDB southbound plugin [1] will populate the topology with the ovsdb node information, including the bridges and ports. With devstack as part of the local.conf config the ODL address is specified. In the final steps of the stack.sh the OVSDB Manager entry is set to that address and the OVSDB nodes will connect to ODL. The OVSDB southbound plugin will see that connection and begin to populate the MDSAL operational datastore - stores the node, the bridge, the ports as termination points. From there the netvirt [2] application listens for the operational updates. netvirt also listens on the neutron events coming from the northbound side. With these two sets of events netvirt will satisfy the neutron requests. The openflow nodes inventory is populated via the openflowplugin. When the OVSDB nodes connect and netvirt sees that it will create the required bridges, i.e, br-int, and then set the Controller address. Those bridges will then connect to ODL openflowplugin port and openflowplugin will add the switches to the inventory. So you just need the odl-ovsdb-southbound-impl or odl-ovsdb-southbound-impl-ui feature to get the southbound plugin which will get the inventory for you. Thanks, Sam [1] ovsdb/southbound/southbound-impl [2] ovsdb/openstack ----- Original Message ----- From: "Khaldoon Al Zoubi" <khaldoon.alzoubi@...> To: ovsdb-dev@... Sent: Thursday, June 25, 2015 12:15:05 PM Subject: [ovsdb-dev] ODL Inventory
Hi,
I can’t figure out how OVSDB populate ODL Inventory based on openstack (i.e. specifically after ./stack.sh is complete). Also, is there a feature I can include in my project to do that.
Thanks much.
Khal
_______________________________________________ ovsdb-dev mailing list ovsdb-dev@... https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
|
|
OVSDB hardware vtep support
Kamat, Maruti Haridas <maruti.kamat@...>
Dear All,
Please find attached the L2 gateway slides.
Blueprint:
Demo:
Thanks,
Maruti
|
|
Re: [neutron-dev] changes for neutron project in Be to support l2-gw
Sam, if you add this as an item to [1], then we'll get it the next meeting.
Ryan
[1] https://wiki.opendaylight.org/view/NeutronNorthbound:FutureReleaseWishList
neutron-dev-bounces@... wrote on 06/30/2015 10:39:34 AM:
> From: Sam Hague <shague@...>
> To: Ravindra Kenchappa <ravindra.kenchappa@...>,
> maruti.kamat@..., Dayavanti Gopal Kamath
> <dayavanti.gopal.kamath@...>, ovsdb-dev <ovsdb-
> dev@...>, neutron-dev@...
> Date: 06/30/2015 10:39 AM
> Subject: [neutron-dev] changes for neutron project in Be to support l2-gw
> Sent by: neutron-dev-bounces@...
>
> Ryan, Flavio, Ed,
>
> I wanted to start the conversation for adding support for l2-gw [1].
> The l2-gw is a service plugin in neutron that has been included with
> kilo. We would need to add some changes to neutron to receive the
> new l2-gw rest calls [2] - something similar to including services
> like LBaaS. We would also need to add the corresponding YANG so the
> data is written to the neutron mdsal.
>
> Should we bring this up in the weekly neutron meeting on Friday? Or
> schedule an alternate time?
>
> Thanks, Sam
>
>
> [1] https://wiki.openstack.org/wiki/Neutron/L2-GW
> [2] https://review.openstack.org/#/c/144173/3/specs/kilo/l2-gateway-api.rst
> _______________________________________________
> neutron-dev mailing list
> neutron-dev@...
> https://lists.opendaylight.org/mailman/listinfo/neutron-dev
>
|
|
changes for neutron project in Be to support l2-gw
Ryan, Flavio, Ed, I wanted to start the conversation for adding support for l2-gw [1]. The l2-gw is a service plugin in neutron that has been included with kilo. We would need to add some changes to neutron to receive the new l2-gw rest calls [2] - something similar to including services like LBaaS. We would also need to add the corresponding YANG so the data is written to the neutron mdsal. Should we bring this up in the weekly neutron meeting on Friday? Or schedule an alternate time? Thanks, Sam [1] https://wiki.openstack.org/wiki/Neutron/L2-GW[2] https://review.openstack.org/#/c/144173/3/specs/kilo/l2-gateway-api.rst
|
|
Re: OVSDB hardware vtep support
Hi Ravi/Maruthi,
Flow wise it looks good to me.
Need minor clarification, with the current design are we assuming that connection management and table modification on hardware vtep will be done by separate (new) southbound plugin, rather then existing ovsdb southbound plugin?
Anil
toggle quoted messageShow quoted text
On Tue, Jun 30, 2015 at 12:21 AM, Sam Hague <shague@...> wrote:
----- Forwarded Message -----
> From: "Ravindra Kenchappa" <ravindra.kenchappa@...>
> To: "Dayavanti Gopal Kamath" <dayavanti.gopal.kamath@...>, "Hema Gopalkrishnan"
> <hema.gopalkrishnan@...>, "Vishal Thapar" <vishal.thapar@...>, "Aswin Suryanarayanan"
> <aswin.suryanarayanan@...>, "Anil Vishnoi" <vishnoianil@...>, "Flavio Fernandes" <ffernand@...>,
> "Sam Hague" <shague@...>, "Chris Wright" <chrisw@...>, "Kyle Mestery" <mestery@...>, "Prem
> sankar G" <prem.sankar.g@...>, "Abhijit Kumbhare" <abhijit.kumbhare@...>, "Ravi Sundareswaran"
> <ravi.sundareswaran@...>, "Maruti Haridas Kamat" <maruti.kamat@...>, "Swaminathan Vasudevan (PNB
> Roseville)" <swaminathan.vasudevan@...>, "afredette@..." <afredette@...>, "Ravi Sabapathy"
> <Ravi_Sabapathy@...>, "Yapeng Wu" <Yapeng.Wu@...>, sumit@...
> Sent: Friday, June 26, 2015 6:03:57 AM
> Subject: RE: OVSDB hardware vtep support
>
> Hi All,
>
> This is regarding the ODL hardware l2gateway implementations. Myself and
> Maruti tried to put together a high level architecture diagram and tried to
> explain as we understand. Please take a look and we can discuss on any
> comments/suggestions in our Tuesday's meeting coming week. Also Maruti
> and I are planning to talk about how the hardware l2 gateway feature is
> implemented in Kilo.
>
>
>
> Discover and establish connection with hardware VTEP:
>
> * ODL OVSDB plug-in will establish an active connection with the device
> running ovsdb-server and hw_vtep model in MD-SAL data store is updated. (1)
> * Neutron administrator creates an l2-gateway (abstraction of hardware
> gateway and its ports/interfaces) - logical resource in neutron.
> * Neutron administrator creates a VXLAN network.
> * Neutron administrator creates an l2-gateway-connection (binding of
> the virtual network with the l2-gateway logical resource)
> * The call lands into the L2gw service plugin.
> * The L2gw service plugin invokes the l2gw-ODL driver and makes REST
> call to the ODL controller
> * The ODL controller validates the request against the data present in
> the datastore (whether such hardware gateway and such ports really exist).
> * ODL northbound REST API also reads the gateway configuration and
> updates the hardware_vtep yang model in MD-SAL data store.
> * onDatachanged event will be generated and the OVSDB net-virt should
> determine ( in MD-SAL data store) the compute nodes which is hosting the
> virtual ports and VM macaddress associated to these virtual ports in
> gateway configuration. Once all the necessary information is available
> appropriated tables of hardware_vtep yang model in MD-SAL data store should
> be updated.
> * Neutron yang should be updated and onDatachanged event will be
> generated which will be consumed by netvirt.
> * OnDataChanged OVSDB Southbound plugin should process the
> NorthBoundevent and using OVSDB library the appropriate tables in the device
> hw_vtep should be updated so that VXLAN tunnel between the hw_vtep and the
> compute node will be created. Also VNI<->VLAN binding should be updated on
> the device's hw_vtep so that VNI <-> VLAN cross-connect configuration will
> be done by the device based on the hw_vtep table updates.
> * When a VM is spawned on the neutron side, the VMs details (like IP,
> MAC, compute node VTEP IP) is sent by the ODL ML2 plugin to the ODL North
> Bound.
> * The ODL OVSDB soutbound plugin updates the OVSDB hardware schema
> tables the hardware gateway creates a VXLAN tunnel to the compute node based
> on this information.
> * Whenever a new bare metal server is discovered on the port (for which
> VXLAN-VLAN mapping exists), the ODL southbound plugin contacts the compute
> node OVS tunnel bridge to create a reverse VXLAN tunnel to the hardware
> VTEP.
> * OVSDB southbound plug-in should also create VXLAN tunnel on the
> compute node whose ports are participating in the gateway configuration.
> * With this configuration bare metals(BM) on the physical
> infrastructure (underlay) and virtual machines (VM) on the overlay can
> participate in the same l2 domain.
>
> Thanks,
> Ravi / Maruti
>
>
> -----Original Appointment-----
> From: Dayavanti Gopal Kamath [mailto: dayavanti.gopal.kamath@...]
> Sent: Monday, June 22, 2015 9:18 PM
> To: Hema Gopalkrishnan; Vishal Thapar; Kenchappa, Ravindra; Suryanarayanan,
> Aswin; 'Anil Vishnoi'; 'Flavio Fernandes'; 'Sam Hague'; 'Chris Wright';
> 'Kyle Mestery'; Prem sankar G; Abhijit Kumbhare; Ravi Sundareswaran; Kamat,
> Maruti Haridas; Vasudevan, Swaminathan (PNB Roseville);
> ' afredette@...'; Ravi_Sabapathy@...; Yapeng.Wu@...;
> sumit@...
> Subject: OVSDB hardware vtep support
> When: Tuesday, June 23, 2015 7:30 PM-8:30 PM (UTC+05:30) Chennai, Kolkata,
> Mumbai, New Delhi.
> Where: tbd
>
>
> All,
> Looking to hold ongoing meetings in the community forum at 7 am PST on
> Tuesdays. Abhijit will send out an invite with the webex details as soon as
> phil robb sets it up. If it doesn't come through for tomorrow, we can use
> the Ericsson conference. Unfortunately, I cannot post the conf number on the
> mailing list, I will share it with this group. So in case we do use it, will
> request you to forward the invite to whoever else interested.
>
> Thanks!
> daya
>
>
>
_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
|
|
initial hardware_vtep wiki and Trello updates
Hi all, the project wiki for hardware_vtep is at [1]. Feel free to add to the wiki as more information is developed or useful. Some of the work items for the OVSDB side of hardware_vtep are included in the OVSDB Beryllium Trello board [2]. The items are high-level and viewed as epics with the expectation that the owners of those cards will add a checklist of more granular items so that we can track them more easily. Notice that all the hardware_vtep cards are prefixed with HWVTEP. Also check [2] below to see if you are a member of the Be Trello board. If not, send me your email address or Trello username and I will add you. Thanks, Sam [1] https://wiki.opendaylight.org/view/OVSDB:Hardware_VTEP[2] https://trello.com/b/FJAa9wyl/ovsdb-beryllium
|
|
OVSDB hardware vtep support
----- Forwarded Message -----
toggle quoted messageShow quoted text
From: "Ravindra Kenchappa" <ravindra.kenchappa@...> To: "Dayavanti Gopal Kamath" <dayavanti.gopal.kamath@...>, "Hema Gopalkrishnan" <hema.gopalkrishnan@...>, "Vishal Thapar" <vishal.thapar@...>, "Aswin Suryanarayanan" <aswin.suryanarayanan@...>, "Anil Vishnoi" <vishnoianil@...>, "Flavio Fernandes" <ffernand@...>, "Sam Hague" <shague@...>, "Chris Wright" <chrisw@...>, "Kyle Mestery" <mestery@...>, "Prem sankar G" <prem.sankar.g@...>, "Abhijit Kumbhare" <abhijit.kumbhare@...>, "Ravi Sundareswaran" <ravi.sundareswaran@...>, "Maruti Haridas Kamat" <maruti.kamat@...>, "Swaminathan Vasudevan (PNB Roseville)" <swaminathan.vasudevan@...>, "afredette@..." <afredette@...>, "Ravi Sabapathy" <Ravi_Sabapathy@...>, "Yapeng Wu" <Yapeng.Wu@...>, sumit@... Sent: Friday, June 26, 2015 6:03:57 AM Subject: RE: OVSDB hardware vtep support
Hi All,
This is regarding the ODL hardware l2gateway implementations. Myself and Maruti tried to put together a high level architecture diagram and tried to explain as we understand. Please take a look and we can discuss on any comments/suggestions in our Tuesday's meeting coming week. Also Maruti and I are planning to talk about how the hardware l2 gateway feature is implemented in Kilo.
Discover and establish connection with hardware VTEP:
* ODL OVSDB plug-in will establish an active connection with the device running ovsdb-server and hw_vtep model in MD-SAL data store is updated. (1) * Neutron administrator creates an l2-gateway (abstraction of hardware gateway and its ports/interfaces) - logical resource in neutron. * Neutron administrator creates a VXLAN network. * Neutron administrator creates an l2-gateway-connection (binding of the virtual network with the l2-gateway logical resource) * The call lands into the L2gw service plugin. * The L2gw service plugin invokes the l2gw-ODL driver and makes REST call to the ODL controller * The ODL controller validates the request against the data present in the datastore (whether such hardware gateway and such ports really exist). * ODL northbound REST API also reads the gateway configuration and updates the hardware_vtep yang model in MD-SAL data store. * onDatachanged event will be generated and the OVSDB net-virt should determine ( in MD-SAL data store) the compute nodes which is hosting the virtual ports and VM macaddress associated to these virtual ports in gateway configuration. Once all the necessary information is available appropriated tables of hardware_vtep yang model in MD-SAL data store should be updated. * Neutron yang should be updated and onDatachanged event will be generated which will be consumed by netvirt. * OnDataChanged OVSDB Southbound plugin should process the NorthBoundevent and using OVSDB library the appropriate tables in the device hw_vtep should be updated so that VXLAN tunnel between the hw_vtep and the compute node will be created. Also VNI<->VLAN binding should be updated on the device's hw_vtep so that VNI <-> VLAN cross-connect configuration will be done by the device based on the hw_vtep table updates. * When a VM is spawned on the neutron side, the VMs details (like IP, MAC, compute node VTEP IP) is sent by the ODL ML2 plugin to the ODL North Bound. * The ODL OVSDB soutbound plugin updates the OVSDB hardware schema tables the hardware gateway creates a VXLAN tunnel to the compute node based on this information. * Whenever a new bare metal server is discovered on the port (for which VXLAN-VLAN mapping exists), the ODL southbound plugin contacts the compute node OVS tunnel bridge to create a reverse VXLAN tunnel to the hardware VTEP. * OVSDB southbound plug-in should also create VXLAN tunnel on the compute node whose ports are participating in the gateway configuration. * With this configuration bare metals(BM) on the physical infrastructure (underlay) and virtual machines (VM) on the overlay can participate in the same l2 domain.
Thanks, Ravi / Maruti
-----Original Appointment----- From: Dayavanti Gopal Kamath [mailto:dayavanti.gopal.kamath@...] Sent: Monday, June 22, 2015 9:18 PM To: Hema Gopalkrishnan; Vishal Thapar; Kenchappa, Ravindra; Suryanarayanan, Aswin; 'Anil Vishnoi'; 'Flavio Fernandes'; 'Sam Hague'; 'Chris Wright'; 'Kyle Mestery'; Prem sankar G; Abhijit Kumbhare; Ravi Sundareswaran; Kamat, Maruti Haridas; Vasudevan, Swaminathan (PNB Roseville); 'afredette@...'; Ravi_Sabapathy@...; Yapeng.Wu@...; sumit@... Subject: OVSDB hardware vtep support When: Tuesday, June 23, 2015 7:30 PM-8:30 PM (UTC+05:30) Chennai, Kolkata, Mumbai, New Delhi. Where: tbd
All, Looking to hold ongoing meetings in the community forum at 7 am PST on Tuesdays. Abhijit will send out an invite with the webex details as soon as phil robb sets it up. If it doesn't come through for tomorrow, we can use the Ericsson conference. Unfortunately, I cannot post the conf number on the mailing list, I will share it with this group. So in case we do use it, will request you to forward the invite to whoever else interested.
Thanks! daya
|
|
|
|
Hi Flavio,
Responses inline.
|
|
Re: [controller-dev] Flows, Ports and Networks are not being removed from ODL with Neutron
toggle quoted messageShow quoted text
----- Original Message ----- From: "Simhon Doctori שמחון דוקטורי" <simhond@...> To: "Sharon Aicler (saichler)" <saichler@...> Cc: sharonaz@..., controller-dev@..., yossi@... Sent: Sunday, June 28, 2015 7:21:38 AM Subject: Re: [controller-dev] Flows, Ports and Networks are not being removed from ODL with Neutron
Thanks, I will try an earlier release of ODL (such as 0.2.3) and see if same issue happens there.
I guess the tuntap interfaces on the hypervisor are up to the nova to create/remove them using the qemu plugin.
On Sun, Jun 28, 2015 at 2:15 PM, Sharon Aicler (saichler) < saichler@... > wrote:
Hi, For flows to be added and removed there should be some integration between the ovsdb & openflowplugin. I do not know if it exist in lithium, hence I would raise the question to the ovsdb mailer... but AFAIK the way ODL works is that the flows, ports & bridges should be added via ovsdb plugin for them to be removed by ovsdb. If neutron is the one adding them then they will be missing from the configuration store, hence ODL will not be able to remove them as they are just in the operational store... Another thought comes to my mind is who removes the tuntap interfaces on the OVS side? Im guessing OVSDB plugin can remove bridges & ports from OVS, but who removes the tuntap interfaces from the vm/machine hosting the OVS?
Sent from my Android phone using TouchDown ( www.nitrodesk.com )
-----Original Message----- From: Simhon Doctori שמחון דוקטורי [ simhond@... ] Received: Sunday, 28 Jun 2015, 3:46 To: Sharon Aicler (saichler) [ saichler@... ] CC: controller-dev@... [ controller-dev@... ]; sharonaz@... [ sharonaz@... ]; yossi@... [ yossi@... ] Subject: Re: [controller-dev] Flows, Ports and Networks are not being removed from ODL with Neutron
Thanks Sharon,
I will check it for the ports and networks but does the removal of the flows should also be originated from the ovsdb <--> neutron ?
Simhon.
On Sun, Jun 28, 2015 at 12:42 PM, Sharon Aicler (saichler) < saichler@... > wrote:
Hi, I think the ovsdb mailer is a better place to ask this question...
Sent from my Android phone using TouchDown ( www.nitrodesk.com )
-----Original Message----- From: Simhon Doctori שמחון דוקטורי [ simhond@... ] Received: Sunday, 28 Jun 2015, 2:26 To: controller-dev@... [ controller-dev@... ] CC: sharonaz@... [ sharonaz@... ]; yossi barshishat יוסי ברששת [ yossi@... ] Subject: [controller-dev] Flows, Ports and Networks are not being removed from ODL with Neutron
Hi,
We are working with Devstack of integration ODL Helium and Icehouse Openstack taken from: https://wiki.opendaylight.org/view/OVSDB:Helium_and_Openstack_on_Fedora20#VMs .
All works well, but when we remove a VM using the nova delete, or even remove the entire network using neutron, nothing is removed neither from the OVS nor from the ODL itself.
It looks like ODL disregards neutron remove requests for some reason. Is this a known problem for these releases ( distribution-karaf-0.2.1-Helium-SR and Icehouese ) ?
Any option to make it works ?
Should it be working is latest Opendaylight release ?
-- Regards,
Simhon.
-- Regards,
Simhon.
-- Regards,
Simhon.
_______________________________________________ controller-dev mailing list controller-dev@... https://lists.opendaylight.org/mailman/listinfo/controller-dev
|
|
Flows, Ports and Networks are not being removed from ODL with Neutron
Simhon Doctori שמחון דוקטורי <simhond@...>
Hi,
All works well, but when we remove a VM using the nova delete, or even remove the entire network using neutron, nothing is removed neither from the OVS nor from the ODL itself.
It looks like ODL disregards neutron remove requests for some reason. Is this a known problem for these releases ( distribution-karaf-0.2.1-Helium-SR and Icehouese ) ?
Any option to make it works ?
Should it be working is latest Opendaylight release ?
--
|
|
Flavio Fernandes <ffernand@...>
[cc’ing odl neutron-dev ovsdb-dev]
Hi Armando,
Sam ran into a snag while trying to use lithium against stable kilo. The issue is 2 fold:
A) there is no stable/kilo branch for networking-odl;
B) the changes you did in neutron for security group callback [armandoSg] is in neutron master, but not in stable/kilo. Because of that, stack fails with [fail].
I think we can handle (A) somewhat easily, right? I know we have a tag (1.0.0a0) and my thinking is that all we need is to create stable/kilo off of that. And potentially neuter sg like this [neuterSg]. Not an ideal solution.
For (B), we would like to hear from you… Is it possible at all to cherry pick [armandoSg] to neutron’s stable/kilo ? If not, it won’t be until liberty that ODL can use SG. Another nefarious idea would be to fork neutron and create a /stable/kilo/odl branch in github and explicitly use that via $NEUTRON_REPO. If we did that, we would have the SG goodness in lithium while using a stable/kilo and not need [neuterSg].
Your thoughts, please!
— flavio
[fail]: CRITICAL neutron [-] AttributeError: 'module' object has no attribute 'SECURITY_GROUP'
[armandoSg]:
commit 2e95d196504e011e451fc8777392a0d6e1b7cec6 Date: Thu Apr 16 12:45:32 2015 -0700
Add security groups events
ML2 mech drivers have no direct exposure to security groups, and they can only infer them from the associated network/ports. This is problematic as agentless ML2 mech drivers have no way of intercepting securitygroups events and propagate the information to their backend, or more generally, react to them.
This patch leverages the callback registry to dispatch such events so that interested ML2 mech drivers (or any interested party like service plugins) can be notified and react accordingly.
This patch addresses create/update/delete of security groups and create/delete of security groups rules. Other events may be added over time, if need be.
This patch is only about emitting the events. The actual subscription and implementation of the event handlers will have to take place where deemed appropriate.
Closes-bug: #1444112
Change-Id: Ifa1d7ee9c967576f824f1129dd68e6e3abd48f5c
|
|
Re: [sfc-dev] [release] New project build cycle between sfc and ovsdb?
Presumably it also wants to be cherry-picked to stable/lithium (and maybe stable/helium). --Colin
toggle quoted messageShow quoted text
On Fri, Jun 26, 2015 at 12:42 PM, Reinaldo Penno <rapenno@...> wrote:
|
|