20:00:07 <tbachman> #startmeeting ovsdb_weekly_call
20:00:07 <odl_meetbot> Meeting started Tue Feb 10 20:00:07 2015 UTC.  The chair is tbachman. Information about MeetBot at http://ci.openstack.org/meetbot.html.
20:00:07 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:07 <odl_meetbot> The meeting name has been set to 'ovsdb_weekly_call'
20:00:13 <tbachman> #chair shague
20:00:13 <odl_meetbot> Current chairs: shague tbachman
20:00:16 <tbachman> #chair flaviof
20:00:16 <odl_meetbot> Current chairs: flaviof shague tbachman
20:00:23 <tbachman> #topic agenda
20:00:42 <tbachman> #link https://meetings.opendaylight.org/opendaylight-ovsdb/2015/ovsdb_weekly_call/opendaylight-ovsdb-ovsdb_weekly_call.2015-01-27-20.00.html Last recorded meeting minutes
20:02:57 <tbachman> 48 members — getting up there :)
20:03:21 <tbachman> #topic Trello Board
20:03:59 <tbachman> #link https://trello.com/b/ddIvDQE0/ovs-openstack Trello Board for the OVSDB project
20:05:48 <tbachman> #info shague says the NSF migration is waiting on go-ahead from michal_rehak
20:06:21 <tbachman> #info vishnoianil and shague have pushed patches to remove AD-SAL pieces
20:06:42 <tbachman> #info shague and vishnoianil working on replacing AD-SAL Node with MD-SAL Node
20:06:54 <tbachman> #info shague eventually replace activation with the config subsystem
20:07:05 <tbachman> #info edwarnicke offers his help with the config subsystem
20:07:39 <tbachman> #info The Neutron Services is eligible for a creation review at this Thursday’s TSC meeting
20:07:52 <odp-gerritbot> Flavio Fernandes proposed a change to ovsdb: Fix ovsdb-ovs-full-integration-daily  https://git.opendaylight.org/gerrit/15119
20:07:53 <tbachman> #info colindixon says it’s hard for him to imagine the Creation Review not going through
20:08:15 <tbachman> flaviof: mixing up commits in our meeting minutes  :x
20:08:16 <tbachman> lol
20:08:48 <cdub> debugging a network live via webex
20:08:51 <tbachman> lol
20:09:07 <tbachman> #info flaviof says a lot of progress has been made on networking-odl plugin
20:09:29 <tbachman> #info the openstack folks want to remove everything that’s not pure openstack and turn it into a plugin
20:09:52 <tbachman> #info flaviof says there’s still work to be done to connect things like LBaaS, FW, and L3
20:10:04 <tbachman> #info flaviof says the critical piece is the integration with gerrit and tempest testing
20:10:53 <tbachman> #info Swami asks what the services work is — pulling from a repo?
20:11:07 <tbachman> #info flaviof says the first one is a final gerrit to remove all the ODL stuff from the devstack repo
20:11:56 <tbachman> #info flaviof says plaurin_ is working on the “entry points” in the config, and is looking for help from Swami and mestery, to take the out of tree work and plug it in (i.e. not use the L3 agent way, but now pass this responsibility to ODL)
20:12:20 <tbachman> #info shague says that stuff is important for supporting the back-end tempest testing so that OpenStack and ODL can integrate
20:12:45 <tbachman> #info LuisGomez asks shague if they’re trying to get this testing going in the LF infrastructure
20:12:48 <tbachman> #info flaviof says yes
20:13:15 <tbachman> #info LuisGomez asks if they’ve gotten any input from the LF infrastructure folks — he’s been looking for the same things to support the needs of the integration team
20:13:43 <tbachman> #info flaviof says the task right now is to make sure that openstack doesn’t break ODL — i.e. a changing openstack vs. a stable ODL release
20:14:03 <tbachman> #info flaviof says that LuisGomez is probably looking for the opposite — ODL changes affecting external projects
20:14:07 <tbachman> #info LuisGomez says that’s the case
20:14:29 <tbachman> #info LuisGomez asks if flaviof has had any issue with Vagrant, etc.?
20:16:12 <tbachman> #info flaviof says there’s a jenkins job in OVSDB (not yet in JJB) that spawns a special VM and does an all-in-one openstack deployment
20:16:33 <tbachman> #info flaviof says that tempest is one of the things they’d do there
20:16:42 <tbachman> #info LuisGomez asks if Vagrant is used in this setup
20:16:58 <tbachman> #info flaviof says no, not in this one, and has heard from LF folks that doing things in Vagrant is a nightmare
20:17:45 <tbachman> #info shague says the goal is a multi-node deployment
20:19:33 <tbachman> #info edwarnicke has submitted a bunch of new patches for the MD-SAL OVSDB southbound
20:19:56 <tbachman> edwarnicke:  https://git.opendaylight.org/gerrit/14877
20:19:59 <edwarnicke> #link https://git.opendaylight.org/gerrit/#/q/status:open+project:ovsdb+branch:master+topic:mdsal_ovsdb_sba <- ovsdb mdsal sb patches
20:20:08 <tbachman> edwarnicke: thx :)
20:20:19 <tbachman> #info You can do both active and passive mode connecting
20:20:30 <tbachman> #info snackewm provided a patch so that the passive-node delete works
20:20:48 <tbachman> #info There are patches that bring in the infa for the monitor requests
20:21:08 <tbachman> #info There’s also a patch that listens in the config store for the OVDSB bridge nodes and retrieves the client
20:21:57 <tbachman> #info edwarnicke says we need to get some of the data in the operational data store before pushing things down; would be nice to be able to look up th bridge to determine handles for talking to different elements
20:22:09 <tbachman> #info edwarnicke says it’s the translation between the model and the row/column table objects
20:22:20 <tbachman> #info vishnoianil says taht will be done by the 12th
20:23:10 <tbachman> #info shague asks if there’s any UT for this
20:23:20 <tbachman> #info edwarnicke  says he’ll feel much better as more tests are put in place
20:24:01 <tbachman> #info edwarnicke asks about the docker-based testing
20:24:45 <tbachman> #info flaviof says the docker stuff was useful for version testing against different revs of OVS
20:24:51 <tbachman> #info edwarnicke asks if there’s a version in the schema
20:24:57 <tbachman> #info shague says that’s a field in the tables
20:25:47 <tbachman> #info edwarnicke asks for some examples in the ways that schema shifts between versions
20:26:05 <tbachman> #action flaviof to come up with concrete examples of schema shifts
20:26:57 <tbachman> #info shague says the nicira extensions for tunnels are one example; used to be part of the port, now are flow-based
20:27:51 <tbachman> #topic clustering
20:28:36 <flaviof> #info ed asks colin to be nice
20:28:38 <tbachman> #info colindixon says that clustering comes down to 3 things that are hard in the current model
20:28:41 <tbachman> flaviof: lol!
20:28:41 <flaviof> #undo
20:28:41 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x192ed50>
20:28:53 <tbachman> flaviof: you undid me :)
20:28:53 <edwarnicke> #info notes Colin is usually nice, if perhaps sardonic ;)
20:29:02 <flaviof> lol
20:29:04 <tbachman> lol
20:29:40 <flaviof> #info colindixon says that clustering comes down to 3 things that are hard in the current model
20:29:43 <tbachman> #info colindixon says you need to figure out what the state is, then you have to model it, and then you have to make your data change notification listeners to work correctly
20:29:49 <tbachman> flaviof: thx ;)
20:29:59 <flaviof> sorry tbachman u r too fast
20:30:01 <tbachman> flaviof: now you stole the minute credit ;)
20:30:02 <tbachman> lol
20:30:06 <flaviof> lol
20:30:14 * tbachman is just having a go with flaviof
20:31:38 <tbachman> #info shague says with the OVSDB use case, it pulls in the DB, and when this goes to clustering, how does this map in ODL
20:32:21 <tbachman> #info colindixon points out that clustering does not address failover — just recovery of state
20:33:43 <cdub> tbachman: you're slwoing down
20:33:48 <tbachman> lol
20:33:59 <tbachman> cdub: colindixon burnt out my fingers
20:34:00 <tbachman> nothing but nubs
20:34:22 <cdub> ;)
20:34:24 <tbachman> cdub: we have a recording :)
20:34:51 <tbachman> #info For deep discussion on clustering and failover behaviors, please see the webex recording at about 30 minutes in
20:34:54 <tbachman> cdub: ^^^^
20:35:02 <flaviof> lol
20:35:18 * tbachman exercises creative laziness
20:35:22 <cdub> tbachman: well done
20:35:28 <tbachman> lol
20:36:01 <tbachman> #info vishnoianil says all the connection caching is at the library level
20:36:38 <tbachman> #info vishnoianil says in a clustered configuration, it’s okay if a node goes down; but what happens if a heartbeat is lost and a new leader is elected (i.e. connection is stil there, even though the cluster leader went down)
20:36:59 <cdub> that's a core part of clustering
20:37:02 <tbachman> #info colindixon says that has to be handled somehow out of band
20:37:32 <cdub> it's split brain, and you need to fence in some way
20:37:34 <tbachman> #info colindixon says it is possible for a 3-node cluster for one node to be operating in the past, yet still have connections to local things
20:37:51 <tbachman> #info cdub says this is a split brain scenario, and it needs to be fenced in some way
20:38:22 <tbachman> #info colindixon says he doesn’t know if OVSDB provides any such mechanism
20:38:42 <tbachman> #info vishnoianil says there are two connections involved — OpenFlow plugin and OVSDB
20:39:07 <tbachman> #info colindixon says one way to deal with this is to piggy-back on openflow (whoever OpenFlow controller is, have OVSDB follow)
20:39:17 <tbachman> cdub: white picket fence?
20:39:22 <cdub> tbachman: heh
20:39:31 <tbachman> #info colindixon asks if OVSDB has any way to deal with this
20:39:40 <tbachman> #info shague says you can have multpiple managers
20:39:51 <tbachman> #info colindixon asks if you can ask an OVSDB manager who it’s managers are
20:39:57 <tbachman> #info shague says there is a table for this
20:40:11 <tbachman> #info colindixon says that this can be used — where the manager writes themselves into the table
20:40:19 <tbachman> #info shague says you can also be a listener
20:40:25 <tbachman> #info colindixon asks if this state is kept in the table
20:40:35 <tbachman> #info shague says he doesn’t believe so
20:41:05 <tbachman> #info colindixon says that if someone’s going to take over node management, you would have at most 1 instance of the OSVDB plugin attached to the switch at any given time
20:41:43 <tbachman> #info you can have all the nodes in the cluster connected, but only one node desginating themselves as the master somehow
20:43:10 <cdub> white picket fence == stonith
20:43:20 <tbachman> lol
20:43:30 <tbachman> #info edwarnicke asks about the use of external_ids in the OVSDB tables
20:43:42 <tbachman> #info edwarnicke asks if we can write an external_id for whatever we consider to be the master
20:44:11 <cdub> there's also other_config
20:44:16 <tbachman> #info shague says external_ids are used so the node can identify itself to the management piece
20:44:22 <tbachman> #info cdub says the other_config can be used
20:45:06 <tbachman> #info edwarnicke says it feels like doing this allows us to determine the rightful owner, so that stonith can be performed
20:45:18 * tbachman prefers stonith to “shot in the head"
20:45:19 <tbachman> :o
20:46:06 <tbachman> #info edwarnicke says one way to discover the master is gone by listening to updates on the managers table
20:46:30 <tbachman> #info colindixon says that only works if every cluster instance is connected to every node — otherwise when the master goes down, you stop getting updates
20:46:52 <tbachman> great lesson in managing distributed state :)
20:47:59 <tbachman> #info the advantage of the complete connectivity model is that failures in the cluster, it’s all internal
20:48:34 * tbachman has to duck out for a sec….
20:51:03 * tbachman jumps back in
20:51:30 <tbachman> #info colindixon says that load balancers are sometimes deployed between teh devices connecting to the controller and the controller
20:51:47 <tbachman> #info edwarnicke says load balancers would have to understand all the way down to the guts of the OVSDB protocol
20:52:16 <tbachman> #info colindixon says first thing first: worry about internal cluster state; address failover second
20:52:40 <tbachman> #info shague says the main request was to get the clustering support in; sounds like this addresses the needs of the users
20:53:03 <tbachman> #info edwarnicke agrees, but wants to make sure that controller node local and internal state is the only data cached (e.g. in hash-maps)
20:53:37 <tbachman> #info shague says the schema is down in the lib; if the node goes away, the schema goes away
20:54:01 <tbachman> #info shague says in order to drive OVSDB, you need that schema; on a reconnect, you get the schema back
20:54:32 <cdub> we've had this theory going for a while now, sounds like we should make test case around this
20:54:39 <tbachman> #info colindixon says do not store any state in the cluster that you can easily rebuild
20:54:43 <tbachman> cdub: +1k ;)
20:55:06 <tbachman> #info colindixon says it’s a lot easier to handle the lazy loading of caches
20:57:35 <tbachman> #info flaviof says there are a bunch of gerrits that edwarnicke needs merging — asks if shague or vishnoianil can look at these
20:57:45 <tbachman> #action shague and vishnoianil to look at edwarnicke’s gerrits
20:58:33 <tbachman> #info colindixon says his suggestion is to use the gerrit comments where possible, moving to live discussion if needed
21:02:27 * tbachman stops scribing during discussion on TDD vs. other methods
21:02:50 <colindixon> tbachman: that’s right
21:03:04 <cdub> uh-oh, somebody pushed the wrong button
21:03:07 <tbachman> lol
21:03:49 <dneary> tbachman, awesome minutes
21:03:58 <dneary> tbachman, Thank you!
21:03:59 <tbachman> dneary: glad to help
21:04:04 <tbachman> np! :)
21:04:11 <tbachman> #endmeeting