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

Reply via email to