Support subresources updates

[kopf-archiver]

An issue by smileisak at 2019-12-04 16:22:06+00:00
Original URL: zalando-incubator/kopf#264
 

Expected Behavior

Handle kopf.on.update for subresources
Let's say that i want to handle subresources updates and updating the parent resources. For example:

apiVersion: renault.org/v1
kind: ParentResource
metadata:
  name: parent
spec:
  foo: bar
  childFoo: childBar

apiVersion: renault.org/v1
kind: ChildResource
metadata:
  name: child
spec:
  childFoo: childBar

The update of kind: ChildResource should run the logic of the child resource and update the ParentResource without re-runinng the logic of child resource.

Actual Behavior

When updating the ChildResource and try to update the spec of ParentResource the logic of ChildResourcewill re trigger.

Specifications

• Platform: GKE
• Kubernetes version:

Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.3", GitCommit:"b3cbbae08ec52a7fc73d334838e18d17e8512749", GitTreeState:"clean", BuildDate:"2019-11-14T04:24:29Z", GoVersion:"go1.12.13", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"14+", GitVersion:"v1.14.7-gke.23", GitCommit:"81c87c699557fed991e292cd328b2129c2f242a2", GitTreeState:"clean", BuildDate:"2019-11-07T19:23:23Z", GoVersion:"go1.12.11b4", Compiler:"gc", Platform:"linux/amd64"}

• Python version: (use python --version)

Python 3.7.4

• Python packages installed: (use pip freeze --all)

adal==1.2.1
aiohttp==3.5.4
aiojobs==0.2.2
aioschedule==0.5.2
asn1crypto==0.24.0
async-timeout==3.0.1
atomicwrites==1.3.0
attrs==19.1.0
cachetools==3.1.0
certifi==2018.11.29
cffi==1.12.2
chardet==3.0.4
Click==7.0
coloredlogs==10.0
coverage==4.5.4
coverage-badge==1.0.1
cryptography==2.6.1
decorator==4.4.0
fut==0.4.2
google-api-python-client==1.7.8
google-auth==1.6.3
google-auth-httplib2==0.0.3
httplib2==0.12.1
humanfriendly==4.18
idna==2.8
iso8601==0.1.12
jsonpath-ng==1.4.3
kopf==0.21
kubernetes==8.0.1
more-itertools==6.0.0
multidict==4.5.2
oauth2client==4.1.3
oauthlib==3.0.1
pip==19.2.3
pluggy==0.9.0
ply==3.11
protobuf==3.6.1
py==1.8.0
pyasn1==0.4.5
pyasn1-modules==0.2.4
pycparser==2.19
PyJWT==1.7.1
pykube-ng==0.28
pyotp==2.2.7
pytest==4.3.0
pytest-cov==2.8.1
python-anticaptcha==0.3.1
python-dateutil==2.8.0
python-ldap==3.2.0
pytz==2019.1
PyYAML==3.13
requests==2.21.0
requests-oauthlib==1.2.0
rsa==4.0
setuptools==41.2.0
six==1.12.0
tzlocal==2.0.0
uritemplate==3.0.0
urllib3==1.24.1
urllib3-mock==0.3.3
websocket-client==0.55.0
wheel==0.33.6
yarl==1.3.0

---

Commented by nolar at 2019-12-07 12:07:37+00:00
 

Can you please clarify on "… without re-runinng the logic of child resource"? What is "re-running" here? When and how does it happen? Maybe a simplified example would help?

If there is a handler defined for the child resource, and an update happens, it is reasonable to expect that the handler will be executed.

---

One way to avoid this is to use @kopf.on.field(..., field='spec.something') handler, which will be called only when spec.something or spec.something.deeper fields are changed, but not when e.g. status.message or metadata.labels are changed — this will be silently ignored (with no logs).

There are few restrictions though. The spec stenza triggers the update handlers always, for any sub-field. Same is true for top-level data fields (not in spec/status/meatdata). The status stenza — only if some of the fields are explicitly awaited in @kopf.on.field() decorators, and is ignored otherwise. The metadata stenza triggers the handlers only for labels & annotations (except for a couple of known "system annotations"), and ignores the rest of the system fields.

This logic is expressed in the resource's essence extraction.

So, it is possible to define the handlers that are executed not for any resource update, but for some fields-of-interest only.

---

There are also plans for a more advanced cross-resource communication (see #58 (comment) and ideation gist) — but the syntax/DSL is not yet clear enough to express this as an issue. The last two ideas in that gist (lines 229+) look like the way to go.

Nevertheless, the communication will be implicitly performed through the resources' status fields. Which, in turn, will trigger the handlers, if those handlers are defined to react to these status fields (as described above).