#wikimedia-office: EventBus RFC

Meeting started by ori at 18:17:46 UTC (full logs).

Meeting summary

  1. EventBus | RFC meeting | Wikimedia meetings channel | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ (Meeting topic: RFC meeting) (ori, 18:18:07)
    1. https://phabricator.wikimedia.org/T88459 (ori, 18:19:49)
    2. (ottomata, 18:20:14)
    3. goals for meeting: 1) finalize some implementaiton decisions, 2) get buy in from ops and others (gwicke, 18:22:03)
    4. : ori> - The success criterion for this system (and this project) is its ability to unify the set of partial and divergent implementations that currently exist. (robla, 18:36:15)
    5. AGREED: The success criterion for this system (and this project) is its ability to unify the set of partial and divergent implementations that currently exist. The work of refactoring / consolidating specific existing implementations should not fall exclusively on any one team; it is a joint responsibility. But: the implementers of this project should assume leadership / ownership of the overall process. (Last clause is actual (ori, 18:39:29)
    6. AGREED: The success criterion for this system (and this project) is its ability to unify the set of partial and divergent implementations that currently exist. The work of refactoring / consolidating specific existing implementations should not fall exclusively on any one team; it is a joint responsibility. But: the implementers of this project should assume leadership / ownership of the overall process. (ori, 18:39:58)
    7. (Last clause re: responsibility is actually somewhat contentious; Ottomata agrees but Gwicke / urandom worried about implications.) (ori, 18:40:07)
    8. <mobrovac> _joe_: yes, i'd like to see the jobqueue replaced before rcs, if you ask me <paravoid> rcstream is a pretty minor usecase overall <ottomata> jobqueue gwicke is intersted in already, I think. (ori, 18:41:48)
    9. <Krinkle> I'd like to avoid a single person both designing and porting systems. It woudl benefit the design and confirm intuitive use if someone else can implement it at least once before we sort of rubberstamp it (ori, 18:42:58)
    10. services' primary goal for this quarter is change propagation, and things needed in the eventbus for that use case will take precedence over porting other use cases (gwicke, 18:43:03)
    11. joe> I have a question about the implementation idea: it is not clear if this REST proxy you want to build in front of Kafka will be used only to produce messages to it or also to consume those. Also, in both scenarios, what this proxy would add as a benefit opposed to creating solid libraries that have a direct interface to kafka? (ottomata, 18:47:55)
    12. http://docs.confluent.io/1.0.1/kafka-rest/docs/intro.html (ottomata, 18:52:37)
    13. issue 1) Contention over whether events need to be validated on consumption (ottomata, 18:56:35)
    14. issue 2) contention over whether produce validation should be done as an HTTP service or as a client lib (ottomata, 18:57:24)
    15. issue 3) scalability - proxy will lessen it, is it worth it? (ottomata, 18:57:55)
    16. correction to issue 3) s/scalability/reliability of message production/ (ottomata, 18:59:42)
    17. https://en.wikipedia.org/wiki/Robustness_principle (gwicke, 19:03:04)
    18. it's contentious whether that service should be required for *all* use cases (gwicke, 19:09:25)
    19. _joe_: I am strongly against abstracting consumption away from kafka, on reliability concerns and on the architectural principle that proxy-services should only be used to add flexibility to a system (_joe_, 19:14:54)
    20. https://phabricator.wikimedia.org/T114443#1736288 (ottomata, 19:19:47)


Meeting ended at 19:25:13 UTC (full logs).

Action items

  1. (none)


People present (lines said)

  1. ottomata (174)
  2. paravoid (93)
  3. ori (85)
  4. gwicke (76)
  5. _joe_ (62)
  6. nuria (44)
  7. Krinkle (28)
  8. mobrovac (26)
  9. urandom (24)
  10. akosiaris (11)
  11. mark (7)
  12. robla (6)
  13. wm-labs-meetbot (4)
  14. chasemp (2)
  15. mutante (1)


Generated by MeetBot 0.1.4.