Date   

Re: Nominate Anil Vishnoi as OVSDB committer

Flavio Fernandes <ffernand@...>
 

+1 from flaviof on having Anil aboard!

— flavio

On Apr 29, 2015, at 2:52 PM, Sam Hague <shague@...> wrote:

I would like to nominate Anil Vishnoi as committer to the OVSDB project. Current committers, please respond with a vote for the nomination.

Anil has been working on all the areas in the OVSDB project:
- worked on the adsal deprecation that required learning all the code in OVSDB
- added an adsal compatibility layer for the plugin
- added different parts of the southbound
- working on migrating netvirt to the southbound

Thanks, Sam


Nominate Anil Vishnoi as OVSDB committer

Sam Hague
 

I would like to nominate Anil Vishnoi as committer to the OVSDB project. Current committers, please respond with a vote for the nomination.

Anil has been working on all the areas in the OVSDB project:
- worked on the adsal deprecation that required learning all the code in OVSDB
- added an adsal compatibility layer for the plugin
- added different parts of the southbound
- working on migrating netvirt to the southbound

Thanks, Sam


OVSDB Lithium Release Investigation

LNT-OpenDayLight
 

Hi,

We would like to know OVSDB lithium release.  We would like to know the following details.

・ Abstract network virt. from OVSDB library and plugin
・ Remove AD-SAL dependencie
・ Support existing OVSDB plugin interface for VTN
・ Add MD-SAL southbound plugin
・ Migrate network virt. to MD-SAL southbound plugin
・ Test and improve scale, stability and performance
・ Close feature gap with Neutron and OpenStack OVSplugin, e.g., L3, LBaaS, FWaaS, VPNaaS

Please share the available information.

Thanks & Regards,
lnt


Looking for Review - Overlay Topology - OVSDB Southbound

Koontz, Marcus G <marcus.g.koontz@...>
 

I'd love to get some feedback on this:
https://git.opendaylight.org/gerrit/#/c/18127/

Thanks,
/** Marcus */


Re: ovsdb error

Vinllen Chen <cvinllen@...>
 

Sorry, i sent to the wrong mailing list address!!!

On Mon, Apr 27, 2015 at 7:46 PM, Vinllen Chen <cvinllen@...> wrote:
Hi, Dear all:
    My ovs was ok before, but recently, my ovs got an error when i add-port in bridge:
ovs-vsctl add-br br0
ovs-vsctl add-port br0 port0
ovs-vsctl: Error detected while setting up 'port0'.  See ovs-vswitchd log for details.

My ovs version is 2.3.90, the problem cannot be resloved even when i reinstall the ovs. The log in the /var/log/openvswitch/ovs-vswitchd.log show :

2015-04-27T11:38:15.746Z|00001|vlog|INFO|opened log file /var/log/openvswitch/ovs-vswitchd.log
2015-04-27T11:38:15.749Z|00002|ovs_numa|INFO|Discovered 4 CPU cores on NUMA node 0
2015-04-27T11:38:15.749Z|00003|ovs_numa|INFO|Discovered 1 NUMA nodes and 4 CPU cores
2015-04-27T11:38:15.749Z|00004|reconnect|INFO|unix:/var/run/openvswitch/db.sock: connecting...
2015-04-27T11:38:15.749Z|00005|reconnect|INFO|unix:/var/run/openvswitch/db.sock: connected
2015-04-27T11:38:15.750Z|00006|ovsdb_idl|WARN|Open_vSwitch database lacks AutoAttach table (database needs upgrade?)
2015-04-27T11:38:15.750Z|00007|ovsdb_idl|WARN|Bridge table in Open_vSwitch database lacks auto_attach column (database needs upgrade?)
2015-04-27T11:38:15.750Z|00008|ovsdb_idl|WARN|Bridge table in Open_vSwitch database lacks datapath_version column (database needs upgrade?)
2015-04-27T11:38:15.750Z|00009|ovsdb_idl|WARN|Bridge table in Open_vSwitch database lacks mcast_snooping_enable column (database needs upgrade?)
2015-04-27T11:38:15.750Z|00010|ovsdb_idl|WARN|Bridge table in Open_vSwitch database lacks rstp_enable column (database needs upgrade?)
2015-04-27T11:38:15.750Z|00011|ovsdb_idl|WARN|Bridge table in Open_vSwitch database lacks rstp_status column (database needs upgrade?)
2015-04-27T11:38:15.750Z|00012|ovsdb_idl|WARN|Flow_Table table in Open_vSwitch database lacks external_ids column (database needs upgrade?)
2015-04-27T11:38:15.750Z|00013|ovsdb_idl|WARN|Flow_Table table in Open_vSwitch database lacks prefixes column (database needs upgrade?)
2015-04-27T11:38:15.750Z|00014|ovsdb_idl|WARN|IPFIX table in Open_vSwitch database lacks other_config column (database needs upgrade?)
2015-04-27T11:38:15.750Z|00015|ovsdb_idl|WARN|Interface table in Open_vSwitch database lacks cfm_flap_count column (database needs upgrade?)
2015-04-27T11:38:15.750Z|00016|ovsdb_idl|WARN|Interface table in Open_vSwitch database lacks error column (database needs upgrade?)
2015-04-27T11:38:15.750Z|00017|ovsdb_idl|WARN|Interface table in Open_vSwitch database lacks lldp column (database needs upgrade?)
2015-04-27T11:38:15.750Z|00018|ovsdb_idl|WARN|Open_vSwitch table in Open_vSwitch database lacks datapath_types column (database needs upgrade?)
2015-04-27T11:38:15.750Z|00019|ovsdb_idl|WARN|Open_vSwitch table in Open_vSwitch database lacks iface_types column (database needs upgrade?)
2015-04-27T11:38:15.750Z|00020|ovsdb_idl|WARN|Port table in Open_vSwitch database lacks bond_active_slave column (database needs upgrade?)
2015-04-27T11:38:15.750Z|00021|ovsdb_idl|WARN|Port table in Open_vSwitch database lacks rstp_statistics column (database needs upgrade?)
2015-04-27T11:38:15.750Z|00022|ovsdb_idl|WARN|Port table in Open_vSwitch database lacks rstp_status column (database needs upgrade?)
2015-04-27T11:38:15.751Z|00023|bridge|INFO|ovs-vswitchd (Open vSwitch) 2.3.90
2015-04-27T11:38:27.897Z|00024|memory|INFO|7688 kB peak resident set size after 12.2 seconds

    Could anyone help me ? Great appreciate for anyone's relpy.
Best Regards,
Vinllen


ovsdb error

Vinllen Chen <cvinllen@...>
 

Hi, Dear all:
    My ovs was ok before, but recently, my ovs got an error when i add-port in bridge:
ovs-vsctl add-br br0
ovs-vsctl add-port br0 port0
ovs-vsctl: Error detected while setting up 'port0'.  See ovs-vswitchd log for details.

My ovs version is 2.3.90, the problem cannot be resloved even when i reinstall the ovs. The log in the /var/log/openvswitch/ovs-vswitchd.log show :

2015-04-27T11:38:15.746Z|00001|vlog|INFO|opened log file /var/log/openvswitch/ovs-vswitchd.log
2015-04-27T11:38:15.749Z|00002|ovs_numa|INFO|Discovered 4 CPU cores on NUMA node 0
2015-04-27T11:38:15.749Z|00003|ovs_numa|INFO|Discovered 1 NUMA nodes and 4 CPU cores
2015-04-27T11:38:15.749Z|00004|reconnect|INFO|unix:/var/run/openvswitch/db.sock: connecting...
2015-04-27T11:38:15.749Z|00005|reconnect|INFO|unix:/var/run/openvswitch/db.sock: connected
2015-04-27T11:38:15.750Z|00006|ovsdb_idl|WARN|Open_vSwitch database lacks AutoAttach table (database needs upgrade?)
2015-04-27T11:38:15.750Z|00007|ovsdb_idl|WARN|Bridge table in Open_vSwitch database lacks auto_attach column (database needs upgrade?)
2015-04-27T11:38:15.750Z|00008|ovsdb_idl|WARN|Bridge table in Open_vSwitch database lacks datapath_version column (database needs upgrade?)
2015-04-27T11:38:15.750Z|00009|ovsdb_idl|WARN|Bridge table in Open_vSwitch database lacks mcast_snooping_enable column (database needs upgrade?)
2015-04-27T11:38:15.750Z|00010|ovsdb_idl|WARN|Bridge table in Open_vSwitch database lacks rstp_enable column (database needs upgrade?)
2015-04-27T11:38:15.750Z|00011|ovsdb_idl|WARN|Bridge table in Open_vSwitch database lacks rstp_status column (database needs upgrade?)
2015-04-27T11:38:15.750Z|00012|ovsdb_idl|WARN|Flow_Table table in Open_vSwitch database lacks external_ids column (database needs upgrade?)
2015-04-27T11:38:15.750Z|00013|ovsdb_idl|WARN|Flow_Table table in Open_vSwitch database lacks prefixes column (database needs upgrade?)
2015-04-27T11:38:15.750Z|00014|ovsdb_idl|WARN|IPFIX table in Open_vSwitch database lacks other_config column (database needs upgrade?)
2015-04-27T11:38:15.750Z|00015|ovsdb_idl|WARN|Interface table in Open_vSwitch database lacks cfm_flap_count column (database needs upgrade?)
2015-04-27T11:38:15.750Z|00016|ovsdb_idl|WARN|Interface table in Open_vSwitch database lacks error column (database needs upgrade?)
2015-04-27T11:38:15.750Z|00017|ovsdb_idl|WARN|Interface table in Open_vSwitch database lacks lldp column (database needs upgrade?)
2015-04-27T11:38:15.750Z|00018|ovsdb_idl|WARN|Open_vSwitch table in Open_vSwitch database lacks datapath_types column (database needs upgrade?)
2015-04-27T11:38:15.750Z|00019|ovsdb_idl|WARN|Open_vSwitch table in Open_vSwitch database lacks iface_types column (database needs upgrade?)
2015-04-27T11:38:15.750Z|00020|ovsdb_idl|WARN|Port table in Open_vSwitch database lacks bond_active_slave column (database needs upgrade?)
2015-04-27T11:38:15.750Z|00021|ovsdb_idl|WARN|Port table in Open_vSwitch database lacks rstp_statistics column (database needs upgrade?)
2015-04-27T11:38:15.750Z|00022|ovsdb_idl|WARN|Port table in Open_vSwitch database lacks rstp_status column (database needs upgrade?)
2015-04-27T11:38:15.751Z|00023|bridge|INFO|ovs-vswitchd (Open vSwitch) 2.3.90
2015-04-27T11:38:27.897Z|00024|memory|INFO|7688 kB peak resident set size after 12.2 seconds

    Could anyone help me ? Great appreciate for anyone's relpy.
Best Regards,
Vinllen


Netty exception while trying connecting to a switch

Tomer Pearl <Tomer.Pearl@...>
 

Good day everyone,

I’m using Helium release of ODL.

 

I have a mechanism of connection retry while a switch is not available.

Every x seconds I use the OvsdbConnectionService.connect method from org.opendaylight.ovsdb.plugin.api to try to connect to a switch that is unavailable.

After something like 150 retries I receive the following log error:

 

java.lang.IllegalStateException: failed to create a child event loop

        at io.netty.util.concurrent.MultithreadEventExecutorGroup.<init>(MultithreadEventExecutorGroup.java:68)[170:io.netty.common:4.0.23.Final]

        at io.netty.channel.MultithreadEventLoopGroup.<init>(MultithreadEventLoopGroup.java:49)[169:io.netty.transport:4.0.23.Final]

        at io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:61)[169:io.netty.transport:4.0.23.Final]

        at io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:52)[169:io.netty.transport:4.0.23.Final]

        at io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:44)[169:io.netty.transport:4.0.23.Final]

        at io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:36)[169:io.netty.transport:4.0.23.Final]

        at org.opendaylight.ovsdb.lib.impl.OvsdbConnectionService.connect(OvsdbConnectionService.java:92)[191:org.opendaylight.ovsdb.library:1.0.1.Helium-SR1]

        at org.opendaylight.ovsdb.plugin.impl.ConnectionServiceImpl.connect(ConnectionServiceImpl.java:165)[205:org.opendaylight.ovsdb.plugin:1.0.1.Helium-SR1]

        at com.cxtrm.contexcontrol.ovsdb.impl.OvsdbDao$OvsdbServerImpl.reconnect(OvsdbDao.java:104)[379:com.cxtrm.contexcontrol.ovsdb.impl:1.1.0.0-SNAPSHOT]

        at com.cxtrm.contexcontrol.ovsdb.impl.OvsdbServerPool$1.work(OvsdbServerPool.java:85)[379:com.cxtrm.contexcontrol.ovsdb.impl:1.1.0.0-SNAPSHOT]

        at com.cxtrm.contexmap.fw.scheduler.SchedulerService$RunnableWrapperForWorker.run(SchedulerService.java:102)[355:com.cxtrm.contexmap.common-infrastructure.impl:1.1.0.0-SNAPSHOT]

        at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)[:1.7.0_25]

        at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)[:1.7.0_25]

        at java.util.concurrent.FutureTask.run(Unknown Source)[:1.7.0_25]

        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(Unknown Source)[:1.7.0_25]

        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)[:1.7.0_25]

        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)[:1.7.0_25]

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)[:1.7.0_25]

        at java.lang.Thread.run(Unknown Source)[:1.7.0_25]

Caused by: io.netty.channel.ChannelException: failed to open a new selector

        at io.netty.channel.nio.NioEventLoop.openSelector(NioEventLoop.java:128)[169:io.netty.transport:4.0.23.Final]

        at io.netty.channel.nio.NioEventLoop.<init>(NioEventLoop.java:120)[169:io.netty.transport:4.0.23.Final]

        at io.netty.channel.nio.NioEventLoopGroup.newChild(NioEventLoopGroup.java:87)[169:io.netty.transport:4.0.23.Final]

        at io.netty.util.concurrent.MultithreadEventExecutorGroup.<init>(MultithreadEventExecutorGroup.java:64)[170:io.netty.common:4.0.23.Final]

        ... 18 more

Caused by: java.io.IOException: Too many open files

        at sun.nio.ch.IOUtil.makePipe(Native Method)[:1.7.0_25]

        at sun.nio.ch.EPollSelectorImpl.<init>(Unknown Source)[:1.7.0_25]

        at sun.nio.ch.EPollSelectorProvider.openSelector(Unknown Source)[:1.7.0_25]

        at io.netty.channel.nio.NioEventLoop.openSelector(NioEventLoop.java:126)[169:io.netty.transport:4.0.23.Final]

        ... 21 more

 

Even if I try somehow to disconnect from the previous OvsdbClient by calling OvsdbClient.disconnect, I still receive this error.

Is this really a bug or maybe I need to use a different java interface?

 

Thank you very much,

Tomer.

 


Re: [controller-dev] Continuing the BUG-2825 discussion

Anton Ivanov <anton.ivanov@...>
 

On 25/04/15 02:47, Edward Warnicke wrote:
Looping in ovsdb, openflowplugin, groupbasedpolicy...

I think we should just do a once over on all projects and audit IpvXPrefix usage.

While most of the breakage is in the testcases, there are some cases where the core code is broken - 3053 and there are logic issues. This is mostly related to how you map match-ers to prefixes to protocol semantics and vice versa.

That may or may not show up with a broken test once we push the change out. By the way, even if we do not push this change back to Li (and even He), we should still fix the broken per project code as it will result in erratic runtime behaviour.

A.


Ed

On Fri, Apr 24, 2015 at 3:34 PM, Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco) <ttkacik@...> wrote:

Note this is merged into post-lithium yangtools - 0.8.0-SNAPSHOT

https://git.opendaylight.org/gerrit/#/c/18922/

 

Merging to Lithium could not be done yet, since as Anton pointed out

some of projects relly on buggy behaviour.

 

I run build of this patch against all ODL projects,

And following had failing unit tests:

 

 

·        ovsdb

·        gbp

·        openflowplugin

 

Because of not properly passing Ipv4 / Ipv6 values.

 

Tony

 

 

From: controller-dev-bounces@... [mailto:controller-dev-bounces@...] On Behalf Of Anton Ivanov
Sent: Friday, April 24, 2015 10:52 PM
To: Edward Warnicke
Cc: controller-dev@...
Subject: Re: [controller-dev] Continuing the BUG-2825 discussion

 

On 24/04/15 21:13, Edward Warnicke wrote:

Also... does this fix 3051:

 


I need to see what it generates which I will do tomorrow. Too late today (on this side of the pond).

We should have announced it on weather before merging. The mayhem will be complete - people have been "using" this bug across the board. Pretty much every project will stop building.

A.


 

Ed

 

On Fri, Apr 24, 2015 at 1:09 PM, Edward Warnicke <hagbard@...> wrote:

Your top line finding is roughly in line with what I expected given past profiling and examination of performance issues.

 

The more nuanced stuff you are looking at is interesting though.

 

Would it perhaps make more sense to dig into the 'bigger fish' on performance?

 

Ed

 

On Fri, Apr 24, 2015 at 12:15 PM, Anton Ivanov <anton.ivanov@...> wrote:

On 22/04/15 14:34, Edward Warnicke wrote:

Sure... but that doesn't really tell us anything about the impact on overall performance.  Chasing microseconds that don't matter is a classic performance tuning error (note: not saying that's what you are doing here... just that we really can't know until we look at its end to end impact).


Hi Edward, hi list,

I ran a full set of benchmarks today and the short story is: there is an impact, but it does not yet make a lot of difference.

Basically, we are stuck/stalled somewhere else.

As I add the faster binary interfaces into the game I retain comparable (a few percent higher, but nothing to shout about) average number of responses on CBENCH. While 5-6% is an improvement, it is not something particularly big.

What is interesting is that the standard deviation increases (once all bells and whistles are added) by 4.6 times. This is at default settings which means that the machine running the controller can clock up and down. Investigation shows that indeed it does.

This effect disappears if I turn the dynamic clock off and nail the machine frequency to highest. Average remains pretty much the same (despite clock running only at max frequency), std dev becomes very low.

What this says to me is that clearly there is CPU saving from the patches and it is significant to the point where the kernel starts making decisions that a particular core CPU usage is low enough to drop the clock. It also drops it low enough for it to show in responce measurements. However, this CPU saving cannot be leveraged for an increase in the headline number, because we are constrained elsewhere and whatever that constraint is, it is pretty "hard".

I am going to set-up the benchmark differently next week to measure actual CPU and/or frequency stats to see exactly what the gain is as well as look for the "wall" (whatever it is) we are hitting here.

Brgds,

A.

P.S. In order to get to this point I had to fix quite a few 3051/3053 derivatives. That breakage is across the board - pretty much everywhere and in every project.

Gerrits for these and an updated gerrit for the patchset (the current one has a bug) will follow next week.

A.



 

Ed

 

On Wed, Apr 22, 2015 at 4:42 AM, Anton Ivanov <anton.ivanov@...> wrote:

On 22/04/15 12:34, Anton Ivanov wrote:

On 21/04/15 22:56, Edward Warnicke wrote:

Anton,

 

Did you ever do end to end testing to see the impact of these proposed changes on performance?


No because I keep being dragged to firefight all kinds of stuff.

I am just about done with setting up the rig.


I'm curious :)


So am I, but it will probably take a day or two to reach the point where the test setup will satisfy my curiosity :(


Just to be clear - I have benchmarked the object instantiation with the existing code and with the new code quite extensively so the differences there are now known.

We have a guaranteed extra latency of 40-100 microseconds on anything and everything we do because of the current code.

A.





A.


 

Ed

 

On Tue, Apr 21, 2015 at 2:52 PM, Anton Ivanov <anton.ivanov@...> wrote:

Hi all,

I found one more item going through my notes from the call - the claimed estimate of performance impact for storing into datastore of data coming from network is wrong.

The given example was BGP which stores all data into the data store so supposedly if you change ser-des to use binary forms you are just moving the CPU load elsewhere. There should apparently be no difference.

So is it really "moving the CPU elsewhere"?

Current design:

    Sum = Deserialize binary from network + Convert to String + Pass to regexp for validation + instantiate object + move into store

Proposed fix assuming we do not fix the data store and data store is "as is":

    Sum = Deserialize + instantiate object + Convert to String + move into store


The regexp is not present in the second case - so even if the BI continues to use the string form and has no efficiency improvements you are looking at: 40 microseconds gain per IPv4 prefix and 100+ for each IPv6 prefix.

Situation with other use cases is similar. So with all due respect, Robert - you are quite wrong on this one. If we will be using any of the acceleration interfaces, it is not moving CPU elsewhere, it is a significant CPU saving.

Brgds,

A.



On 21/04/15 18:39, Anton Ivanov wrote:

Hi all,

First of all, continuing from the call - if there is general feeling that we should not be locking ourselves into the additional binary APIs then we should simply cut for Li the issue down to bug-fixing and make the classes expose only backwards compatible interfaces.

Reality is - we are buggy and non-v6 compliant. We can release the controller with the sticker "Legacy Equipment, v4 only" sticker on it, but this still leaves the corner cases of v4 prefix and Mac. So it will still be buggy.

I am going to go back to Robert's "Solve it at BI" suggestion.

I am probably missing something.

1. If there is a "union" like structure that sits behind an object (similar to current code generated from union) it has to use the _SAME_ backend data and the backend data should be in the canonical form and stored canonically on instantiation. How is this going to work out as code?

The current code generated to represent a yang union does not do that - it provides alternatives, each of which uses its own storage. If one part is generated and another one is not how does the generated part talk to the manual one and how do they use the same storage? Specifically, how does the string part (as expected by the current core components) talk to the canonicalized backend?

The deeper you go into this, the more it looks like zero generated code - all manual (for the 5 affected types - there are 5 types in total under discussion). Even then, I cannot form that code in my head (just yet), this is why I am proposing something which is BA only.

2. We are talking a grand total of 5 types here. There are 5 types in total across the core yang data models which predate yang by a very long time and have their unique canonicalization specifics described in earlier RFCs (or IEEE documents). Their canonical representation does not match the data in the yang model and is described in the comments:

    MacAddress
    Ipv4Address - optional, performance only
    Ipv4Prefix
    Ipv6Address
    Ipv6Prefix

A generic solution to generate polimorphic code to represent any type with a binary req is nice. I am all for it. But is it worth it to do that for 5 types? Also, these 5 types are special - you are not doing any network application without touching at least one of them.

So even if they end up being special that may be worth it. In fact, the easiest is to make them special in BA, special in BI and be done with it - it is probably a fraction of a percent or so of the effort required to fix generation.

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


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

 




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

 


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

 

 

 

 

 




Re: [Need Help] Arbitrary connection port is part of the node-id

Edward Warnicke <hagbard@...>
 

If we do not receive the initial dump of the DB... we aren't getting anything to work at all... it s a fundamental failure.

And always remember that OVSDB can connect to us unsolicted... so we will always have to deal with ovsdb instances that we *didn't* create the connection for.  This is another reason that the solution I'm advocating for here is good... it works consistently in active and passive mode.

Ed

On Fri, Apr 24, 2015 at 7:08 PM, Amit Mandke (ammandke) <ammandke@...> wrote:
Isn’t that tricky for a person who is trying to connect ovs to controller? Its like you may or may not see the node in operations based whether or not it succeeds or fails to update.However the ovs would show conencted=true and manager ip, with no data in operations.  :-)

IMO connection received is exclusive event for creating ovsdb node and then registering for callbacks for update. Current implementation seems more logical(to me) than changing it for 1 case of IID creation. 

My further 2 cents on iid serialization/deserialization:

In general, IMO  this IID serialization and deserialization is a risk. And should be avoided if possible.  If a system is running for long period of time and for some reason someone connected disconnected same ovs nodes with diff setting once with IID passed to it once without. Your config would be looking very out of synch of your operations. On top of that if the apps that are trying to use this data programmatically would most likely fail to take care of such situations. 

Also different apps may choose different strategies to generate iids and would be impossible for them to coexist.

So having  only one way of creating IIDs would help in longer run. If one wants avoid iid  generation while connecting to OVS or creating bridges then we can always expose RPCs for that. However, if one wants to use CONFIG store to configure, then they have to build appropriate iid.

Thoughts?

-Amit


From: Edward Warnicke <hagbard@...>
Date: Friday, April 24, 2015 at 2:09 PM
To: Amit Mandke <ammandke@...>
Cc: "Prateek Garg (prategar)" <prategar@...>, "ovsdb-dev@..." <ovsdb-dev@...>

Subject: Re: [ovsdb-dev] [Need Help] Arbitrary connection port is part of the node-id

Not so tricky... we either get that dump or we are borked...

Ed

On Fri, Apr 24, 2015 at 2:07 PM, Amit Mandke (ammandke) <ammandke@...> wrote:
It sounds tricky, cause once you register for callbacks you can’t be sure of the sequence of all the updates right? Or even guaranty if each update would be processed?

So essentially you are letting go a sure-shot event where you received the connection to store the OVSDB node and relying on the future updates to create it.

I am not sure if that is the best thing to do.

-Amit


From: Edward Warnicke <hagbard@...>
Date: Friday, April 24, 2015 at 11:07 AM
To: "Prateek Garg (prategar)" <prategar@...>
Cc: "ovsdb-dev@..." <ovsdb-dev@...>

Subject: Re: [ovsdb-dev] [Need Help] Arbitrary connection port is part of the node-id

I had an idea last night as I was falling asleep that might be interesting.

How about we create the ovsdb-node in operational with the OpenVSwitchUpdateCommand (which should get tripped with the original dump of data from ovsdb on connect) rather than invoking OvsdbNodeCreatedCommand in the OvsdbConnectionInstance() constructor.  That way you have access to the info you need, don't have to do a select (and thus a new round trip) etc.

Thoughts?

Ed

On Wed, Apr 22, 2015 at 3:40 PM, Prateek Garg (prategar) <prategar@...> wrote:
This can be done in OvsdbNodeCreateCommand. The issue I see there is changing the signature of the OvsdbNodeCreateCommand’s constructor.
Let me know if its ok to change the signature and pass OvsdbClient.
However, I believe still we would need to run a select statement to get the system-id in OvsdbNodeCreateCommand.

Please let me know your thoughts.

Thanks
Prateek

From: Edward Warnicke <hagbard@...>
Date: Wednesday, April 22, 2015 at 3:26 PM

To: Prateek Garg <prategar@...>
Cc: "ovsdb-dev@..." <ovsdb-dev@...>, "ffernand@..." <ffernand@...>
Subject: Re: [ovsdb-dev] [Need Help] Arbitrary connection port is part of the node-id

And why change ConnectionInfo (that really really is info about the ip and port...)

Ed

On Wed, Apr 22, 2015 at 3:25 PM, Edward Warnicke <hagbard@...> wrote:
Prateek,

Question... why not in the OvsdbNodeCreateCommand where all of the other operational info is being created and written?

Ed

On Wed, Apr 22, 2015 at 3:22 PM, Prateek Garg (prategar) <prategar@...> wrote:
Hi Ed,

The way I am implementing this is:

In OvsdbConnectionManager’s connected method, I’ll set system-Id from external_ids of open_Vswitch table in ConnectionInfo key (I’ll modify yang to add systemId field in connectionInfo to add system-id). Therefore to get the system-id in OvsdbConnectionManager’s connected method, I need to execute select operation on open_Vswitch table. 
So later when OvsdbNodeCreateCommand is called with ConnectionInfo, I’ll have the systemId to write to operation store.

Please let me know your thoughts on this approach.

Regards
Prateek

From: Edward Warnicke <hagbard@...>
Date: Wednesday, April 22, 2015 at 2:58 PM
To: Prateek Garg <prategar@...>
Cc: "ovsdb-dev@..." <ovsdb-dev@...>, "ffernand@..." <ffernand@...>
Subject: Re: [ovsdb-dev] [Need Help] Arbitrary connection port is part of the node-id

Prateek,

Why are you doing a select? (curious) :)

Ed

On Wed, Apr 22, 2015 at 2:54 PM, Prateek Garg (prategar) <prategar@...> wrote:
Hi,

While implementing this use case I need some help using the select operation of ovsdb library. I am trying to read the Open_vSwitch table to get the data in external-ids. I am doing the following:

OpenVSwitch ovs = TyperUtils.getTypedRowWrapper(dbSchema, OpenVSwitch.class);

                transaction.add(op.select(ovs.getSchema()));

                ListenableFuture<List<OperationResult>> results = transaction.execute();

List<OperationResult> resultList = results.get();


I am getting resultList as:

[OperationResult [count=0, uuid=null, rows=[Row [columns={}]], error=null, details=null]]

Query sent to Ovs db is:

ovsdb-client transact '["Open_vSwitch",{"op":"select", "table":"Open_vSwitch", "columns":[],"where": []}]'


However, I want to send:

ovsdb-client transact '["Open_vSwitch",{"op":"select", "table":"Open_vSwitch", "columns":["external_ids"],"where": []}]'


It would be very helpful if someone could provide pointers on how to set column in select operation.


Regards

Prateek


From: Edward Warnicke <hagbard@...>
Date: Tuesday, April 21, 2015 at 1:18 PM
To: Prateek Garg <prategar@...>
Cc: "ffernand@..." <ffernand@...>, "ovsdb-dev@..." <ovsdb-dev@...>

Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the node-id

The config/operational synch is best handled a little differently.

When you try to config an ovsdb-node to connect... you don't *really* know the systemid... just the IP:port.

The way we solved this for bridges, and the way I'd advocate solving it here is:

1)  If you are configing a ovsdb-node, write its iid to the external-ids of the openvswitch table
2)  When you get an openvswitch table, if it has an iid in its external-ids, use that in the operational data store as its iid
3)  If you don't get an iid in its external-ids... use some reasonable heuristic to contruct one.

For #3... I don't currently see a reason *not* to use systemid presuming its guaranteed unique and we contruct some kind of reasonable
Uri from it.

Ed

On Tue, Apr 21, 2015 at 1:09 PM, Prateek Garg (prategar) <prategar@...> wrote:
Hi,

In my opinion, the we can replace the node-id of the ovsdb node in md-sal to contain system_id from external properties. This would make sure that the config and operation store are in synch in case the controller reconnects to the same ovs in tcp mode.
I’ll make these changes, update postman collection and submit for approval. 

Regards
Prateek

----------------------------------------------------------------------
Date: Mon, 20 Apr 2015 21:28:28 -0700
From: Edward Warnicke <hagbard@...>
To: Flavio Fernandes <ffernand@...>
Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the
node-id
Message-ID:
Content-Type: text/plain; charset="utf-8"

Make sure we build in the same mechanism of storing iids in external_ids
that we use for bridges so that if someone configures a connection as an
ovsdb-node, it comes *back* in operational store with the same iid...

Ed

On Mon, Apr 20, 2015 at 8:12 PM, Flavio Fernandes <ffernand@...>
wrote:


> On Apr 20, 2015, at 7:12 PM, Sharon Aicler (saichler) <
saichler@...> wrote:
>
> Hi,
> A further investigation by Amit has revealed that the system uuid is
automatically set by the OVS so we can use it out of the box to identify an
OVS instance. To see the external ID you can invoke the following cli:
>
> ovs-vsctl --columns=external-ids list open_vswitch
>
> looks like a win/win situation to me...:o)
>

ok!

? flavio



> Thanks,
>          Sharon.
> ________________________________________
ovsdb-dev-bounces@...] on behalf of Sharon Aicler
(saichler)
> Sent: Monday, April 20, 2015 3:41 PM
> To: Flavio Fernandes
> Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the node-id
>
> In that case you are kind of "gambling" that two of your dockers won't
choose the same arbitrary port...:o)
> In any case, we can't have the ID of an element arbitrary change all the
time...As a quick and dirty fix, i would drop the port (and the "behind a
NAT" scenario) so ovsdb id's would be predictable and not change per
connection (it can even change in run-time if there was some network
connectivity issue)...
>
> A more suitable solution is probably generating and assigning a uuid to
each of the managed instances, if one does not exist...a quick googling i
found the following cli method:
>
> ovs-vsctl set open_vswitch . external-ids:system-id='"${UUID}"'
>
>
> Thanks,
>         Sharon.
> ________________________________________
> From: Flavio Fernandes [ffernand@...]
> Sent: Monday, April 20, 2015 1:25 PM
> To: Sharon Aicler (saichler)
> Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the node-id
>
>> On Apr 20, 2015, at 3:24 PM, Sharon Aicler (saichler) <
saichler@...> wrote:
>>
>> Hi,
>> Sorry, but does't a docker has a unique ip?
>
> yes and no. ;) I?m used to see docker behind nat on the vm that hosts
the containers. Then, from
> 'outside' the vm, various ovs instances reached using the same ip, but
different ports. Like this:
>
>        docker run -p 16640:6640 blablabla
>        docker run -p 16641:6640 blablabla
>        docker run -p 16642:6640 blablabla
>        ?
>
> ? flavio
>
>
>
>> ________________________________________
>> From: Flavio Fernandes [ffernand@...]
>> Sent: Friday, April 17, 2015 4:23 AM
>> To: Sharon Aicler (saichler)
>> Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the
node-id
>>
>>> On Apr 16, 2015, at 6:53 PM, Sharon Aicler (saichler) <
saichler@...> wrote:
>>>
>>> Hi all,
>>> The node-id of an ovs bridge contains the arbitrary port of the
outgoing connection instance and looks something like the following:
>>>
>>> This creates an issue if i place something in the configuration store
and the connection goes down due to some reason, the node-id will change
each time the connection is lost or I restart ODL/OVSDB.
>>> Any reason for this? can't we just use the ip? i don't think you can
run two instances of OVS in the same VM?
>>>
>>
>> Hi Sharon,
>>
>> That is not true. I?ve seen a VM with many OVS instances running;
mostly in a docker environment.
>>
>> But I see your point. When OVS is connecting to ODL (i.e. active
method) the port is not predictable. When ODL connects to
>> an OVS (passive mode), ODL will need to know that port, tho; so the
solution to this problem should ideally work on both
>> scenarios.
>>
>> ? flavio
>>
>>
>>
>>>
>>> Thanks,
>>>        Sharon.
>>> _______________________________________________
>>> ovsdb-dev mailing list
> _______________________________________________
> ovsdb-dev mailing list

_______________________________________________
ovsdb-dev mailing list

-------------- next part --------------
An HTML attachment was scrubbed...








Cluster support?

Amit Mandke (ammandke) <ammandke@...>
 

Hi All, 
Is it possible to connect ovsdb/ovsswitch to clustered(3 node) odl controller? or currently it can connect to only single node/ non-clustered controller? I couldn’t find a way of doing that.

-Amit


Re: [Need Help] Arbitrary connection port is part of the node-id

Amit Mandke (ammandke) <ammandke@...>
 

Isn’t that tricky for a person who is trying to connect ovs to controller? Its like you may or may not see the node in operations based whether or not it succeeds or fails to update.However the ovs would show conencted=true and manager ip, with no data in operations.  :-)

IMO connection received is exclusive event for creating ovsdb node and then registering for callbacks for update. Current implementation seems more logical(to me) than changing it for 1 case of IID creation. 

My further 2 cents on iid serialization/deserialization:

In general, IMO  this IID serialization and deserialization is a risk. And should be avoided if possible.  If a system is running for long period of time and for some reason someone connected disconnected same ovs nodes with diff setting once with IID passed to it once without. Your config would be looking very out of synch of your operations. On top of that if the apps that are trying to use this data programmatically would most likely fail to take care of such situations. 

Also different apps may choose different strategies to generate iids and would be impossible for them to coexist.

So having  only one way of creating IIDs would help in longer run. If one wants avoid iid  generation while connecting to OVS or creating bridges then we can always expose RPCs for that. However, if one wants to use CONFIG store to configure, then they have to build appropriate iid.

Thoughts?

-Amit


From: Edward Warnicke <hagbard@...>
Date: Friday, April 24, 2015 at 2:09 PM
To: Amit Mandke <ammandke@...>
Cc: "Prateek Garg (prategar)" <prategar@...>, "ovsdb-dev@..." <ovsdb-dev@...>
Subject: Re: [ovsdb-dev] [Need Help] Arbitrary connection port is part of the node-id

Not so tricky... we either get that dump or we are borked...

Ed

On Fri, Apr 24, 2015 at 2:07 PM, Amit Mandke (ammandke) <ammandke@...> wrote:

It sounds tricky, cause once you register for callbacks you can’t be sure of the sequence of all the updates right? Or even guaranty if each update would be processed?

So essentially you are letting go a sure-shot event where you received the connection to store the OVSDB node and relying on the future updates to create it.

I am not sure if that is the best thing to do.

-Amit


From: Edward Warnicke <hagbard@...>
Date: Friday, April 24, 2015 at 11:07 AM
To: "Prateek Garg (prategar)" <prategar@...>
Cc: "ovsdb-dev@..." <ovsdb-dev@...>

Subject: Re: [ovsdb-dev] [Need Help] Arbitrary connection port is part of the node-id

I had an idea last night as I was falling asleep that might be interesting.

How about we create the ovsdb-node in operational with the OpenVSwitchUpdateCommand (which should get tripped with the original dump of data from ovsdb on connect) rather than invoking OvsdbNodeCreatedCommand in the OvsdbConnectionInstance() constructor.  That way you have access to the info you need, don't have to do a select (and thus a new round trip) etc.

Thoughts?

Ed

On Wed, Apr 22, 2015 at 3:40 PM, Prateek Garg (prategar) <prategar@...> wrote:
This can be done in OvsdbNodeCreateCommand. The issue I see there is changing the signature of the OvsdbNodeCreateCommand’s constructor.
Let me know if its ok to change the signature and pass OvsdbClient.
However, I believe still we would need to run a select statement to get the system-id in OvsdbNodeCreateCommand.

Please let me know your thoughts.

Thanks
Prateek

From: Edward Warnicke <hagbard@...>
Date: Wednesday, April 22, 2015 at 3:26 PM

To: Prateek Garg <prategar@...>
Cc: "ovsdb-dev@..." <ovsdb-dev@...>, "ffernand@..." <ffernand@...>
Subject: Re: [ovsdb-dev] [Need Help] Arbitrary connection port is part of the node-id

And why change ConnectionInfo (that really really is info about the ip and port...)

Ed

On Wed, Apr 22, 2015 at 3:25 PM, Edward Warnicke <hagbard@...> wrote:
Prateek,

Question... why not in the OvsdbNodeCreateCommand where all of the other operational info is being created and written?

Ed

On Wed, Apr 22, 2015 at 3:22 PM, Prateek Garg (prategar) <prategar@...> wrote:
Hi Ed,

The way I am implementing this is:

In OvsdbConnectionManager’s connected method, I’ll set system-Id from external_ids of open_Vswitch table in ConnectionInfo key (I’ll modify yang to add systemId field in connectionInfo to add system-id). Therefore to get the system-id in OvsdbConnectionManager’s connected method, I need to execute select operation on open_Vswitch table. 
So later when OvsdbNodeCreateCommand is called with ConnectionInfo, I’ll have the systemId to write to operation store.

Please let me know your thoughts on this approach.

Regards
Prateek

From: Edward Warnicke <hagbard@...>
Date: Wednesday, April 22, 2015 at 2:58 PM
To: Prateek Garg <prategar@...>
Cc: "ovsdb-dev@..." <ovsdb-dev@...>, "ffernand@..." <ffernand@...>
Subject: Re: [ovsdb-dev] [Need Help] Arbitrary connection port is part of the node-id

Prateek,

Why are you doing a select? (curious) :)

Ed

On Wed, Apr 22, 2015 at 2:54 PM, Prateek Garg (prategar) <prategar@...> wrote:
Hi,

While implementing this use case I need some help using the select operation of ovsdb library. I am trying to read the Open_vSwitch table to get the data in external-ids. I am doing the following:

OpenVSwitch ovs = TyperUtils.getTypedRowWrapper(dbSchema, OpenVSwitch.class);

                transaction.add(op.select(ovs.getSchema()));

                ListenableFuture<List<OperationResult>> results = transaction.execute();

List<OperationResult> resultList = results.get();


I am getting resultList as:

[OperationResult [count=0, uuid=null, rows=[Row [columns={}]], error=null, details=null]]

Query sent to Ovs db is:

ovsdb-client transact '["Open_vSwitch",{"op":"select", "table":"Open_vSwitch", "columns":[],"where": []}]'


However, I want to send:

ovsdb-client transact '["Open_vSwitch",{"op":"select", "table":"Open_vSwitch", "columns":["external_ids"],"where": []}]'


It would be very helpful if someone could provide pointers on how to set column in select operation.


Regards

Prateek


From: Edward Warnicke <hagbard@...>
Date: Tuesday, April 21, 2015 at 1:18 PM
To: Prateek Garg <prategar@...>
Cc: "ffernand@..." <ffernand@...>, "ovsdb-dev@..." <ovsdb-dev@...>

Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the node-id

The config/operational synch is best handled a little differently.

When you try to config an ovsdb-node to connect... you don't *really* know the systemid... just the IP:port.

The way we solved this for bridges, and the way I'd advocate solving it here is:

1)  If you are configing a ovsdb-node, write its iid to the external-ids of the openvswitch table
2)  When you get an openvswitch table, if it has an iid in its external-ids, use that in the operational data store as its iid
3)  If you don't get an iid in its external-ids... use some reasonable heuristic to contruct one.

For #3... I don't currently see a reason *not* to use systemid presuming its guaranteed unique and we contruct some kind of reasonable
Uri from it.

Ed

On Tue, Apr 21, 2015 at 1:09 PM, Prateek Garg (prategar) <prategar@...> wrote:
Hi,

In my opinion, the we can replace the node-id of the ovsdb node in md-sal to contain system_id from external properties. This would make sure that the config and operation store are in synch in case the controller reconnects to the same ovs in tcp mode.
I’ll make these changes, update postman collection and submit for approval. 

Regards
Prateek

----------------------------------------------------------------------
Date: Mon, 20 Apr 2015 21:28:28 -0700
From: Edward Warnicke <hagbard@...>
To: Flavio Fernandes <ffernand@...>
Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the
node-id
Message-ID:
Content-Type: text/plain; charset="utf-8"

Make sure we build in the same mechanism of storing iids in external_ids
that we use for bridges so that if someone configures a connection as an
ovsdb-node, it comes *back* in operational store with the same iid...

Ed

On Mon, Apr 20, 2015 at 8:12 PM, Flavio Fernandes <ffernand@...>
wrote:


> On Apr 20, 2015, at 7:12 PM, Sharon Aicler (saichler) <
saichler@...> wrote:
>
> Hi,
> A further investigation by Amit has revealed that the system uuid is
automatically set by the OVS so we can use it out of the box to identify an
OVS instance. To see the external ID you can invoke the following cli:
>
> ovs-vsctl --columns=external-ids list open_vswitch
>
> looks like a win/win situation to me...:o)
>

ok!

? flavio



> Thanks,
>          Sharon.
> ________________________________________
ovsdb-dev-bounces@...] on behalf of Sharon Aicler
(saichler)
> Sent: Monday, April 20, 2015 3:41 PM
> To: Flavio Fernandes
> Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the node-id
>
> In that case you are kind of "gambling" that two of your dockers won't
choose the same arbitrary port...:o)
> In any case, we can't have the ID of an element arbitrary change all the
time...As a quick and dirty fix, i would drop the port (and the "behind a
NAT" scenario) so ovsdb id's would be predictable and not change per
connection (it can even change in run-time if there was some network
connectivity issue)...
>
> A more suitable solution is probably generating and assigning a uuid to
each of the managed instances, if one does not exist...a quick googling i
found the following cli method:
>
> ovs-vsctl set open_vswitch . external-ids:system-id='"${UUID}"'
>
>
> Thanks,
>         Sharon.
> ________________________________________
> From: Flavio Fernandes [ffernand@...]
> Sent: Monday, April 20, 2015 1:25 PM
> To: Sharon Aicler (saichler)
> Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the node-id
>
>> On Apr 20, 2015, at 3:24 PM, Sharon Aicler (saichler) <
saichler@...> wrote:
>>
>> Hi,
>> Sorry, but does't a docker has a unique ip?
>
> yes and no. ;) I?m used to see docker behind nat on the vm that hosts
the containers. Then, from
> 'outside' the vm, various ovs instances reached using the same ip, but
different ports. Like this:
>
>        docker run -p 16640:6640 blablabla
>        docker run -p 16641:6640 blablabla
>        docker run -p 16642:6640 blablabla
>        ?
>
> ? flavio
>
>
>
>> ________________________________________
>> From: Flavio Fernandes [ffernand@...]
>> Sent: Friday, April 17, 2015 4:23 AM
>> To: Sharon Aicler (saichler)
>> Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the
node-id
>>
>>> On Apr 16, 2015, at 6:53 PM, Sharon Aicler (saichler) <
saichler@...> wrote:
>>>
>>> Hi all,
>>> The node-id of an ovs bridge contains the arbitrary port of the
outgoing connection instance and looks something like the following:
>>>
>>> This creates an issue if i place something in the configuration store
and the connection goes down due to some reason, the node-id will change
each time the connection is lost or I restart ODL/OVSDB.
>>> Any reason for this? can't we just use the ip? i don't think you can
run two instances of OVS in the same VM?
>>>
>>
>> Hi Sharon,
>>
>> That is not true. I?ve seen a VM with many OVS instances running;
mostly in a docker environment.
>>
>> But I see your point. When OVS is connecting to ODL (i.e. active
method) the port is not predictable. When ODL connects to
>> an OVS (passive mode), ODL will need to know that port, tho; so the
solution to this problem should ideally work on both
>> scenarios.
>>
>> ? flavio
>>
>>
>>
>>>
>>> Thanks,
>>>        Sharon.
>>> _______________________________________________
>>> ovsdb-dev mailing list
> _______________________________________________
> ovsdb-dev mailing list

_______________________________________________
ovsdb-dev mailing list

-------------- next part --------------
An HTML attachment was scrubbed...







Re: [controller-dev] Continuing the BUG-2825 discussion

Edward Warnicke <hagbard@...>
 

Looping in ovsdb, openflowplugin, groupbasedpolicy...

Ed

On Fri, Apr 24, 2015 at 3:34 PM, Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco) <ttkacik@...> wrote:

Note this is merged into post-lithium yangtools - 0.8.0-SNAPSHOT

https://git.opendaylight.org/gerrit/#/c/18922/

 

Merging to Lithium could not be done yet, since as Anton pointed out

some of projects relly on buggy behaviour.

 

I run build of this patch against all ODL projects,

And following had failing unit tests:

 

 

·        ovsdb

·        gbp

·        openflowplugin

 

Because of not properly passing Ipv4 / Ipv6 values.

 

Tony

 

 

From: controller-dev-bounces@... [mailto:controller-dev-bounces@...] On Behalf Of Anton Ivanov
Sent: Friday, April 24, 2015 10:52 PM
To: Edward Warnicke
Cc: controller-dev@...
Subject: Re: [controller-dev] Continuing the BUG-2825 discussion

 

On 24/04/15 21:13, Edward Warnicke wrote:

Also... does this fix 3051:

 


I need to see what it generates which I will do tomorrow. Too late today (on this side of the pond).

We should have announced it on weather before merging. The mayhem will be complete - people have been "using" this bug across the board. Pretty much every project will stop building.

A.


 

Ed

 

On Fri, Apr 24, 2015 at 1:09 PM, Edward Warnicke <hagbard@...> wrote:

Your top line finding is roughly in line with what I expected given past profiling and examination of performance issues.

 

The more nuanced stuff you are looking at is interesting though.

 

Would it perhaps make more sense to dig into the 'bigger fish' on performance?

 

Ed

 

On Fri, Apr 24, 2015 at 12:15 PM, Anton Ivanov <anton.ivanov@...> wrote:

On 22/04/15 14:34, Edward Warnicke wrote:

Sure... but that doesn't really tell us anything about the impact on overall performance.  Chasing microseconds that don't matter is a classic performance tuning error (note: not saying that's what you are doing here... just that we really can't know until we look at its end to end impact).


Hi Edward, hi list,

I ran a full set of benchmarks today and the short story is: there is an impact, but it does not yet make a lot of difference.

Basically, we are stuck/stalled somewhere else.

As I add the faster binary interfaces into the game I retain comparable (a few percent higher, but nothing to shout about) average number of responses on CBENCH. While 5-6% is an improvement, it is not something particularly big.

What is interesting is that the standard deviation increases (once all bells and whistles are added) by 4.6 times. This is at default settings which means that the machine running the controller can clock up and down. Investigation shows that indeed it does.

This effect disappears if I turn the dynamic clock off and nail the machine frequency to highest. Average remains pretty much the same (despite clock running only at max frequency), std dev becomes very low.

What this says to me is that clearly there is CPU saving from the patches and it is significant to the point where the kernel starts making decisions that a particular core CPU usage is low enough to drop the clock. It also drops it low enough for it to show in responce measurements. However, this CPU saving cannot be leveraged for an increase in the headline number, because we are constrained elsewhere and whatever that constraint is, it is pretty "hard".

I am going to set-up the benchmark differently next week to measure actual CPU and/or frequency stats to see exactly what the gain is as well as look for the "wall" (whatever it is) we are hitting here.

Brgds,

A.

P.S. In order to get to this point I had to fix quite a few 3051/3053 derivatives. That breakage is across the board - pretty much everywhere and in every project.

Gerrits for these and an updated gerrit for the patchset (the current one has a bug) will follow next week.

A.



 

Ed

 

On Wed, Apr 22, 2015 at 4:42 AM, Anton Ivanov <anton.ivanov@...> wrote:

On 22/04/15 12:34, Anton Ivanov wrote:

On 21/04/15 22:56, Edward Warnicke wrote:

Anton,

 

Did you ever do end to end testing to see the impact of these proposed changes on performance?


No because I keep being dragged to firefight all kinds of stuff.

I am just about done with setting up the rig.


I'm curious :)


So am I, but it will probably take a day or two to reach the point where the test setup will satisfy my curiosity :(


Just to be clear - I have benchmarked the object instantiation with the existing code and with the new code quite extensively so the differences there are now known.

We have a guaranteed extra latency of 40-100 microseconds on anything and everything we do because of the current code.

A.





A.


 

Ed

 

On Tue, Apr 21, 2015 at 2:52 PM, Anton Ivanov <anton.ivanov@...> wrote:

Hi all,

I found one more item going through my notes from the call - the claimed estimate of performance impact for storing into datastore of data coming from network is wrong.

The given example was BGP which stores all data into the data store so supposedly if you change ser-des to use binary forms you are just moving the CPU load elsewhere. There should apparently be no difference.

So is it really "moving the CPU elsewhere"?

Current design:

    Sum = Deserialize binary from network + Convert to String + Pass to regexp for validation + instantiate object + move into store

Proposed fix assuming we do not fix the data store and data store is "as is":

    Sum = Deserialize + instantiate object + Convert to String + move into store


The regexp is not present in the second case - so even if the BI continues to use the string form and has no efficiency improvements you are looking at: 40 microseconds gain per IPv4 prefix and 100+ for each IPv6 prefix.

Situation with other use cases is similar. So with all due respect, Robert - you are quite wrong on this one. If we will be using any of the acceleration interfaces, it is not moving CPU elsewhere, it is a significant CPU saving.

Brgds,

A.



On 21/04/15 18:39, Anton Ivanov wrote:

Hi all,

First of all, continuing from the call - if there is general feeling that we should not be locking ourselves into the additional binary APIs then we should simply cut for Li the issue down to bug-fixing and make the classes expose only backwards compatible interfaces.

Reality is - we are buggy and non-v6 compliant. We can release the controller with the sticker "Legacy Equipment, v4 only" sticker on it, but this still leaves the corner cases of v4 prefix and Mac. So it will still be buggy.

I am going to go back to Robert's "Solve it at BI" suggestion.

I am probably missing something.

1. If there is a "union" like structure that sits behind an object (similar to current code generated from union) it has to use the _SAME_ backend data and the backend data should be in the canonical form and stored canonically on instantiation. How is this going to work out as code?

The current code generated to represent a yang union does not do that - it provides alternatives, each of which uses its own storage. If one part is generated and another one is not how does the generated part talk to the manual one and how do they use the same storage? Specifically, how does the string part (as expected by the current core components) talk to the canonicalized backend?

The deeper you go into this, the more it looks like zero generated code - all manual (for the 5 affected types - there are 5 types in total under discussion). Even then, I cannot form that code in my head (just yet), this is why I am proposing something which is BA only.

2. We are talking a grand total of 5 types here. There are 5 types in total across the core yang data models which predate yang by a very long time and have their unique canonicalization specifics described in earlier RFCs (or IEEE documents). Their canonical representation does not match the data in the yang model and is described in the comments:

    MacAddress
    Ipv4Address - optional, performance only
    Ipv4Prefix
    Ipv6Address
    Ipv6Prefix

A generic solution to generate polimorphic code to represent any type with a binary req is nice. I am all for it. But is it worth it to do that for 5 types? Also, these 5 types are special - you are not doing any network application without touching at least one of them.

So even if they end up being special that may be worth it. In fact, the easiest is to make them special in BA, special in BI and be done with it - it is probably a fraction of a percent or so of the effort required to fix generation.

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


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

 




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

 


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

 

 

 

 

 



Re: [Need Help] Arbitrary connection port is part of the node-id

Edward Warnicke <hagbard@...>
 

Not so tricky... we either get that dump or we are borked...

Ed

On Fri, Apr 24, 2015 at 2:07 PM, Amit Mandke (ammandke) <ammandke@...> wrote:
It sounds tricky, cause once you register for callbacks you can’t be sure of the sequence of all the updates right? Or even guaranty if each update would be processed?

So essentially you are letting go a sure-shot event where you received the connection to store the OVSDB node and relying on the future updates to create it.

I am not sure if that is the best thing to do.

-Amit


From: Edward Warnicke <hagbard@...>
Date: Friday, April 24, 2015 at 11:07 AM
To: "Prateek Garg (prategar)" <prategar@...>
Cc: "ovsdb-dev@..." <ovsdb-dev@...>

Subject: Re: [ovsdb-dev] [Need Help] Arbitrary connection port is part of the node-id

I had an idea last night as I was falling asleep that might be interesting.

How about we create the ovsdb-node in operational with the OpenVSwitchUpdateCommand (which should get tripped with the original dump of data from ovsdb on connect) rather than invoking OvsdbNodeCreatedCommand in the OvsdbConnectionInstance() constructor.  That way you have access to the info you need, don't have to do a select (and thus a new round trip) etc.

Thoughts?

Ed

On Wed, Apr 22, 2015 at 3:40 PM, Prateek Garg (prategar) <prategar@...> wrote:
This can be done in OvsdbNodeCreateCommand. The issue I see there is changing the signature of the OvsdbNodeCreateCommand’s constructor.
Let me know if its ok to change the signature and pass OvsdbClient.
However, I believe still we would need to run a select statement to get the system-id in OvsdbNodeCreateCommand.

Please let me know your thoughts.

Thanks
Prateek

From: Edward Warnicke <hagbard@...>
Date: Wednesday, April 22, 2015 at 3:26 PM

To: Prateek Garg <prategar@...>
Cc: "ovsdb-dev@..." <ovsdb-dev@...>, "ffernand@..." <ffernand@...>
Subject: Re: [ovsdb-dev] [Need Help] Arbitrary connection port is part of the node-id

And why change ConnectionInfo (that really really is info about the ip and port...)

Ed

On Wed, Apr 22, 2015 at 3:25 PM, Edward Warnicke <hagbard@...> wrote:
Prateek,

Question... why not in the OvsdbNodeCreateCommand where all of the other operational info is being created and written?

Ed

On Wed, Apr 22, 2015 at 3:22 PM, Prateek Garg (prategar) <prategar@...> wrote:
Hi Ed,

The way I am implementing this is:

In OvsdbConnectionManager’s connected method, I’ll set system-Id from external_ids of open_Vswitch table in ConnectionInfo key (I’ll modify yang to add systemId field in connectionInfo to add system-id). Therefore to get the system-id in OvsdbConnectionManager’s connected method, I need to execute select operation on open_Vswitch table. 
So later when OvsdbNodeCreateCommand is called with ConnectionInfo, I’ll have the systemId to write to operation store.

Please let me know your thoughts on this approach.

Regards
Prateek

From: Edward Warnicke <hagbard@...>
Date: Wednesday, April 22, 2015 at 2:58 PM
To: Prateek Garg <prategar@...>
Cc: "ovsdb-dev@..." <ovsdb-dev@...>, "ffernand@..." <ffernand@...>
Subject: Re: [ovsdb-dev] [Need Help] Arbitrary connection port is part of the node-id

Prateek,

Why are you doing a select? (curious) :)

Ed

On Wed, Apr 22, 2015 at 2:54 PM, Prateek Garg (prategar) <prategar@...> wrote:
Hi,

While implementing this use case I need some help using the select operation of ovsdb library. I am trying to read the Open_vSwitch table to get the data in external-ids. I am doing the following:

OpenVSwitch ovs = TyperUtils.getTypedRowWrapper(dbSchema, OpenVSwitch.class);

                transaction.add(op.select(ovs.getSchema()));

                ListenableFuture<List<OperationResult>> results = transaction.execute();

List<OperationResult> resultList = results.get();


I am getting resultList as:

[OperationResult [count=0, uuid=null, rows=[Row [columns={}]], error=null, details=null]]

Query sent to Ovs db is:

ovsdb-client transact '["Open_vSwitch",{"op":"select", "table":"Open_vSwitch", "columns":[],"where": []}]'


However, I want to send:

ovsdb-client transact '["Open_vSwitch",{"op":"select", "table":"Open_vSwitch", "columns":["external_ids"],"where": []}]'


It would be very helpful if someone could provide pointers on how to set column in select operation.


Regards

Prateek


From: Edward Warnicke <hagbard@...>
Date: Tuesday, April 21, 2015 at 1:18 PM
To: Prateek Garg <prategar@...>
Cc: "ffernand@..." <ffernand@...>, "ovsdb-dev@..." <ovsdb-dev@...>

Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the node-id

The config/operational synch is best handled a little differently.

When you try to config an ovsdb-node to connect... you don't *really* know the systemid... just the IP:port.

The way we solved this for bridges, and the way I'd advocate solving it here is:

1)  If you are configing a ovsdb-node, write its iid to the external-ids of the openvswitch table
2)  When you get an openvswitch table, if it has an iid in its external-ids, use that in the operational data store as its iid
3)  If you don't get an iid in its external-ids... use some reasonable heuristic to contruct one.

For #3... I don't currently see a reason *not* to use systemid presuming its guaranteed unique and we contruct some kind of reasonable
Uri from it.

Ed

On Tue, Apr 21, 2015 at 1:09 PM, Prateek Garg (prategar) <prategar@...> wrote:
Hi,

In my opinion, the we can replace the node-id of the ovsdb node in md-sal to contain system_id from external properties. This would make sure that the config and operation store are in synch in case the controller reconnects to the same ovs in tcp mode.
I’ll make these changes, update postman collection and submit for approval. 

Regards
Prateek

----------------------------------------------------------------------
Date: Mon, 20 Apr 2015 21:28:28 -0700
From: Edward Warnicke <hagbard@...>
To: Flavio Fernandes <ffernand@...>
Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the
node-id
Message-ID:
Content-Type: text/plain; charset="utf-8"

Make sure we build in the same mechanism of storing iids in external_ids
that we use for bridges so that if someone configures a connection as an
ovsdb-node, it comes *back* in operational store with the same iid...

Ed

On Mon, Apr 20, 2015 at 8:12 PM, Flavio Fernandes <ffernand@...>
wrote:


> On Apr 20, 2015, at 7:12 PM, Sharon Aicler (saichler) <
saichler@...> wrote:
>
> Hi,
> A further investigation by Amit has revealed that the system uuid is
automatically set by the OVS so we can use it out of the box to identify an
OVS instance. To see the external ID you can invoke the following cli:
>
> ovs-vsctl --columns=external-ids list open_vswitch
>
> looks like a win/win situation to me...:o)
>

ok!

? flavio



> Thanks,
>          Sharon.
> ________________________________________
ovsdb-dev-bounces@...] on behalf of Sharon Aicler
(saichler)
> Sent: Monday, April 20, 2015 3:41 PM
> To: Flavio Fernandes
> Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the node-id
>
> In that case you are kind of "gambling" that two of your dockers won't
choose the same arbitrary port...:o)
> In any case, we can't have the ID of an element arbitrary change all the
time...As a quick and dirty fix, i would drop the port (and the "behind a
NAT" scenario) so ovsdb id's would be predictable and not change per
connection (it can even change in run-time if there was some network
connectivity issue)...
>
> A more suitable solution is probably generating and assigning a uuid to
each of the managed instances, if one does not exist...a quick googling i
found the following cli method:
>
> ovs-vsctl set open_vswitch . external-ids:system-id='"${UUID}"'
>
>
> Thanks,
>         Sharon.
> ________________________________________
> From: Flavio Fernandes [ffernand@...]
> Sent: Monday, April 20, 2015 1:25 PM
> To: Sharon Aicler (saichler)
> Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the node-id
>
>> On Apr 20, 2015, at 3:24 PM, Sharon Aicler (saichler) <
saichler@...> wrote:
>>
>> Hi,
>> Sorry, but does't a docker has a unique ip?
>
> yes and no. ;) I?m used to see docker behind nat on the vm that hosts
the containers. Then, from
> 'outside' the vm, various ovs instances reached using the same ip, but
different ports. Like this:
>
>        docker run -p 16640:6640 blablabla
>        docker run -p 16641:6640 blablabla
>        docker run -p 16642:6640 blablabla
>        ?
>
> ? flavio
>
>
>
>> ________________________________________
>> From: Flavio Fernandes [ffernand@...]
>> Sent: Friday, April 17, 2015 4:23 AM
>> To: Sharon Aicler (saichler)
>> Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the
node-id
>>
>>> On Apr 16, 2015, at 6:53 PM, Sharon Aicler (saichler) <
saichler@...> wrote:
>>>
>>> Hi all,
>>> The node-id of an ovs bridge contains the arbitrary port of the
outgoing connection instance and looks something like the following:
>>>
>>> This creates an issue if i place something in the configuration store
and the connection goes down due to some reason, the node-id will change
each time the connection is lost or I restart ODL/OVSDB.
>>> Any reason for this? can't we just use the ip? i don't think you can
run two instances of OVS in the same VM?
>>>
>>
>> Hi Sharon,
>>
>> That is not true. I?ve seen a VM with many OVS instances running;
mostly in a docker environment.
>>
>> But I see your point. When OVS is connecting to ODL (i.e. active
method) the port is not predictable. When ODL connects to
>> an OVS (passive mode), ODL will need to know that port, tho; so the
solution to this problem should ideally work on both
>> scenarios.
>>
>> ? flavio
>>
>>
>>
>>>
>>> Thanks,
>>>        Sharon.
>>> _______________________________________________
>>> ovsdb-dev mailing list
> _______________________________________________
> ovsdb-dev mailing list

_______________________________________________
ovsdb-dev mailing list

-------------- next part --------------
An HTML attachment was scrubbed...







Re: [Need Help] Arbitrary connection port is part of the node-id

Amit Mandke (ammandke) <ammandke@...>
 

It sounds tricky, cause once you register for callbacks you can’t be sure of the sequence of all the updates right? Or even guaranty if each update would be processed?

So essentially you are letting go a sure-shot event where you received the connection to store the OVSDB node and relying on the future updates to create it.

I am not sure if that is the best thing to do.

-Amit


From: Edward Warnicke <hagbard@...>
Date: Friday, April 24, 2015 at 11:07 AM
To: "Prateek Garg (prategar)" <prategar@...>
Cc: "ovsdb-dev@..." <ovsdb-dev@...>
Subject: Re: [ovsdb-dev] [Need Help] Arbitrary connection port is part of the node-id

I had an idea last night as I was falling asleep that might be interesting.

How about we create the ovsdb-node in operational with the OpenVSwitchUpdateCommand (which should get tripped with the original dump of data from ovsdb on connect) rather than invoking OvsdbNodeCreatedCommand in the OvsdbConnectionInstance() constructor.  That way you have access to the info you need, don't have to do a select (and thus a new round trip) etc.

Thoughts?

Ed

On Wed, Apr 22, 2015 at 3:40 PM, Prateek Garg (prategar) <prategar@...> wrote:

This can be done in OvsdbNodeCreateCommand. The issue I see there is changing the signature of the OvsdbNodeCreateCommand’s constructor.
Let me know if its ok to change the signature and pass OvsdbClient.
However, I believe still we would need to run a select statement to get the system-id in OvsdbNodeCreateCommand.

Please let me know your thoughts.

Thanks
Prateek

From: Edward Warnicke <hagbard@...>
Date: Wednesday, April 22, 2015 at 3:26 PM

To: Prateek Garg <prategar@...>
Cc: "ovsdb-dev@..." <ovsdb-dev@...>, "ffernand@..." <ffernand@...>
Subject: Re: [ovsdb-dev] [Need Help] Arbitrary connection port is part of the node-id

And why change ConnectionInfo (that really really is info about the ip and port...)

Ed

On Wed, Apr 22, 2015 at 3:25 PM, Edward Warnicke <hagbard@...> wrote:
Prateek,

Question... why not in the OvsdbNodeCreateCommand where all of the other operational info is being created and written?

Ed

On Wed, Apr 22, 2015 at 3:22 PM, Prateek Garg (prategar) <prategar@...> wrote:
Hi Ed,

The way I am implementing this is:

In OvsdbConnectionManager’s connected method, I’ll set system-Id from external_ids of open_Vswitch table in ConnectionInfo key (I’ll modify yang to add systemId field in connectionInfo to add system-id). Therefore to get the system-id in OvsdbConnectionManager’s connected method, I need to execute select operation on open_Vswitch table. 
So later when OvsdbNodeCreateCommand is called with ConnectionInfo, I’ll have the systemId to write to operation store.

Please let me know your thoughts on this approach.

Regards
Prateek

From: Edward Warnicke <hagbard@...>
Date: Wednesday, April 22, 2015 at 2:58 PM
To: Prateek Garg <prategar@...>
Cc: "ovsdb-dev@..." <ovsdb-dev@...>, "ffernand@..." <ffernand@...>
Subject: Re: [ovsdb-dev] [Need Help] Arbitrary connection port is part of the node-id

Prateek,

Why are you doing a select? (curious) :)

Ed

On Wed, Apr 22, 2015 at 2:54 PM, Prateek Garg (prategar) <prategar@...> wrote:
Hi,

While implementing this use case I need some help using the select operation of ovsdb library. I am trying to read the Open_vSwitch table to get the data in external-ids. I am doing the following:

OpenVSwitch ovs = TyperUtils.getTypedRowWrapper(dbSchema, OpenVSwitch.class);

                transaction.add(op.select(ovs.getSchema()));

                ListenableFuture<List<OperationResult>> results = transaction.execute();

List<OperationResult> resultList = results.get();


I am getting resultList as:

[OperationResult [count=0, uuid=null, rows=[Row [columns={}]], error=null, details=null]]

Query sent to Ovs db is:

ovsdb-client transact '["Open_vSwitch",{"op":"select", "table":"Open_vSwitch", "columns":[],"where": []}]'


However, I want to send:

ovsdb-client transact '["Open_vSwitch",{"op":"select", "table":"Open_vSwitch", "columns":["external_ids"],"where": []}]'


It would be very helpful if someone could provide pointers on how to set column in select operation.


Regards

Prateek


From: Edward Warnicke <hagbard@...>
Date: Tuesday, April 21, 2015 at 1:18 PM
To: Prateek Garg <prategar@...>
Cc: "ffernand@..." <ffernand@...>, "ovsdb-dev@..." <ovsdb-dev@...>

Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the node-id

The config/operational synch is best handled a little differently.

When you try to config an ovsdb-node to connect... you don't *really* know the systemid... just the IP:port.

The way we solved this for bridges, and the way I'd advocate solving it here is:

1)  If you are configing a ovsdb-node, write its iid to the external-ids of the openvswitch table
2)  When you get an openvswitch table, if it has an iid in its external-ids, use that in the operational data store as its iid
3)  If you don't get an iid in its external-ids... use some reasonable heuristic to contruct one.

For #3... I don't currently see a reason *not* to use systemid presuming its guaranteed unique and we contruct some kind of reasonable
Uri from it.

Ed

On Tue, Apr 21, 2015 at 1:09 PM, Prateek Garg (prategar) <prategar@...> wrote:
Hi,

In my opinion, the we can replace the node-id of the ovsdb node in md-sal to contain system_id from external properties. This would make sure that the config and operation store are in synch in case the controller reconnects to the same ovs in tcp mode.
I’ll make these changes, update postman collection and submit for approval. 

Regards
Prateek

----------------------------------------------------------------------
Date: Mon, 20 Apr 2015 21:28:28 -0700
From: Edward Warnicke <hagbard@...>
To: Flavio Fernandes <ffernand@...>
Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the
node-id
Message-ID:
Content-Type: text/plain; charset="utf-8"

Make sure we build in the same mechanism of storing iids in external_ids
that we use for bridges so that if someone configures a connection as an
ovsdb-node, it comes *back* in operational store with the same iid...

Ed

On Mon, Apr 20, 2015 at 8:12 PM, Flavio Fernandes <ffernand@...>
wrote:


> On Apr 20, 2015, at 7:12 PM, Sharon Aicler (saichler) <
saichler@...> wrote:
>
> Hi,
> A further investigation by Amit has revealed that the system uuid is
automatically set by the OVS so we can use it out of the box to identify an
OVS instance. To see the external ID you can invoke the following cli:
>
> ovs-vsctl --columns=external-ids list open_vswitch
>
> looks like a win/win situation to me...:o)
>

ok!

? flavio



> Thanks,
>          Sharon.
> ________________________________________
ovsdb-dev-bounces@...] on behalf of Sharon Aicler
(saichler)
> Sent: Monday, April 20, 2015 3:41 PM
> To: Flavio Fernandes
> Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the node-id
>
> In that case you are kind of "gambling" that two of your dockers won't
choose the same arbitrary port...:o)
> In any case, we can't have the ID of an element arbitrary change all the
time...As a quick and dirty fix, i would drop the port (and the "behind a
NAT" scenario) so ovsdb id's would be predictable and not change per
connection (it can even change in run-time if there was some network
connectivity issue)...
>
> A more suitable solution is probably generating and assigning a uuid to
each of the managed instances, if one does not exist...a quick googling i
found the following cli method:
>
> ovs-vsctl set open_vswitch . external-ids:system-id='"${UUID}"'
>
>
> Thanks,
>         Sharon.
> ________________________________________
> From: Flavio Fernandes [ffernand@...]
> Sent: Monday, April 20, 2015 1:25 PM
> To: Sharon Aicler (saichler)
> Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the node-id
>
>> On Apr 20, 2015, at 3:24 PM, Sharon Aicler (saichler) <
saichler@...> wrote:
>>
>> Hi,
>> Sorry, but does't a docker has a unique ip?
>
> yes and no. ;) I?m used to see docker behind nat on the vm that hosts
the containers. Then, from
> 'outside' the vm, various ovs instances reached using the same ip, but
different ports. Like this:
>
>        docker run -p 16640:6640 blablabla
>        docker run -p 16641:6640 blablabla
>        docker run -p 16642:6640 blablabla
>        ?
>
> ? flavio
>
>
>
>> ________________________________________
>> From: Flavio Fernandes [ffernand@...]
>> Sent: Friday, April 17, 2015 4:23 AM
>> To: Sharon Aicler (saichler)
>> Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the
node-id
>>
>>> On Apr 16, 2015, at 6:53 PM, Sharon Aicler (saichler) <
saichler@...> wrote:
>>>
>>> Hi all,
>>> The node-id of an ovs bridge contains the arbitrary port of the
outgoing connection instance and looks something like the following:
>>>
>>> This creates an issue if i place something in the configuration store
and the connection goes down due to some reason, the node-id will change
each time the connection is lost or I restart ODL/OVSDB.
>>> Any reason for this? can't we just use the ip? i don't think you can
run two instances of OVS in the same VM?
>>>
>>
>> Hi Sharon,
>>
>> That is not true. I?ve seen a VM with many OVS instances running;
mostly in a docker environment.
>>
>> But I see your point. When OVS is connecting to ODL (i.e. active
method) the port is not predictable. When ODL connects to
>> an OVS (passive mode), ODL will need to know that port, tho; so the
solution to this problem should ideally work on both
>> scenarios.
>>
>> ? flavio
>>
>>
>>
>>>
>>> Thanks,
>>>        Sharon.
>>> _______________________________________________
>>> ovsdb-dev mailing list
> _______________________________________________
> ovsdb-dev mailing list

_______________________________________________
ovsdb-dev mailing list

-------------- next part --------------
An HTML attachment was scrubbed...






Re: [Need Help] Arbitrary connection port is part of the node-id

Edward Warnicke <hagbard@...>
 

I had an idea last night as I was falling asleep that might be interesting.

How about we create the ovsdb-node in operational with the OpenVSwitchUpdateCommand (which should get tripped with the original dump of data from ovsdb on connect) rather than invoking OvsdbNodeCreatedCommand in the OvsdbConnectionInstance() constructor.  That way you have access to the info you need, don't have to do a select (and thus a new round trip) etc.

Thoughts?

Ed

On Wed, Apr 22, 2015 at 3:40 PM, Prateek Garg (prategar) <prategar@...> wrote:
This can be done in OvsdbNodeCreateCommand. The issue I see there is changing the signature of the OvsdbNodeCreateCommand’s constructor.
Let me know if its ok to change the signature and pass OvsdbClient.
However, I believe still we would need to run a select statement to get the system-id in OvsdbNodeCreateCommand.

Please let me know your thoughts.

Thanks
Prateek

From: Edward Warnicke <hagbard@...>
Date: Wednesday, April 22, 2015 at 3:26 PM

To: Prateek Garg <prategar@...>
Cc: "ovsdb-dev@..." <ovsdb-dev@...>, "ffernand@..." <ffernand@...>
Subject: Re: [ovsdb-dev] [Need Help] Arbitrary connection port is part of the node-id

And why change ConnectionInfo (that really really is info about the ip and port...)

Ed

On Wed, Apr 22, 2015 at 3:25 PM, Edward Warnicke <hagbard@...> wrote:
Prateek,

Question... why not in the OvsdbNodeCreateCommand where all of the other operational info is being created and written?

Ed

On Wed, Apr 22, 2015 at 3:22 PM, Prateek Garg (prategar) <prategar@...> wrote:
Hi Ed,

The way I am implementing this is:

In OvsdbConnectionManager’s connected method, I’ll set system-Id from external_ids of open_Vswitch table in ConnectionInfo key (I’ll modify yang to add systemId field in connectionInfo to add system-id). Therefore to get the system-id in OvsdbConnectionManager’s connected method, I need to execute select operation on open_Vswitch table. 
So later when OvsdbNodeCreateCommand is called with ConnectionInfo, I’ll have the systemId to write to operation store.

Please let me know your thoughts on this approach.

Regards
Prateek

From: Edward Warnicke <hagbard@...>
Date: Wednesday, April 22, 2015 at 2:58 PM
To: Prateek Garg <prategar@...>
Cc: "ovsdb-dev@..." <ovsdb-dev@...>, "ffernand@..." <ffernand@...>
Subject: Re: [ovsdb-dev] [Need Help] Arbitrary connection port is part of the node-id

Prateek,

Why are you doing a select? (curious) :)

Ed

On Wed, Apr 22, 2015 at 2:54 PM, Prateek Garg (prategar) <prategar@...> wrote:
Hi,

While implementing this use case I need some help using the select operation of ovsdb library. I am trying to read the Open_vSwitch table to get the data in external-ids. I am doing the following:

OpenVSwitch ovs = TyperUtils.getTypedRowWrapper(dbSchema, OpenVSwitch.class);

                transaction.add(op.select(ovs.getSchema()));

                ListenableFuture<List<OperationResult>> results = transaction.execute();

List<OperationResult> resultList = results.get();


I am getting resultList as:

[OperationResult [count=0, uuid=null, rows=[Row [columns={}]], error=null, details=null]]

Query sent to Ovs db is:

ovsdb-client transact '["Open_vSwitch",{"op":"select", "table":"Open_vSwitch", "columns":[],"where": []}]'


However, I want to send:

ovsdb-client transact '["Open_vSwitch",{"op":"select", "table":"Open_vSwitch", "columns":["external_ids"],"where": []}]'


It would be very helpful if someone could provide pointers on how to set column in select operation.


Regards

Prateek


From: Edward Warnicke <hagbard@...>
Date: Tuesday, April 21, 2015 at 1:18 PM
To: Prateek Garg <prategar@...>
Cc: "ffernand@..." <ffernand@...>, "ovsdb-dev@..." <ovsdb-dev@...>

Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the node-id

The config/operational synch is best handled a little differently.

When you try to config an ovsdb-node to connect... you don't *really* know the systemid... just the IP:port.

The way we solved this for bridges, and the way I'd advocate solving it here is:

1)  If you are configing a ovsdb-node, write its iid to the external-ids of the openvswitch table
2)  When you get an openvswitch table, if it has an iid in its external-ids, use that in the operational data store as its iid
3)  If you don't get an iid in its external-ids... use some reasonable heuristic to contruct one.

For #3... I don't currently see a reason *not* to use systemid presuming its guaranteed unique and we contruct some kind of reasonable
Uri from it.

Ed

On Tue, Apr 21, 2015 at 1:09 PM, Prateek Garg (prategar) <prategar@...> wrote:
Hi,

In my opinion, the we can replace the node-id of the ovsdb node in md-sal to contain system_id from external properties. This would make sure that the config and operation store are in synch in case the controller reconnects to the same ovs in tcp mode.
I’ll make these changes, update postman collection and submit for approval. 

Regards
Prateek

----------------------------------------------------------------------
Date: Mon, 20 Apr 2015 21:28:28 -0700
From: Edward Warnicke <hagbard@...>
To: Flavio Fernandes <ffernand@...>
Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the
node-id
Message-ID:
Content-Type: text/plain; charset="utf-8"

Make sure we build in the same mechanism of storing iids in external_ids
that we use for bridges so that if someone configures a connection as an
ovsdb-node, it comes *back* in operational store with the same iid...

Ed

On Mon, Apr 20, 2015 at 8:12 PM, Flavio Fernandes <ffernand@...>
wrote:


> On Apr 20, 2015, at 7:12 PM, Sharon Aicler (saichler) <
saichler@...> wrote:
>
> Hi,
> A further investigation by Amit has revealed that the system uuid is
automatically set by the OVS so we can use it out of the box to identify an
OVS instance. To see the external ID you can invoke the following cli:
>
> ovs-vsctl --columns=external-ids list open_vswitch
>
> looks like a win/win situation to me...:o)
>

ok!

? flavio



> Thanks,
>          Sharon.
> ________________________________________
ovsdb-dev-bounces@...] on behalf of Sharon Aicler
(saichler)
> Sent: Monday, April 20, 2015 3:41 PM
> To: Flavio Fernandes
> Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the node-id
>
> In that case you are kind of "gambling" that two of your dockers won't
choose the same arbitrary port...:o)
> In any case, we can't have the ID of an element arbitrary change all the
time...As a quick and dirty fix, i would drop the port (and the "behind a
NAT" scenario) so ovsdb id's would be predictable and not change per
connection (it can even change in run-time if there was some network
connectivity issue)...
>
> A more suitable solution is probably generating and assigning a uuid to
each of the managed instances, if one does not exist...a quick googling i
found the following cli method:
>
> ovs-vsctl set open_vswitch . external-ids:system-id='"${UUID}"'
>
>
> Thanks,
>         Sharon.
> ________________________________________
> From: Flavio Fernandes [ffernand@...]
> Sent: Monday, April 20, 2015 1:25 PM
> To: Sharon Aicler (saichler)
> Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the node-id
>
>> On Apr 20, 2015, at 3:24 PM, Sharon Aicler (saichler) <
saichler@...> wrote:
>>
>> Hi,
>> Sorry, but does't a docker has a unique ip?
>
> yes and no. ;) I?m used to see docker behind nat on the vm that hosts
the containers. Then, from
> 'outside' the vm, various ovs instances reached using the same ip, but
different ports. Like this:
>
>        docker run -p 16640:6640 blablabla
>        docker run -p 16641:6640 blablabla
>        docker run -p 16642:6640 blablabla
>        ?
>
> ? flavio
>
>
>
>> ________________________________________
>> From: Flavio Fernandes [ffernand@...]
>> Sent: Friday, April 17, 2015 4:23 AM
>> To: Sharon Aicler (saichler)
>> Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the
node-id
>>
>>> On Apr 16, 2015, at 6:53 PM, Sharon Aicler (saichler) <
saichler@...> wrote:
>>>
>>> Hi all,
>>> The node-id of an ovs bridge contains the arbitrary port of the
outgoing connection instance and looks something like the following:
>>>
>>> This creates an issue if i place something in the configuration store
and the connection goes down due to some reason, the node-id will change
each time the connection is lost or I restart ODL/OVSDB.
>>> Any reason for this? can't we just use the ip? i don't think you can
run two instances of OVS in the same VM?
>>>
>>
>> Hi Sharon,
>>
>> That is not true. I?ve seen a VM with many OVS instances running;
mostly in a docker environment.
>>
>> But I see your point. When OVS is connecting to ODL (i.e. active
method) the port is not predictable. When ODL connects to
>> an OVS (passive mode), ODL will need to know that port, tho; so the
solution to this problem should ideally work on both
>> scenarios.
>>
>> ? flavio
>>
>>
>>
>>>
>>> Thanks,
>>>        Sharon.
>>> _______________________________________________
>>> ovsdb-dev mailing list
> _______________________________________________
> ovsdb-dev mailing list

_______________________________________________
ovsdb-dev mailing list

-------------- next part --------------
An HTML attachment was scrubbed...






Re: Integration of Controller with OVSDB Server

Sam Hague
 

LNT,

there are multiple examples in the OVSDB southbound code. An easy start is to look at the OvsdbDatachangeListener. Simply change use the Operational datastore instead of the Configuration in the Iid path and you will receive ovsdb updates.

The SouthboundIT code shows some simple methods to initiate connections to the OVSDB nodes and how to add and remove Bridges and Ports.

This wiki [1] describes some methods on how to drive the southbound via the RESTCONF.

Thanks, Sam

[1] https://wiki.opendaylight.org/view/OVSDB:MDSAL_Southbound

----- Original Message -----
From: "Lnt OpenDayLight" <opendaylight.lnt@...>
To: ovsdb-dev@..., controller-dev-request@..., "controller-dev"
<controller-dev@...>, "Sam Hague" <shague@...>
Sent: Friday, April 24, 2015 5:44:52 AM
Subject: Integration of Controller with OVSDB Server

Hi

We would like to know how to integrate or connect between Controller and
OVSDB server.

Currently we are using Toaster Step by Step sample project and we would
like to access Bridge table information in this MD-SAL application. But we
are not able to do establish database OVSDB Server with our provider.

Could you please provide us any URL or sample examples available?

Regards,
LNT


Integration of Controller with OVSDB Server

LNT-OpenDayLight
 

Hi

We would like to know how to integrate or connect between Controller and OVSDB server.

Currently we are using Toaster Step by Step sample project and we would like to access Bridge table information in this MD-SAL application. But we are not able to do establish database OVSDB Server with our provider. 

Could you please provide us any URL or sample examples available?

Regards,
LNT


Re: [Need Help] Arbitrary connection port is part of the node-id

Edward Warnicke <hagbard@...>
 

Sam,

The thinking there is to do what we do for bridges... put the iid from config in the external-ids of OpenVSwitch, and on the operational side if that's present use it for the iid there too :)

Ed

On Thu, Apr 23, 2015 at 5:14 AM, Sam Hague <shague@...> wrote:
What was the solution for the cases where ODL connects to the ovsdb nodes? In that case odl only has the ip:port of the node to make the outgoing connection.

The idea in this thread is to use the system-id, but that looks to only cover the case where the ovsdb node connects to ODL.

Thanks, Sam

----- Original Message -----
> From: "Amit Mandke (ammandke)" <ammandke@...>
> To: "Prateek Garg (prategar)" <prategar@...>, "Edward Warnicke" <hagbard@...>,
> ovsdb-dev@..., ffernand@...
> Sent: Wednesday, April 22, 2015 7:20:02 PM
> Subject: Re: [ovsdb-dev] [Need Help] Arbitrary connection port is part of the node-id
>
> Just to address the question from following mail. The way you specify the
> columns to select operation is you call setColumn(..) on a select.
>
> Example:
>
> Select<GenericTableSchema> bridgeSelect = op.select(bridge.getSchema());
> List<String> columns = new ArrayList<>();
> columns.add(bridge.getNameColumn().getSchema().getName());
> bridgeSelect.setColumns(columns);
>
> -Amit
>
>
> From: "Prateek Garg (prategar)" < prategar@... >
> Date: Wednesday, April 22, 2015 at 2:54 PM
> To: Edward Warnicke < hagbard@... >, " ovsdb-dev@...
> " < ovsdb-dev@... >, " ffernand@... " <
> ffernand@... >
> Subject: Re: [ovsdb-dev] [Need Help] Arbitrary connection port is part of the
> node-id
>
> Hi,
>
> While implementing this use case I need some help using the select operation
> of ovsdb library. I am trying to read the Open_vSwitch table to get the data
> in external-ids. I am doing the following:
>
>
> OpenVSwitch ovs = TyperUtils.getTypedRowWrapper(dbSchema, OpenVSwitch.class);
>
> transaction.add( op.select(ovs.getSchema() ));
>
> ListenableFuture<List<OperationResult>> results = transaction.execute();
>
> List<OperationResult> resultList = results.get();
>
>
>
>
> I am getting resultList as:
>
> [OperationResult [count=0, uuid=null, rows=[Row [columns={}]], error=null,
> details=null]]
>
> Query sent to Ovs db is:
>
> ovsdb-client transact '["Open_vSwitch",{"op":"select",
> "table":"Open_vSwitch", "columns":[], "where": []}]'
>
>
>
>
> However, I want to send:
>
> ovsdb-client transact '["Open_vSwitch",{"op":"select",
> "table":"Open_vSwitch", "columns":["external_ids"] ,"where": []}]'
>
>
>
>
> It would be very helpful if someone could provide pointers on how to set
> column in select operation.
>
>
>
>
> Regards
>
> Prateek
>
> From: Edward Warnicke < hagbard@... >
> Date: Tuesday, April 21, 2015 at 1:18 PM
> To: Prateek Garg < prategar@... >
> Cc: " ffernand@... " < ffernand@... >, "
> ovsdb-dev@... " < ovsdb-dev@... >
> Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the node-id
>
> The config/operational synch is best handled a little differently.
>
> When you try to config an ovsdb-node to connect... you don't *really* know
> the systemid... just the IP:port.
>
> The way we solved this for bridges, and the way I'd advocate solving it here
> is:
>
> 1) If you are configing a ovsdb-node, write its iid to the external-ids of
> the openvswitch table
> 2) When you get an openvswitch table, if it has an iid in its external-ids,
> use that in the operational data store as its iid
> 3) If you don't get an iid in its external-ids... use some reasonable
> heuristic to contruct one.
>
> For #3... I don't currently see a reason *not* to use systemid presuming its
> guaranteed unique and we contruct some kind of reasonable
> Uri from it.
>
> Ed
>
> On Tue, Apr 21, 2015 at 1:09 PM, Prateek Garg (prategar) < prategar@...
> > wrote:
>
>
>
> Hi,
>
> In my opinion, the we can replace the node-id of the ovsdb node in md-sal to
> contain system_id from external properties. This would make sure that the
> config and operation store are in synch in case the controller reconnects to
> the same ovs in tcp mode.
> I’ll make these changes, update postman collection and submit for approval.
>
> Regards
> Prateek
>
> ----------------------------------------------------------------------
> Date: Mon, 20 Apr 2015 21:28:28 -0700
> From: Edward Warnicke < hagbard@... >
> To: Flavio Fernandes < ffernand@... >
> Cc: " ovsdb-dev@... "
> < ovsdb-dev@... >
> Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the
> node-id
> Message-ID:
> < CAFVSqg0kmBcNkGZ50vN-a0TgKswJeRNHVR-1PVvW40ukZuMtYw@... >
> Content-Type: text/plain; charset="utf-8"
>
> Make sure we build in the same mechanism of storing iids in external_ids
> that we use for bridges so that if someone configures a connection as an
> ovsdb-node, it comes *back* in operational store with the same iid...
>
> Ed
>
> On Mon, Apr 20, 2015 at 8:12 PM, Flavio Fernandes < ffernand@... >
> wrote:
>
>
>
>
>
> > On Apr 20, 2015, at 7:12 PM, Sharon Aicler (saichler) <
> saichler@... > wrote:
> >
> > Hi,
> > A further investigation by Amit has revealed that the system uuid is
> automatically set by the OVS so we can use it out of the box to identify an
> OVS instance. To see the external ID you can invoke the following cli:
> >
> > ovs-vsctl --columns=external-ids list open_vswitch
> >
> > looks like a win/win situation to me...:o)
> >
>
> ok!
>
> ? flavio
>
>
>
> > Thanks,
> > Sharon.
> > ________________________________________
> > From: ovsdb-dev-bounces@... [
> ovsdb-dev-bounces@... ] on behalf of Sharon Aicler
> (saichler)
> > Sent: Monday, April 20, 2015 3:41 PM
> > To: Flavio Fernandes
> > Cc: ovsdb-dev@...
> > Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the node-id
> >
> > In that case you are kind of "gambling" that two of your dockers won't
> choose the same arbitrary port...:o)
> > In any case, we can't have the ID of an element arbitrary change all the
> time...As a quick and dirty fix, i would drop the port (and the "behind a
> NAT" scenario) so ovsdb id's would be predictable and not change per
> connection (it can even change in run-time if there was some network
> connectivity issue)...
> >
> > A more suitable solution is probably generating and assigning a uuid to
> each of the managed instances, if one does not exist...a quick googling i
> found the following cli method:
> >
> > ovs-vsctl set open_vswitch . external-ids:system-id='"${UUID}"'
> >
> >
> > Thanks,
> > Sharon.
> > ________________________________________
> > From: Flavio Fernandes [ ffernand@... ]
> > Sent: Monday, April 20, 2015 1:25 PM
> > To: Sharon Aicler (saichler)
> > Cc: ovsdb-dev@...
> > Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the node-id
> >
> >> On Apr 20, 2015, at 3:24 PM, Sharon Aicler (saichler) <
> saichler@... > wrote:
> >>
> >> Hi,
> >> Sorry, but does't a docker has a unique ip?
> >
> > yes and no. ;) I?m used to see docker behind nat on the vm that hosts
> the containers. Then, from
> > 'outside' the vm, various ovs instances reached using the same ip, but
> different ports. Like this:
> >
> > docker run -p 16640:6640 blablabla
> > docker run -p 16641:6640 blablabla
> > docker run -p 16642:6640 blablabla
> > ?
> >
> > ? flavio
> >
> >
> >
> >> ________________________________________
> >> From: Flavio Fernandes [ ffernand@... ]
> >> Sent: Friday, April 17, 2015 4:23 AM
> >> To: Sharon Aicler (saichler)
> >> Cc: ovsdb-dev@...
> >> Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the
> node-id
> >>
> >>> On Apr 16, 2015, at 6:53 PM, Sharon Aicler (saichler) <
> saichler@... > wrote:
> >>>
> >>> Hi all,
> >>> The node-id of an ovs bridge contains the arbitrary port of the
> outgoing connection instance and looks something like the following:
> >>> ovsdb:// 10.156.48.239:39490/bridge/br-ex
> >>>
> >>> This creates an issue if i place something in the configuration store
> and the connection goes down due to some reason, the node-id will change
> each time the connection is lost or I restart ODL/OVSDB.
> >>> Any reason for this? can't we just use the ip? i don't think you can
> run two instances of OVS in the same VM?
> >>>
> >>
> >> Hi Sharon,
> >>
> >> That is not true. I?ve seen a VM with many OVS instances running;
> mostly in a docker environment.
> >>
> >> But I see your point. When OVS is connecting to ODL (i.e. active
> method) the port is not predictable. When ODL connects to
> >> an OVS (passive mode), ODL will need to know that port, tho; so the
> solution to this problem should ideally work on both
> >> scenarios.
> >>
> >> ? flavio
> >>
> >>
> >>
> >>>
> >>> Thanks,
> >>> Sharon.
> >>> _______________________________________________
> >>> 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
>
> _______________________________________________
> ovsdb-dev mailing list
> ovsdb-dev@...
> https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.opendaylight.org/pipermail/ovsdb-dev/attachments/20150420/0ac78b3d/attachment-0001.html
> >
>
>
> _______________________________________________
> ovsdb-dev mailing list
> ovsdb-dev@...
> https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
>


Re: odl ovsdb net-girt pipeline part 1 is finished

Flavio Fernandes <ffernand@...>
 


On Apr 23, 2015, at 10:28 AM, Anil Vishnoi <vishnoianil@...> wrote:

This is really a great tutorial, thanks a lot for doing it.


Thanks Anil. Sorry for the delay; I now feel that this should have been done a year go.
Better late than ever, I guess. ;) I think having this one will be a good stepping stone to
describe L3 fwd; which it on top of my list.


 Can we link this from the ovsdb wiki main page, under external link session or any other appropriate place?


Good idea. I’ve added it here [1].

— flavio

PS. Sorry for the typo in the subject! My spell checker automatically assumed that I meant to say ‘girt’ when
I typed virt. ARGH!!! ;)




Thanks
Anil

On Thu, Apr 23, 2015 at 6:33 PM, Flavio Fernandes <ffernand@...> wrote:
Hi folks,

I’m finished with part 1 of the pipeline description used in ovsdb’s net-virt:


if you can please, take a peek and let me know if it clarifies anything. ;)

Best,

— flavio





--
Thanks
Anil


Re: odl ovsdb net-girt pipeline part 1 is finished

Anil Vishnoi
 

This is really a great tutorial, thanks a lot for doing it.

 Can we link this from the ovsdb wiki main page, under external link session or any other appropriate place?

Thanks
Anil

On Thu, Apr 23, 2015 at 6:33 PM, Flavio Fernandes <ffernand@...> wrote:
Hi folks,

I’m finished with part 1 of the pipeline description used in ovsdb’s net-virt:


if you can please, take a peek and let me know if it clarifies anything. ;)

Best,

— flavio





--
Thanks
Anil

3381 - 3400 of 4855