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 have just one helm release, but have Test Wikidata use the `staging` cluster while Wikidata uses the `eqiad` and `codfw` clusters? >> >> Meaning merging the functionality of `test` in the functionality of the `staging` release ? It certainly is possible, although that would mean overloading the functionality of the `staging` release. We do have an open big question of what the `staging` releases mean to deployers after all and whether they indeed find them useful. I am a bit ambivalent about that approach, but it certainly is possible and if product people deemed it is useful to have a test release, we can go down that path. > > Yeah, that’s certainly an open question for me – I don’t know what the current functionality of the `staging` release is. It was always envisioned as safety net. One could deploy there before deploying to production in order to catch errors that standard CI/CD failed to catch. That being said, I think that it's natural for all these kinds of environments to obtain more roles than the intended ones and I don't think we have made a very consistent effort to communicate what the vision was. > FWIW, when I’ve deployed new Termbox versions in the past, I never tested the deployment “directly” (though I assume it would be possible – `curl` some internal URL?) – I only ever tested it through MediaWiki, by looking at new items on Wikidata or Test Wikidata and checking whether they had a server-side rendered termbox or not. But IIUC, this only allows testing two of the possible release+cluster combinations: Wikidata targets the production release on the eqiad/codfw clusters, I assume, while Test Wikidata targets some other combination (I don’t know which one). There is a loop here. `wikidata.org` uses the `production` release of each helmfile environment (eqiad/codfw to match our DCs). The `production` releases use `wikidata.org` in their own turn (that's the loop I was pointing out). The `staging` release isn't being used by anything. It is using wikidata.org production as well (you can tell by the fact that the only thing it overrides from the main values.yaml file is the number of replicas). `test.wikidata.org` uses the `test` release. The `test` release uses `test.wikidata.org` in turn (same loop as above). As for a curl request example, here it is deploy2002:~$ curl https://staging.svc.eqiad.wmnet:4004/_info {"name":"wikibase-termbox","version":"0.1.0"} Your test release is accessible as deploy1002:~$ curl http://staging.svc.eqiad.wmnet:3031/_info {"name":"wikibase-termbox","version":"0.1.0"} Note the difference in ports and HTTPS vs HTTP. The `test` release, being the unique thing that it is, doesn't have TLS support as it doesn't use the service mesh. > (I also just noticed that `helmfile.yaml` lists //three// releases: production, staging, and test. ~~I don’t think I was aware of the test one before, to be honest.~~ Edit: Nonsense, that’s the one I updated in this Gerrit change <https://gerrit.wikimedia.org/r/c/operations/deployment-charts/+/992387>. But there’s definitely //something// about the releases and clusters/environments that I didn’t realize, because I previously thought of it as 2×3 combinations, when it seems to be more 3×3. Maybe the thing I missed is that the name “staging” is used both for a release and for an environment/cluster?) It's 4 releases in total. 1 `production` release per helmfile environment (or cluster/DC/data center[1]) and 2 releases, named `staging` and `test` that both reside in a kubernetes cluster named `staging`. The corresponding environment in helmfile is also named `staging`. Some of the above can possibly be treated as implementation details. There is nothing forcing us to have the staging and test releases in a different cluster/environment, they could also reside in the eqiad/codfw ones (addressing them would a little bit different but not by much). We just chose to go that way for some historical reasons. [1] You can use those terms kinda interchangeably for this specific discussion we have right now. That might not always be the case, but it sure is right now TASK DETAIL https://phabricator.wikimedia.org/T355685 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: akosiaris Cc: Aklapper, akosiaris, Clement_Goubert, Jdforrester-WMF, Michael, WMDE-leszek, Lucas_Werkmeister_WMDE, Danny_Benjafield_WMDE, Kappakayala, Mohamed-Awnallah, Astuthiodit_1, lbowmaker, Arnoldokoth, BTullis, karapayneWMDE, Invadibot, Ywats0ns, maantietaja, wkandek, JMeybohm, ItamarWMDE, Akuckartz, darthmon_wmde, Nandana, jijiki, Lahi, Gq86, GoranSMilovanovic, QZanden, KimKelting, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331
_______________________________________________ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org