#opendaylight-ovsdb: ovsdb_weekly_call

Meeting started by tbachman at 20:00:07 UTC (full logs).

Meeting summary

  1. agenda (tbachman, 20:00:23)
    1. 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 (tbachman, 20:00:42)

  2. Trello Board (tbachman, 20:03:21)
    1. https://trello.com/b/ddIvDQE0/ovs-openstack Trello Board for the OVSDB project (tbachman, 20:03:59)
    2. shague says the NSF migration is waiting on go-ahead from michal_rehak (tbachman, 20:05:48)
    3. vishnoianil and shague have pushed patches to remove AD-SAL pieces (tbachman, 20:06:21)
    4. shague and vishnoianil working on replacing AD-SAL Node with MD-SAL Node (tbachman, 20:06:42)
    5. shague eventually replace activation with the config subsystem (tbachman, 20:06:54)
    6. edwarnicke offers his help with the config subsystem (tbachman, 20:07:05)
    7. The Neutron Services is eligible for a creation review at this Thursday’s TSC meeting (tbachman, 20:07:39)
    8. colindixon says it’s hard for him to imagine the Creation Review not going through (tbachman, 20:07:53)
    9. flaviof says a lot of progress has been made on networking-odl plugin (tbachman, 20:09:07)
    10. the openstack folks want to remove everything that’s not pure openstack and turn it into a plugin (tbachman, 20:09:29)
    11. flaviof says there’s still work to be done to connect things like LBaaS, FW, and L3 (tbachman, 20:09:52)
    12. flaviof says the critical piece is the integration with gerrit and tempest testing (tbachman, 20:10:04)
    13. Swami asks what the services work is — pulling from a repo? (tbachman, 20:10:53)
    14. flaviof says the first one is a final gerrit to remove all the ODL stuff from the devstack repo (tbachman, 20:11:07)
    15. 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) (tbachman, 20:11:56)
    16. shague says that stuff is important for supporting the back-end tempest testing so that OpenStack and ODL can integrate (tbachman, 20:12:20)
    17. LuisGomez asks shague if they’re trying to get this testing going in the LF infrastructure (tbachman, 20:12:45)
    18. flaviof says yes (tbachman, 20:12:48)
    19. 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 (tbachman, 20:13:15)
    20. 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 (tbachman, 20:13:43)
    21. flaviof says that LuisGomez is probably looking for the opposite — ODL changes affecting external projects (tbachman, 20:14:03)
    22. LuisGomez says that’s the case (tbachman, 20:14:07)
    23. LuisGomez asks if flaviof has had any issue with Vagrant, etc.? (tbachman, 20:14:29)
    24. 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 (tbachman, 20:16:12)
    25. flaviof says that tempest is one of the things they’d do there (tbachman, 20:16:33)
    26. LuisGomez asks if Vagrant is used in this setup (tbachman, 20:16:42)
    27. flaviof says no, not in this one, and has heard from LF folks that doing things in Vagrant is a nightmare (tbachman, 20:16:58)
    28. shague says the goal is a multi-node deployment (tbachman, 20:17:45)
    29. edwarnicke has submitted a bunch of new patches for the MD-SAL OVSDB southbound (tbachman, 20:19:33)
    30. https://git.opendaylight.org/gerrit/#/q/status:open+project:ovsdb+branch:master+topic:mdsal_ovsdb_sba <- ovsdb mdsal sb patches (edwarnicke, 20:19:59)
    31. You can do both active and passive mode connecting (tbachman, 20:20:19)
    32. snackewm provided a patch so that the passive-node delete works (tbachman, 20:20:30)
    33. There are patches that bring in the infa for the monitor requests (tbachman, 20:20:48)
    34. There’s also a patch that listens in the config store for the OVDSB bridge nodes and retrieves the client (tbachman, 20:21:08)
    35. 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 (tbachman, 20:21:57)
    36. edwarnicke says it’s the translation between the model and the row/column table objects (tbachman, 20:22:09)
    37. vishnoianil says taht will be done by the 12th (tbachman, 20:22:20)
    38. shague asks if there’s any UT for this (tbachman, 20:23:10)
    39. edwarnicke says he’ll feel much better as more tests are put in place (tbachman, 20:23:20)
    40. edwarnicke asks about the docker-based testing (tbachman, 20:24:01)
    41. flaviof says the docker stuff was useful for version testing against different revs of OVS (tbachman, 20:24:45)
    42. edwarnicke asks if there’s a version in the schema (tbachman, 20:24:51)
    43. shague says that’s a field in the tables (tbachman, 20:24:57)
    44. edwarnicke asks for some examples in the ways that schema shifts between versions (tbachman, 20:25:47)
    45. ACTION: flaviof to come up with concrete examples of schema shifts (tbachman, 20:26:05)
    46. shague says the nicira extensions for tunnels are one example; used to be part of the port, now are flow-based (tbachman, 20:26:57)

  3. clustering (tbachman, 20:27:51)
    1. ed asks colin to be nice (flaviof, 20:28:36)
    2. notes Colin is usually nice, if perhaps sardonic ;) (edwarnicke, 20:28:53)
    3. colindixon says that clustering comes down to 3 things that are hard in the current model (flaviof, 20:29:40)
    4. 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 (tbachman, 20:29:43)
    5. shague says with the OVSDB use case, it pulls in the DB, and when this goes to clustering, how does this map in ODL (tbachman, 20:31:38)
    6. colindixon points out that clustering does not address failover — just recovery of state (tbachman, 20:32:21)
    7. For deep discussion on clustering and failover behaviors, please see the webex recording at about 30 minutes in (tbachman, 20:34:51)
    8. vishnoianil says all the connection caching is at the library level (tbachman, 20:36:01)
    9. 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) (tbachman, 20:36:38)
    10. colindixon says that has to be handled somehow out of band (tbachman, 20:37:02)
    11. 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 (tbachman, 20:37:34)
    12. cdub says this is a split brain scenario, and it needs to be fenced in some way (tbachman, 20:37:51)
    13. colindixon says he doesn’t know if OVSDB provides any such mechanism (tbachman, 20:38:22)
    14. vishnoianil says there are two connections involved — OpenFlow plugin and OVSDB (tbachman, 20:38:42)
    15. colindixon says one way to deal with this is to piggy-back on openflow (whoever OpenFlow controller is, have OVSDB follow) (tbachman, 20:39:07)
    16. colindixon asks if OVSDB has any way to deal with this (tbachman, 20:39:31)
    17. shague says you can have multpiple managers (tbachman, 20:39:40)
    18. colindixon asks if you can ask an OVSDB manager who it’s managers are (tbachman, 20:39:51)
    19. shague says there is a table for this (tbachman, 20:39:57)
    20. colindixon says that this can be used — where the manager writes themselves into the table (tbachman, 20:40:11)
    21. shague says you can also be a listener (tbachman, 20:40:19)
    22. colindixon asks if this state is kept in the table (tbachman, 20:40:25)
    23. shague says he doesn’t believe so (tbachman, 20:40:35)
    24. 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 (tbachman, 20:41:05)
    25. you can have all the nodes in the cluster connected, but only one node desginating themselves as the master somehow (tbachman, 20:41:43)
    26. edwarnicke asks about the use of external_ids in the OVSDB tables (tbachman, 20:43:30)
    27. edwarnicke asks if we can write an external_id for whatever we consider to be the master (tbachman, 20:43:42)
    28. shague says external_ids are used so the node can identify itself to the management piece (tbachman, 20:44:16)
    29. cdub says the other_config can be used (tbachman, 20:44:22)
    30. edwarnicke says it feels like doing this allows us to determine the rightful owner, so that stonith can be performed (tbachman, 20:45:06)
    31. edwarnicke says one way to discover the master is gone by listening to updates on the managers table (tbachman, 20:46:06)
    32. colindixon says that only works if every cluster instance is connected to every node — otherwise when the master goes down, you stop getting updates (tbachman, 20:46:30)
    33. the advantage of the complete connectivity model is that failures in the cluster, it’s all internal (tbachman, 20:47:59)
    34. colindixon says that load balancers are sometimes deployed between teh devices connecting to the controller and the controller (tbachman, 20:51:30)
    35. edwarnicke says load balancers would have to understand all the way down to the guts of the OVSDB protocol (tbachman, 20:51:47)
    36. colindixon says first thing first: worry about internal cluster state; address failover second (tbachman, 20:52:16)
    37. shague says the main request was to get the clustering support in; sounds like this addresses the needs of the users (tbachman, 20:52:40)
    38. edwarnicke agrees, but wants to make sure that controller node local and internal state is the only data cached (e.g. in hash-maps) (tbachman, 20:53:03)
    39. shague says the schema is down in the lib; if the node goes away, the schema goes away (tbachman, 20:53:37)
    40. shague says in order to drive OVSDB, you need that schema; on a reconnect, you get the schema back (tbachman, 20:54:01)
    41. colindixon says do not store any state in the cluster that you can easily rebuild (tbachman, 20:54:39)
    42. colindixon says it’s a lot easier to handle the lazy loading of caches (tbachman, 20:55:06)
    43. flaviof says there are a bunch of gerrits that edwarnicke needs merging — asks if shague or vishnoianil can look at these (tbachman, 20:57:35)
    44. ACTION: shague and vishnoianil to look at edwarnicke’s gerrits (tbachman, 20:57:45)
    45. colindixon says his suggestion is to use the gerrit comments where possible, moving to live discussion if needed (tbachman, 20:58:33)


Meeting ended at 21:04:11 UTC (full logs).

Action items

  1. flaviof to come up with concrete examples of schema shifts
  2. shague and vishnoianil to look at edwarnicke’s gerrits


Action items, by person

  1. edwarnicke
    1. shague and vishnoianil to look at edwarnicke’s gerrits
  2. flaviof
    1. flaviof to come up with concrete examples of schema shifts
  3. shague
    1. shague and vishnoianil to look at edwarnicke’s gerrits


People present (lines said)

  1. tbachman (128)
  2. cdub (11)
  3. flaviof (7)
  4. odl_meetbot (6)
  5. dneary (2)
  6. edwarnicke (2)
  7. odp-gerritbot (1)
  8. colindixon (1)
  9. shague (0)


Generated by MeetBot 0.1.4.