Conversation
tarrow
force-pushed
the
T408624
branch
3 times, most recently
from
78fa82e to
530fb26
Compare
|
In addition to this "unit like" test with mocked k8s client responses I also tried to try it out on a kubernetes minikube setup. This time running in GKE - still incredibly painfully slow but at least without locking up my personal machine; didn't actually get as far as really testing it routes correctly. I would do this by creating a couple of Wikis, one with a 139 and 143 DB. I would then manually dispatch app/Jobs/ProcessMediaWikiJobsJob.php and inspect the jobs that are fired off. |
This selects a pod that matches the selector[1] for the appropriate backend service rather than any random backend MediaWiki pod [1] https://kubernetes.io/docs/concepts/services-networking/service/#services-in-kubernetes Bug: T408624
|
|
||
| public function handle(Client $kubernetesClient): void { | ||
| public function handle(Client $kubernetesClient, MediaWikiHostResolver $resolver): void { | ||
| $domain = $resolver->getBackendHostForDomain($this->wikiDomain); |
There was a problem hiding this comment.
while reading I confused this $domain var with a wiki domain, I'd suggest $mwBackendHost or something
There was a problem hiding this comment.
Good idea; I picked a different name. I can see why you were confused for sure. I wanted to make it clear that this isn't a host like an ip but actually a domain for a service. Hopefully this makes sense now.
| $serviceName = $domain; | ||
| $kubernetesClient->setNamespace('default'); | ||
| $backendService = $kubernetesClient->services()->setLabelSelector([ | ||
| 'name' => $serviceName, |
There was a problem hiding this comment.
I'm not sure if it will work like this, as the name of the service seems more like mediawiki-143-app-backend than mediawiki-143-app-backend.default.svc.cluster.local ?
see kubectl get service mediawiki-143-app-backend -o yaml
There was a problem hiding this comment.
yeah, you're totally right. I just took the first bit. Apparently also the LabelSelector was wrong and I should have used the field one with metadata.name. I basically only determined this my trial and error though.
|
You might find you wanted to try this out in your local cluster but it depends a bit on this chart update being there e.g. this being merged (wmde/wbaas-deploy#2325). If you want to try out this new chart locally then you can do this to disable argo self heal and select a newer than used version of the chart: kubectl patch application app-of-apps -n argocd --type='json' -p='[{"op": "replace", "path": "/spec/syncPolicy/automated/selfHeal", "value": false}]'
kubectl patch application api -n argocd --type='json' -p='[{"op": "replace", "path": "/spec/sources/0/targetRevision", "value": "0.34.0"}]' |
|
Even with the change in the chart I somehow still get this access error - is this something that works for you locally @tarrow ? |
I just checked, the clusterrole didnt get updated for some reason in my local cluster, I'll have a look |
|
can always |
|
I nuked my cluster because I didn't understand what was the cause, and indeed now the defaultrole looks better, but now I get an error for |
|
Okay - turns out I was holding it wrong. The api chart only provides the api-queue deployments with the |
|
can confirm it works! 🎉 |
* Route backend jobs to use correct image This selects a pod that matches the selector[1] for the appropriate backend service rather than any random backend MediaWiki pod [1] https://kubernetes.io/docs/concepts/services-networking/service/#services-in-kubernetes Bug: T408624 * parse out service name from backend host * try getting service using field not label selector * fix pint
2 participants
This selects a pod that matches the selector[1]
for the appropriate backend service rather than
any random backend MediaWiki pod
[1] https://kubernetes.io/docs/concepts/services-networking/service/#services-in-kubernetes
Bug: T408624