Let pods report their state to the operator#472
Conversation
| @@ -0,0 +1,170 @@ | |||
| #!/usr/bin/python3 | |||
There was a problem hiding this comment.
i find it unusual there's no .py extension here? what's the rationale for that?
There was a problem hiding this comment.
I originally implemented it in bash, then moved it to python. And since we have this pattern of bind-mounting files directly which is causing us concerns during minor update if anything changes, I figured there was no point it exposing the language here. So I discarded the extension.
There was a problem hiding this comment.
OK, so then it's suggestive of a practice we would in theory have for all of our files is that accurate?
There was a problem hiding this comment.
That is something that I would like, but I'm open to discussion. When I rewrote this new script in python, I figured all the other scripts would likely benefit from being rewritten in a higher-lever language eventually, and if so, their filename would need to be updated.
So right now I'm in favor of getting rid of file extension in those injected scripts, because we own them, we may need to change their implementation later, and we can set our own convention anyway, so why not.
Do you have a strong opinion on that, maybe we should keep the extension if you think it makes sense?
There was a problem hiding this comment.
i sorta like having the extension :) but the whole "we changed our approach and new bind mounts are a problem" would be the reason we wouldnt, but what is the problem with new bindmounts ?
There was a problem hiding this comment.
I'll re-add the extension then, not a big deal.
The problem with adding changing bind-mounts is that we have to special case our code we every new path, because we have to support rolling update, even from an old FRx version to the latest.
(I added https://github.com/openstack-k8s-operators/mariadb-operator/tree/main/test/ansible to verify that new code doesn't break rolling update, it will become a voting prow job in a subsequent PR.)
|
/recheck |
|
/test mariadb-operator-build-deploy-chainsaw |
dciabrin
force-pushed
the
seqno-push
branch
2 times, most recently
from
ade476b to
718cfeb
Compare
|
/retest |
|
/test mariadb-operator-build-deploy-chainsaw |
Reverse the introspection approach for bootstrapping the cluster. Until now, the mariadb operator was in charge in running scripts inside pods to extract the state of the mysql database. Now the pod are responsible for reporting the state of their database to the operator, by updating their associated galera CR via calls to the API server. This allows asynchronous reporting from the operator's perspective, and ensure that newly (re)started pod will always update the operator state, preventing stale data to linger in the galera CR status. Jira: OSPRH-23075
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dciabrin, lmiccini The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-merge-bot
Bot
merged commit a569a68
into
openstack-k8s-operators:main
3 participants
Reverse the introspection approach for bootstrapping the cluster. Until now, the mariadb operator was in charge in running scripts inside pods to extract the state of the mysql database.
Now the pod are responsible for reporting the state of their database to the operator, by updating their associated galera CR via calls to the API server. This allows asynchronous reporting from the operator's perspective, and ensure that newly (re)started pod will always update the operator state, preventing stale data to linger in the galera CR status.
Jira: OSPRH-23075