Addshore added a comment.
TLDR this ticket is about code review of these things, not about deploying this thing to production right now. ------ > I just wanted to say while I love to get this into production, I highly object to get the code in production while trying to read the cloud service in the backend (i.e. deploying the code without deploying the service to production). We tried to do this for ores several years ago and it turned out that it is not a good idea. So this is primarily for an A/B test, and after the A/B test is complete we can make the decision around 1) full production deployment including the service in production or 2) keep using the existing thing. There is little point in multiple teams investing work on getting something deployed into product, that in theroy after a month of so we then just need to undeploy and unwire etc. > The reason production doesn't speak to the outside is security, we are exposing a big vector attack. That service can be taken over somewhat easier. We can control and "lock down" the service in cloud VPS as much as we and other see fit. No remotely private data is sent to the service by the application. Any data read from the application can also be sanitized / checked for validity, and again this would be a very small attack vector if any (this is something that should come up in CR of the patches linked by this ticket. > The defense in depth principle being applied in production implies anything we depend on must have a security review. This effectively bypasses that principle. This area can indeed have a security review of some sorts etc. As mentioned in the story time call, there is an ongoing discussion with WMF around if and how we can do this. This ticket only relates to the code that would make something like this possible, not about the deploying to production bit, which would come after. Even if we don't end up deploying this to production and talking to labs, this code is still needed in the extension. > Production and Cloud have way different SLOs. The service can go down for any reason for hours or more, degrading a production functionality or worse causing exceptions and possibly an outage in production. This is also something that should come up in code review of the patches. We should be ready for the service to not be there, and to gracefully fallback to the other solution, or whatever product @Lydia_Pintscher is happy with in said situation. TASK DETAIL https://phabricator.wikimedia.org/T284820 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Addshore Cc: Martaannaj, Ladsgroup, Esc3300, Aklapper, Lydia_Pintscher, Addshore, Invadibot, maantietaja, Akuckartz, Iflorez, alaa_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Wikidata-bugs, aude, Sjoerddebruin, Mbch331
_______________________________________________ Wikidata-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected]
