akosiaris added a comment.
In T212189#5017053 <https://phabricator.wikimedia.org/T212189#5017053>, @Tarrow wrote: > In T212189#5011311 <https://phabricator.wikimedia.org/T212189#5011311>, @akosiaris wrote: > > > I have to say I am wondering a bit about the latency as the low end seems to be quite high (500ms?). It's your service of course and I am fine with it. > > > There is a chance we might want to revise this down in the future but right now it seems that being this high would not be unreasonable for us. It's difficult to gauge what is realistic right now. Sure. As I said, fine by me. > > >>> - ASAP as feasible, preferably 2019-03-31 at the latest. >> >> Unfortunately that is not feasible. This is the last month of the quarter and there's goals already running, plus we are short handed. But I guess we can target early next quarter. > > What more work/steps are needed? Is it: > > - Helm Chart > - Security Review There is also the LVS and DNS work, but that's in SRE realm. It does take time, but I don't think there anything you can do to expedite that. > Is there a "similar to production" test environment we could use check that everything is correctly setup on our end? There is a staging environment that might fit part of the "similar to production" definition. Things that are deployed in kubernetes are required to go through that environment anyway, so it's part of the process. > If the main work load on your end would be post deploy troubleshooting/monitoring etc.. could we consider a sooner deploy of the service without any expectations of service level (and not send any wikidata.org traffic there)? Just to increase our confidence that we haven't overlooked something. Unfortunately the main work load is pre-deploy. There is of course work post deploy, but I did not take that into consideration when I answered. In T212189#5017076 <https://phabricator.wikimedia.org/T212189#5017076>, @WMDE-leszek wrote: > In T212189#5011311 <https://phabricator.wikimedia.org/T212189#5011311>, @akosiaris wrote: > > > I have to say I am wondering a bit about the latency as the low end seems to be quite high (500ms?). It's your service of course and I am fine with it. > > > This indeed a relatively high number. We have come up with this estimate taking into account that our service is depending on others (MW API for time being) to fullfil its job, so we have taken this uncertainty into account, hence higher figure. We of course don't mind if the service works faster. > And FWIW, we understand "request latency" here as the time from client making a request and getting the response from the service, not a time between client making a request and the service becoming aware of it (just to be clear). Thanks for the clarification. Just noting that, assuming correct service-runner integration, we will anyway have metrics for the former, the latter would have been more difficult. > > >> As far as "wikipedia" availability goes, that's a very difficult number to come up with (it's being asked of in the past) as there are many components that constitute "wikipedia". Anyway 99.9% looks fine to me at this point, and this is not anyway set in stone, we can reevaluate in a few quarters if it ends up being unfeasible. > > Understood, thanks! > >> >> >>> - ASAP as feasible, preferably 2019-03-31 at the latest. >> >> Unfortunately that is not feasible. This is the last month of the quarter and there's goals already running, plus we are short handed. But I guess we can target early next quarter. > > This is understandable. We have had to try, though :) We're looking forward for this hopefully happening next quarter. Thanks for the understanding. We are drafting next quarter goals this week, I 'll make sure to add this. Final question and just for verification, this ain't going to be exposed directly to the internet after all, right? Rather this will be called by mediawiki, per the architectural diagrams attached to this task. TASK DETAIL https://phabricator.wikimedia.org/T212189 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: akosiaris Cc: sbassett, thcipriani, Tarrow, Smalyshev, jijiki, fsero, CDanis, akosiaris, Krinkle, Milimetric, daniel, mobrovac, Joe, Matthias_Geisler_WMDE, Jakob_WMDE, Pablo-WMDE, Aklapper, Lydia_Pintscher, Lea_WMDE, Addshore, WMDE-leszek, alaa_wmde, holger.knust, Legado_Shulgin, Nandana, thifranc, AndyTan, Davinaclare77, Qtn1293, Lahi, Gq86, GoranSMilovanovic, Th3d3v1ls, Hfbn0, QZanden, LawExplorer, Zppix, _jensen, rosalieper, Wong128hk, Eevans, Hardikj, Wikidata-bugs, aude, faidon, Jdforrester-WMF, Mbch331, Jay8g, fgiunchedi
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
