Conversation
juliaaano
requested review from
agonzalezrh,
fridim,
rut31337,
stencell and
wkulhanek
as code owners
wkulhanek
left a comment
wkulhanek
left a comment
There was a problem hiding this comment.
No. The variables come from the caller. We don't query the cluster in every single workload
|
We have standard variables that are available whenever either open shift-cluster or openshift-workloads calls a workload: |
That's not true. The variables are expected to be available as global variables. And there are no safety checks! If they came from the caller, then we would have that being passed/set in agV common.yaml. I thought you appreciated not depending on the global vars and being explicit, so I don't understand the pushback, it can't be the cost of querying the cluster? I'll give you a use case. I need to run this role standalone (separate) when doing local dev execution. In that case, it fails unless I set those vars myself. |
|
@juliaaano how are you running the role? If you run via the open shift-workloads config you don't have that problem. If not you'll have to pass the vars for your specific cluster. You want every single role to call the cluster for the information that it needs? When the information is readily available? |
|
That’s a bit unfortunate, but not a big deal. I wasn’t expecting you to argue that we should rely on global variables, even if they seem to be common sense. I’ve never developed in agnosticd with the notion of standard variables, and I’ve never seen that documented anywhere. In my view, most people were using those vars because it was easy, not necessarily because it was the right thing to do. |
|
Understood. But that's the pattern that every single role in core_workloads follows and (since @newgoliath asked) that's documented in the example role. I made sure that we didn't query the same thing in every role - it was a mess - different vars, different way to query ( |
3 participants
No description provided.