#opendaylight-meeting: simplifyingodl

Meeting summary

1. 1. https://zoom.us/j/664690256 (dfarrell07, 16:05:09)
   2. https://docs.google.com/document/d/1-MaazB2rGQt_Ci9tMH8G6GNYfcFsJ9bMmCSsLHRwsqU (dfarrell07, 16:09:33)
   3. going through existing doc, linked above (dfarrell07, 16:11:56)
   4. jiraj has done his homework, has some extra slides/ideas to talk through (dfarrell07, 16:12:16)
   5. https://www.youtube.com/watch?v=nr5nFfWIqhQ (tbachman, 16:12:54)
   6. jiraj talks through example of how Java EE reasoned themselves through similar challenges (dfarrell07, 16:14:34)
   7. one step to start would be to identify key services, start thinking of as microservices (dfarrell07, 16:15:57)
   8. there are about 33 services jiraj id'd as being critical to their Lightly usage (dfarrell07, 16:16:14)
   9. nice slide showing services in netvirt and how they might be grouped into microservices (dfarrell07, 16:17:15)
   10. would be not so hard with stateless services, but some extra considerations for stateful services (dfarrell07, 16:18:35)
   11. analysis of netvirt shows that it's not reasonable to break down to one bundle per microservice (dfarrell07, 16:20:50)
   12. tomp talks about cross-ties between services that also require some grouping (dfarrell07, 16:21:43)
   13. also need lots of consideration about what the logical chunk of work a microserv would handle - what are responsibilities, what does provide (dfarrell07, 16:23:27)
   14. also need to consider what wires will consist of between microservs (dfarrell07, 16:24:07)
   15. options for wires are things like rest, grpc, rabbitmq, kafka, etc (dfarrell07, 16:24:35)
   16. ODL <3's tbachman ;* (dfarrell07, 16:25:25)
   17. discussion about when things are broken apart, will need to consider if will use existing APIs or build new ones (dfarrell07, 16:27:21)
   18. perhaps obviously, need to make sure chunks of microservs are logical chunks that make sense to folks (dfarrell07, 16:29:58)
   19. discussion about memory spaces, how data store would work if not shared (dfarrell07, 16:32:23)
   20. juraj says would likely need to include mdsal in all microservs to start with (dfarrell07, 16:33:03)
   21. tomp says the data store APIs would need some sort of implementation locally, even if fake, but need something to make the APIs work (dfarrell07, 16:34:01)
   22. LuisGomez reminds us that jsonrcp project might be useful for this distributed data question (dfarrell07, 16:36:12)
   23. vorburger points out that it would of course be nice just not to have shared state, LuisGomez agrees (dfarrell07, 16:37:34)
   24. could have one microserv that has config data store that many microservs could access, and not bother with operational data in each microserv, there but not HAish (dfarrell07, 16:41:02)
   25. tomp points out that some of these microservs will be HA (dfarrell07, 16:41:29)
   26. some microservs could just be recreated if die, but others might need active HAish (dfarrell07, 16:42:23)
   27. using an etcd back mdsal would of course also be an option, in particular in k8s, see vorburgers work here (dfarrell07, 16:44:16)
   28. vorburger's current poc is looking like should be able to make hidden to services on top (dfarrell07, 16:44:57)
   29. lumina has learned some hard lessons about using ha data store vs external data store; also that it's painful to support both; also that it would be great if we could all work on some same solution upstream (dfarrell07, 16:47:08)
   30. lots of discussion about not needing to replicate/protect nearly as much data as we do today, operational data generated by microservs for internal use for example (dfarrell07, 16:50:23)
   31. but also need to consider how a microserv would get operational data if a pervious version of it died - how would it get back to having the same opp data; hot stand-by is one option; replaying data is one we do in some contexts today (dfarrell07, 16:52:14)
   32. tomp likes eventual consistency with cold standbys, if can make application work that way (dfarrell07, 16:53:48)
   33. other apps may have different HA needs (dfarrell07, 16:56:15)
   34. need to choose one application to use as first, poc; would very likely choose netvirt because lots of activity, interest (dfarrell07, 16:56:38)
   35. but eventually solution needs to apply to all of ODL, all companies/usages if at all possible (dfarrell07, 16:56:57)
   36. Quan (XiongQuan, 17:00:01)

Action items

1. (none)

People present (lines said)

1. dfarrell07 (46)
2. tbachman (14)
3. odl_meetbot (5)
4. abhijitk (4)
5. vpickard (2)
6. XiongQuan (1)
7. jamoluhrsen (1)
8. vthapar (0)
9. skitt (0)
10. vorburger (0)
11. faseelak (0)
12. premsankar (0)
13. anipbu (0)
14. rovarga_ (0)