akosiaris added a comment.
Patches have been deployed, simple curl tests as well as
`service-checker-swagger` checks have passed. I double checked the diff, envoy
is listening now on both IPv6 and IPv4.
I think you are unblocked on this and can proceed with the migration.
TASK DETAIL
akosiaris added a comment.
In T355685#9491036 <https://phabricator.wikimedia.org/T355685#9491036>,
@akosiaris wrote:
> In T355685#9491033 <https://phabricator.wikimedia.org/T355685#9491033>,
@Lucas_Werkmeister_WMDE wrote:
>
>> In T355685#9490969 <https:
akosiaris added a comment.
In T355685#9491033 <https://phabricator.wikimedia.org/T355685#9491033>,
@Lucas_Werkmeister_WMDE wrote:
> In T355685#9490969 <https://phabricator.wikimedia.org/T355685#9490969>,
@akosiaris wrote:
>
>> Definitely different task. I
akosiaris added a comment.
In T355685#9490871 <https://phabricator.wikimedia.org/T355685#9490871>,
@Lucas_Werkmeister_WMDE wrote:
> Thanks a lot – I’ve added some of that information at
https://wikitech.wikimedia.org/wiki/WMDE/Wikidata/SSR_Service#Deployment where
it will
akosiaris added a comment.
In T355685#9490230 <https://phabricator.wikimedia.org/T355685#9490230>,
@Lucas_Werkmeister_WMDE wrote:
> In T355685#9490204 <https://phabricator.wikimedia.org/T355685#9490204>,
@akosiaris wrote:
>
>>> Would it be possible to
akosiaris added a comment.
In T355685#9484621 <https://phabricator.wikimedia.org/T355685#9484621>,
@Lucas_Werkmeister_WMDE wrote:
> In T355685#9484091 <https://phabricator.wikimedia.org/T355685#9484091>,
@akosiaris wrote:
>
>> My high level suggestion
akosiaris added a comment.
The deeper reason behind most of this mess is the probably the uniqueness of
the `test` release. There is no other environment where we have a `test`
release currently and thus some of the assumptions made elsewhere to provide
functionality don't apply
akosiaris added a comment.
Fixed the alert too. Took me a bit to figure out how to find it, thanks for
posting the link in the task.
TASK DETAIL
https://phabricator.wikimedia.org/T341054
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: akosiaris
akosiaris added a comment.
I think I have fixed the graphs now to be correct. They will definitely be
more correct than previously where they were doing statistically wrong things
(aggregating aggregates)
TASK DETAIL
https://phabricator.wikimedia.org/T341054
EMAIL PREFERENCES
https
akosiaris added a comment.
Sorry about that. For what is worth, we are approaching this piecemeal and
this is the first instance. There are more changeprop related metrics that are
wrongly summaries and not histograms, we will ping you before changing the next
few ones.
TASK DETAIL
https
akosiaris added a comment.
In T301471#8806115 <https://phabricator.wikimedia.org/T301471#8806115>,
@Michaelcochez wrote:
> The testing code is now implemented, and we found two small issues with it.
These have now been resolved and the code is simplified further.
&
akosiaris added a comment.
Any updates on this one? Per previous comment we were waiting on a merge, has
this been done?
TASK DETAIL
https://phabricator.wikimedia.org/T301471
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: akosiaris
Cc
akosiaris added a comment.
curl also implements HSTS. See https://curl.se/docs/hsts.html, but it is
indeed primarily a mechanism to protect users of browsers.
@Ennomeijers you are right about this being a fundamental question. I think
nobody expected HTTP to become disfavored anytime
akosiaris added a comment.
In T301471#7964353 <https://phabricator.wikimedia.org/T301471#7964353>,
@Michaelcochez wrote:
> Regarding the option of using a batch of queries to an external database;
the issue is that what we are creating is a specialized index specifically for
akosiaris added a comment.
In T301471#7964314 <https://phabricator.wikimedia.org/T301471#7964314>,
@Michaelcochez wrote:
> An update on the current status, mainly regarding the index file:
>
> First, I made a mistake in my response above. The size of the file is a lo
akosiaris added a comment.
In T301471#7840496 <https://phabricator.wikimedia.org/T301471#7840496>,
@Michaelcochez wrote:
> I merged the pull request on github now.
>
> I do not have rights to push to the gerrit repository, it might just be my
limited knowledge of h
akosiaris added a comment.
In T238751#7851690 <https://phabricator.wikimedia.org/T238751#7851690>,
@Addshore wrote:
> @Joe (Also pinging @akosiaris as I know joe is out right now).
> It seems like the ideal solution of T239392: Applications and scripts need
to be able t
akosiaris added a comment.
In T301471#7837692 <https://phabricator.wikimedia.org/T301471#7837692>,
@Addshore wrote:
> So a summary comment as promised!
>
> In T301471#7799393 <https://phabricator.wikimedia.org/T301471#7799393>,
@Michaelcochez wrote:
>
akosiaris added a comment.
In T280485#7510249 <https://phabricator.wikimedia.org/T280485#7510249>,
@Zbyszko wrote:
> Sorry all for the confusion my typo caused, different name for that
magnitude in my native language is confusing me my whole life :).
No worries, that's
akosiaris added a comment.
In T280485#7510247 <https://phabricator.wikimedia.org/T280485#7510247>,
@dcausse wrote:
> small precision:
> If we reuse the same cluster (same k8s namespace):
>
> - it's 3 more pods at 2.1G ram, cpu: 1000m each
>
> If we use
akosiaris added a comment.
In T280485#7510193 <https://phabricator.wikimedia.org/T280485#7510193>,
@Gehel wrote:
>>> In T280485#7506072 <https://phabricator.wikimedia.org/T280485#7506072>,
@akosiaris wrote:
>>>
>>>> Is T280485#7275149
akosiaris added a comment.
In T280485#7509094 <https://phabricator.wikimedia.org/T280485#7509094>,
@Gehel wrote:
> In T280485#7506072 <https://phabricator.wikimedia.org/T280485#7506072>,
@akosiaris wrote:
>
>> Is T280485#7275149 <https://phabricator.wi
akosiaris added a comment.
Hi. Given the 13 core/15GB RAM requirement, I can verify that we have that
capacity free lying around[1], so we expect no problems there.
Is T280485#7275149 <https://phabricator.wikimedia.org/T280485#7275149>
related to blazegraph and not flink ? I am no
akosiaris moved this task from Inbox to In progress on the
Service-deployment-requests board.
akosiaris triaged this task as "Medium" priority.
TASK DETAIL
https://phabricator.wikimedia.org/T280579
WORKBOARD
https://phabricator.wikimedia.org/project/board/1305/
EMAIL PREFERENC
akosiaris added a comment.
In T278385#6964844 <https://phabricator.wikimedia.org/T278385#6964844>,
@akosiaris wrote:
> In T278385#6962724 <https://phabricator.wikimedia.org/T278385#6962724>,
@Mstyles wrote:
>
>> @akosiaris the swift proxies in there seem a
akosiaris added a comment.
In T278385#6962724 <https://phabricator.wikimedia.org/T278385#6962724>,
@Mstyles wrote:
> @akosiaris the swift proxies in there seem are pointing to the swift
cluster that we use (thano-swift). We'll need additional proxies set up for
that as we
akosiaris added a comment.
In T278385#6957363 <https://phabricator.wikimedia.org/T278385#6957363>,
@Mstyles wrote:
> @akosiaris: I wanted to clarify for Swift as well, will there be proxies to
connect to the swift auth url (https://thanos-swift.discovery.wmnet/
akosiaris added a comment.
Those are the public endpoints and are not on purpose (in order to preserve
the edge caches from accidental pollution as well as debuggability) accessible
from inside the cluster. What you want instead is to send HTTP requests to:
localhost: 6500 (also known
akosiaris closed this task as "Invalid".
akosiaris added a comment.
I am inclined to close this as `Invalid`. Regardless of the amount of time
staging was broken for, staging is not meant to have alerts on purpose. That
being said, feel free to reopen.
TASK DETA
akosiaris added a comment.
In T199219#6855641 <https://phabricator.wikimedia.org/T199219#6855641>,
@Gehel wrote:
> In terms of implementation in our new updater, the comment from @BBlack is
the starting point:
>
> In T199219#4416896 <https://phabricator.wikimedia.o
akosiaris added a comment.
For what is worth, we now have the services proxy (envoy based) with
persistent connections and doing TLS on its own so any costs from switching to
TLS connections to the internal LVS services will be largely mitigated. In
fact, if anything I expect the latencies
akosiaris added a comment.
In T273097#6805355 <https://phabricator.wikimedia.org/T273097#6805355>,
@Mstyles wrote:
> @akosiaris I just learned that there are archive links that have all of the
Flink packages. I'm proposing that we close both this ticket a
akosiaris added a comment.
In T273097#6801429 <https://phabricator.wikimedia.org/T273097#6801429>,
@RKemper wrote:
> @akosiaris Is your concern with the idea of using a`flink` base image
solution mainly just centered around the inefficiency/inconvenience of needing
SRE to
akosiaris added a comment.
Hmm, I see your point. In that case, if there isn't a good place that Search
controls to upload the version of flink that they want, the most prudent way
out is the debian package described in T266495
<https://phabricator.wikimedia.org/T266495>
TASK
akosiaris added a comment.
Given the very well put `The downside of having a base image owned by SRE
means that we are reliant on them to merge any Flink version updates.` state in
the task description, I 'd suggest that we don't create a base image but rather
fetch the jars and put them
akosiaris added a comment.
After the helm chart is merged and published (both should happen
automatically on a +2, I 've +1ed already), the final 2 items for deployment
are:
[ ] Create k8s tokens, namespaces. That's for SRE ServiceOps, example
akosiaris added a comment.
In T265512#6648623 <https://phabricator.wikimedia.org/T265512#6648623>,
@Gehel wrote:
>
> My (limited) understanding of the usual pipelines is that we expect a
1-to-1 mapping between project source code, packaged artifact an
akosiaris added subscribers: jeena, dduvall.
akosiaris added a comment.
In T265512#6637980 <https://phabricator.wikimedia.org/T265512#6637980>,
@Mstyles wrote:
> @akosiaris it was unclear to me whether we need the promote section in the
pipeline config. I'm referring to thi
akosiaris added a comment.
In T265504#6615197 <https://phabricator.wikimedia.org/T265504#6615197>,
@Mstyles wrote:
> @akosiaris I started using the new Java images that you uploaded. I wasn't
able to install gpg in the build process. There are some conflicts. We can
akosiaris added a comment.
In T265504#6598430 <https://phabricator.wikimedia.org/T265504#6598430>,
@Mstyles wrote:
> @akosiaris when you get some time, can you please take another look at
https://gerrit.wikimedia.org/r/c/wikidata/query/rdf/+/635074
Yes, I will. This hasn
akosiaris closed this task as "Invalid".
akosiaris added a comment.
In T264710#6586070 <https://phabricator.wikimedia.org/T264710#6586070>,
@Addshore wrote:
> Sounds like a fine solution from our side for now.
> I'll let #serviceops <https://phabricator.wik
akosiaris added a comment.
In T265504#6580948 <https://phabricator.wikimedia.org/T265504#6580948>,
@Zbyszko wrote:
>> Could you elaborate on that a bit?
>
> Sure, here goes: We are using Apache Flink[1] as a platform for our event
processing we do to feed Wiki
akosiaris added a comment.
In T265504#6580645 <https://phabricator.wikimedia.org/T265504#6580645>,
@Zbyszko wrote:
> @akosiaris I see, makes sense. I still would like to solve the issue with
replicating the original dockerfile - can we deploy Flink images to our
registry - eve
akosiaris added a comment.
In T265504#6578280 <https://phabricator.wikimedia.org/T265504#6578280>,
@Zbyszko wrote:
> @akosiaris Can we base a blubber enabled project on a 3rd party docker
image, provided on docker hub? I was wondering if we have to replicate
original docker
akosiaris added a comment.
For what is worth, the idea that Daniel explains above, would solve the issue
for now without the need to move to kubernetes, satisfying multiple of the
requirements without requiring significant effort.
The following from the task description are satisfied
akosiaris added a comment.
In T255410#6550492 <https://phabricator.wikimedia.org/T255410#6550492>,
@Michael wrote:
>
> That seems very strange. I would have expected the //error rate// to be
calculated by `(number of errors / number of total requests)` f
akosiaris added a comment.
In T255410#6543118 <https://phabricator.wikimedia.org/T255410#6543118>,
@Michael wrote:
> @akosiaris Thank you a lot for your detailed response. I did look into
those errors a tiny bit more to properly document them as can be now seen on
wikitec
akosiaris added a comment.
A couple of requirements from my side, regardless of where those sites are
deployed and the technology used:
- Support for structured logging to stdout to allow debugging issues via our
ELK stack should be a requirement.
- Support for exporting metrics via
akosiaris edited projects, added serviceops-radar; removed serviceops.
akosiaris added a comment.
Envoy is being documented at
https://wikitech.wikimedia.org/wiki/Envoy#Envoy_at_WMF. It is being used by
termbox to talk to mediawiki (it's a component of a service mesh). The idea is
to have
akosiaris added a project: serviceops-radar.
akosiaris added a comment.
Sorry for not answering earlier.
In T255410#6494077 <https://phabricator.wikimedia.org/T255410#6494077>,
@Pablo-WMDE wrote:
>
> I unfortunately don't know how to do this for sing
akosiaris added a comment.
In T255410#6491711 <https://phabricator.wikimedia.org/T255410#6491711>,
@Pablo-WMDE wrote:
> We are seeing our termbox service, when reaching out to the mediawiki API,
occasionally receiving a 503 (e.g.
<https://logstash.wikimedia.org/app/kibana#/
akosiaris added a comment.
In T255410#6224239 <https://phabricator.wikimedia.org/T255410#6224239>,
@Michael wrote:
>
> Termbox/k8s:
https://logstash.wikimedia.org/app/kibana#/doc/logstash-*/logstash-syslog-2020.06.15/syslog?id=AXK3_osLZmYAikdJbyT-&_g=h@e3739
akosiaris updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T249598
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: akosiaris
Cc: Aklapper, Krinkle, kchapman, Pablo-WMDE, Ladsgroup, alaa_wmde, Anomie,
Addshore, WMDE-leszek
akosiaris triaged this task as "Medium" priority.
TASK DETAIL
https://phabricator.wikimedia.org/T247058
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: akosiaris
Cc: Aklapper, dcausse, Zbyszko, Gehel, darthmon_wmde, Legado_Shulgi
akosiaris added a comment.
> It's unmaintained as you pointed out (see T211881
<https://phabricator.wikimedia.org/T211881> for the gory details). Even if we
fixed the blubber file (I am guessing that's where the issue is), deploying
anything merged would probably not hap
akosiaris closed this task as "Resolved".
akosiaris claimed this task.
akosiaris added a comment.
The service has for long been deployed and even has nice dashboards in
grafana, resolving.
TASK DETAIL
https://phabricator.wikimedia.org/T212189
EMAIL PREFERENC
akosiaris added a comment.
In T199219#5396104 <https://phabricator.wikimedia.org/T199219#5396104>,
@Ladsgroup wrote:
> The other thing I want to mention and was missing here is overhead of
encryption and TLS handshakes. In the @BBlack's example, we still use TLS but
if you
akosiaris added a comment.
In T229236#5376652 <https://phabricator.wikimedia.org/T229236#5376652>,
@Ladsgroup wrote:
> @Lydia_Pintscher @alaa_wmde So the current user agent of graphoid service
is `graphoid (yurik at wikimedia)`. Yurik has left Wikimedia for a couple years
I
akosiaris added a comment.
In T176875#5317155 <https://phabricator.wikimedia.org/T176875#5317155>,
@Ottomata wrote:
> @Addshore, just saw T218710 <https://phabricator.wikimedia.org/T218710> and
clicked through to here. If you use
https://wikitech.wikimedia.org/wiki/HTTP
akosiaris added a comment.
In T212189#5289724 <https://phabricator.wikimedia.org/T212189#5289724>,
@Tarrow wrote:
> @akosiaris Yep; we've interpreted it as something we really need before
exposing it to real traffic. We've got a ticket open about it that we'll be
picking up
akosiaris added a comment.
@WMDE-leszek, @Tarrow.
Any feedback on the comment above?
TASK DETAIL
https://phabricator.wikimedia.org/T212189
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: akosiaris
Cc: Mholloway, RazShuty, sbassett
akosiaris added a comment.
@WMDE-leszek, @Tarrow.
I 've noticed we are missing one thing. We have a dashboard for the service's
metrics in https://grafana.wikimedia.org/d/AJf0z_7Wz/termbox but it looks like
the service isn't sending request metrics to the local statsd instance
akosiaris closed this task as "Resolved".
akosiaris claimed this task.
akosiaris added a comment.
curl -s -I -X GET
'http://termbox.discovery.wmnet:3030/termbox?editLink=%2Fedit%2FQ1347=de=de=Q1=103'
HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: text/html; cha
akosiaris added a comment.
Just as an FYI, everything looks ok on this end, but there's a train freeze
this week, so we have to wait before deploying this. Patches are up and waiting
to be merged on Monday the 17th
TASK DETAIL
https://phabricator.wikimedia.org/T220402
EMAIL PREFERENCES
akosiaris added a comment.
In T220402#5243209 <https://phabricator.wikimedia.org/T220402#5243209>,
@Tarrow wrote:
> This should now be fixed. Sadly this was due to a mismatch between the code
in wikibase master and that deployed on Wikidata.org
And yes, we are finally i
akosiaris added a comment.
In T199219#5234979 <https://phabricator.wikimedia.org/T199219#5234979>,
@Smalyshev wrote:
> But won't we lose use of the varnish cache if we use the internal endpoint?
Yes that's true. That being said, is that particularly important? Will W
akosiaris added a comment.
Indeed this was fixed. However another regression has crept up it's head
Doing a `curl
'http://192.168.99.100:18788/termbox?editLink=%2Fedit%2FQ1347=de=de=Q1=103'`
returns a 500 with an error in the logs
{
"name": "termbox&qu
akosiaris added a comment.
@tarrow, @WMDE-leszek
Hi, sorry for taking so long to answer to this, it's been really busy.
In T220402#5214471 <https://phabricator.wikimedia.org/T220402#5214471>,
@Tarrow wrote:
> @mobrovac Thanks! I think we've now taken most of thi
akosiaris added a comment.
In T199219#5234041 <https://phabricator.wikimedia.org/T199219#5234041>,
@Smalyshev wrote:
> There's a change though that WDQS no longer uses `nocache` for
cache-busting in most common cases (see T217897
<https://phabricator.wikimedia.org/T2178
akosiaris added a comment.
In T199219#4452041 <https://phabricator.wikimedia.org/T199219#4452041>,
@Smalyshev wrote:
> @BBlack I am getting rather strange result with
`appservers-ro.discovery.wmnet` - if I call the URL you provided, the call
takes a lot of time:
&
akosiaris added a comment.
In T220402#5180031 <https://phabricator.wikimedia.org/T220402#5180031>,
@Pablo-WMDE wrote:
> Hi @akosiaris,
>
> thanks for taking the time to explain the way the `Host` header is intended
to be used.
> If I understand correctly the
akosiaris added a comment.
In T220402#5177862 <https://phabricator.wikimedia.org/T220402#5177862>,
@Pablo-WMDE wrote:
> Hi @akosiaris - thanks for getting back to us.
>
> > sending a Host: HTTP for the identification of the exact project. Would
it
akosiaris added a comment.
> With respect to the end point checks it would be great to hear what we are
trying to achieve with them. Our service depends on the availability of another
service. If the examples are to act as smoke tests then their reliability
depends on the upstream serv
akosiaris added a comment.
@Tarrow , @WMDE-leszek I 've noticed 3 things while working on the above
- The service seems to be configurable to reach directly out to the wikidata
endpoint. e.g. `WIKIBASE_REPO:
'{env(WIKIBASE_REPO,https://www.wikidata.org/w)}'`. Since, in the general case
akosiaris added a comment.
@WMDE-leszek. Yes I did.
Using https://locust.io/, wrote P8511
<https://phabricator.wikimedia.org/P8511> and benchmarked the service locally
on my minikube instance. A rough howto (minus the locust part) is at
https://wikitech.wikimedia.or
akosiaris added a comment.
@Tarrow, @WMDE-leszek. I 've been working on the termbox helm chart and while
the service seems to be up and running, I see no `/_info` endpoint nor a
swagger/openapi[1] spec published under `/?spec`. Both are crucial for
deploying, as the former is used
akosiaris closed this task as "Resolved".
akosiaris claimed this task.
akosiaris added a comment.
dummy private repo updated, so is the actual private repo. Resolving, thanks!
TASK DETAIL
https://phabricator.wikimedia.org/T217641
EMAIL PREFERENCES
https://phabricator.wik
akosiaris updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T217641
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: akosiaris
Cc: akosiaris, Lucas_Werkmeister_WMDE, Ladsgroup, Aklapper, Addshore,
alaa_wmde, joker88john
akosiaris added a comment.
@WMDE-leszek Hi, sorry for not answering any sooner, last few weeks have been
crazy indeed.
Q4/Q2 started We can start work on this finally. The tracking task for this
is in T220402 <https://phabricator.wikimedia.org/T220402>. Barring various
akosiaris added a comment.
In T212189#5044451 <https://phabricator.wikimedia.org/T212189#5044451>,
@Addshore wrote:
> In T212189#5020187 <https://phabricator.wikimedia.org/T212189#5020187>,
@akosiaris wrote:
>
> > Thanks for the understanding. We are dra
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 th
akosiaris added a comment.
That for this, it's appreciated. Note that we haven't still decided over
which time window the availability will be calculated, but it's probably gonna
be quarertly (3months that is).
I have to say I am wondering a bit about the latency as the low end seems
akosiaris added subscribers: jijiki, ArielGlenn, Krinkle, hashar, fgiunchedi,
Joe, akosiaris.
akosiaris added a comment.
I was looking at Special needs or unsorted. @ayounsi I 've updated a few,
feel free to move them to other sections. Pinging:
- ge-2/0/13 - tungsten - xhgui:app
akosiaris updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T187960
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Cmjohnson, akosiaris
Cc: Addshore, MMiller_WMF, Catrope, elukey, Marostegui, Stashbot, Paladox,
gerritbot
akosiaris updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T187960
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Cmjohnson, akosiaris
Cc: Addshore, MMiller_WMF, Catrope, elukey, Marostegui, Stashbot, Paladox,
gerritbot
akosiaris added a comment.
In T212189#4998182 <https://phabricator.wikimedia.org/T212189#4998182>,
@Tarrow wrote:
> I am indeed already working on it.
>
> Just so you know the current state: we are already using blubber for the CI
i.e. we have 'service-pipeline-te
akosiaris added subscribers: Tarrow, thcipriani.
akosiaris added a comment.
Per some IRC discussions we had in #wikimedia-serviceops, the code should be
updated to be service-runner compatible as this will greatly increase
homogeneity and allow for easy handling of things like logging
akosiaris added a comment.
In T212189#4833536, @daniel wrote:
"We should not introduce a service that is called by MediaWiki, and itself calls MediaWiki."
Slightly OT, but a +1000 YES to this. Been there, seen that antipattern, it's a mess to reason about. The coupling of the 2 compo
akosiaris reopened this task as "Open".akosiaris added a comment.
Oops, closed this by mistake. Re-opened, feel free to close when the issue is indeed resolved.TASK DETAILhttps://phabricator.wikimedia.org/T210260EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailp
akosiaris closed this task as "Resolved".akosiaris claimed this task.akosiaris added a comment.
In T210260#4820556, @hashar wrote:
Following the merge of https://gerrit.wikimedia.org/r/478200 , can you possibly rebuild the two images please? :)
RepositoryTagImage idCreatedS
akosiaris added a comment.
I did just do a quick check on wikimedia-stretch image for this
$ docker run --rm -it docker-registry.wikimedia.org/wikimedia-stretch:latest
root@92dc0302edca:/# ls
bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var
root
akosiaris added a comment.
In T210260#4784708, @LarsWirzenius wrote:
C.UTF8 does not exist. In every other locale I try, a UTF8 suffix is an alias to the UTF-8 suffix (with the dash).
This works: docker run unitest env LC_ALL=C.UTF-8 python3 -c "print('étoile')"
I'd suggest t
akosiaris added a comment.
https://grafana.wikimedia.org/dashboard/db/t204083?orgId=1 shows the excessive traffic moving around the various memcached hosts for the last 1 year.TASK DETAILhttps://phabricator.wikimedia.org/T204083EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel
akosiaris triaged this task as "High" priority.akosiaris added a project: Performance-Team.
TASK DETAILhttps://phabricator.wikimedia.org/T204083EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: akosiarisCc: Aklapper, mark, Krinkle, Joe, akosiari
akosiaris created this task.akosiaris added projects: Wikidata, wikiba.se, Operations.Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTIONSRE team noticed that a specific host (mc1023) is close to saturating the uplink network connection [1]. More investigation into the grafana
akosiaris added a comment.
In T163922#3639831, @Lucas_Werkmeister_WMDE wrote:
If the TTL isn’t too long (I saw a cap of 1 day in the puppet config, is that correct?), then normal expiry is probably enough.
It doesn't work like that. The time that request can be cached is determined
akosiaris added a comment.
There are other comments from yours truly in the last review, namely maintaining the status quo of configuring the redirect, aside from the 303 vs 301 part, on which I can be convinced with a good enough argument, but I haven't yet seen a reply.TASK DETAILhttps
akosiaris closed subtask T146474: Add firewall exception to get to wdqs*.codfw.wmnet: from analytics cluster as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T146207EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Addshore, akosiarisCc
akosiaris closed this task as "Resolved".akosiaris claimed this task.akosiaris added a comment.
This seems to have fallen between the cracks. I 've had a quick look and talk with @Gehel and opened the access. Resolving, feel free to reopen.TASK DETAILhttps://phabricator.wikimedia.org/T1
akosiaris added a comment.
I support that as well. The code in wdqs::updater should probably anyway be amended to use base::service_unit at some point, at which point the question of whether puppet should also manage a service resource will probably be posed. We would at least be ready from
1 - 100 of 105 matches
Mail list logo
