Ottomata added a comment. Hi all, I talked to @gwicke a little bit more about this last Thursday. He impressed upon me a couple of good points I hadn't fully taken in before, and I want to recognize them.
**Simplicity ** - Services is concerned that the REST service needs to be very reliable and not buggy. restevent is simple, and if it never needs to do anything beyond this MVP, it will not need many changes or deploys throughout its lifetime. Conversely, EventLogging is a codebase that is often worked on and improved. Using this established and more featureful codebase provides a lot of benefit, but brings with it risk of instability due to changes. **EventLogging deprecation** - A big concern expressed at the RFC was proliferations of systems and the effort needed to port old systems over to EventBus if we were to use restevent. EventBus is about 2 things: standardizing WMF events, and getting valid events into a pub/sub for many consumers to use. The scope of this MVP does not include consumption of events, and much of the EventLogging codebase is about consuming, not producing. Using restevent does not mean that EventLogging will be deprecated. EventLogging does much more than restevent ever would. There will be other systems that will need to be ported to EventBus, but this is true independent of the EventLogging vs restevent discussion. That said, I still think we should move forward with EventLogging as we have been and as the general consensus in the RFC indicated. I have discussed these points with some folks, and even though they are valid concerns, I don't think that they outweigh the pros of using and improving an established working system. The risk of instability due to active development of EventLogging can be addressed with common release management practices. I.e. we can version well and deploy only stable releases to the HTTP service. And even though we wouldn't need to port EventLogging to use restevent, there is duplication of effort here, as EventLogging is built to do most of what this MVP is about. Also, I'd like to note that building an HTTP produce service that fits this MVP in EventLogging //is// more work than is in restevent. This is mostly due to the schema constraints (I.e. EventCapsule <https://meta.wikimedia.org/wiki/Schema:EventCapsule>) that EventLogging was originally built with. The work we are doing to make EventLogging work with more generic meta data is valuable beyond just this MVP, so I think it is worth it. > To be explicit: I'm not saying we're dismissing the RFC discussions and don't > want to collaborate with others. Our ultimate goal is exactly what you > described - a unified event bus system for the whole organisation - and only > an org-wide consensus will bring us home. But we have to make (small-ish) > compromises in the short term in order to meet our QG. I think this is one of the sources of conflict. I originally proposed a very generic solution to an org wide problem, and Analytics has committed to work on the initial infrastructure MVP that solves the generic problem this quarter. Services wants to use the solution that solves the org wide problem, but has additionally committed to an additional goal that depends on the generic solution. Services wants something that works for them now, and will make it work for others later. Analytics is interested in the more generic problems first. Services goal + the fact that EventLogging is more work is worrysome for Services. I believe that we can get EventLogging ready in time to meet Service's needs, but I'm not excited about promising it. As a back up and with Ops' go-ahead, I think it would be ok to use restevent as a stand in until EventLogging is ready, especially for the month of December so that Services can continue to work on their goals. @gwicke, @mobrovac, @eevans, and @nuria, I propose we set up a twice-a-week-EventBus-standup-sync-up-party-meeting to help us better collaborate and be in sync. How about Monday and Thursdays? TASK DETAIL https://phabricator.wikimedia.org/T114443 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Ottomata Cc: Milimetric, RobLa-WMF, brion, intracer, Smalyshev, mark, MZMcBride, Krinkle, EBernhardson, bd808, Joe, dr0ptp4kt, madhuvishy, Nuria, ori, faidon, aaron, GWicke, mobrovac, Eevans, Ottomata, Matanya, Aklapper, JAllemandou, jkroll, Hardikj, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, daniel, Mbch331, Jay8g, Ltrlg, jeremyb, Legoktm _______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
