NFD-Topology updater as a oneshot job

[swatisehgal]

As a follow-up from the discussion in #525, it has emerged that we should reconsider deploying nfd-topologyupdater as a oneshot job. We should do one of the following:

1. Deploy nfd-topologyupdater only as a daemonset and remove its ability to be deployed as a oneshot job
2. Populate only capacity and allocatable (and not available) when --oneshot flag is specified
3. just simply log in case --oneshot and not create NRT CRs

[marquiz]

I think we could do # 2 above. I.e. only update node capacity and allocatable, and not scan pods at all if --oneshot is specified.

WDYT?

[zwpaper]

hi @marquiz, I would like to take action on this issue, but I not yet figure out what we should do exactly, should we

1. update the kustomization leaving NRT daemonset only
2. do nothing in NRT cmd as daemonset has an Always restart policy
3. only update node capacity and allocatable, and not scan pods in NRT

[marquiz]

Hi @zwpaper, thanks for reaching out!

A good question, indeed 😇 Above, I was pondering that only publishing node capacity and allocatable would be a good solution but now I'm starting to think otherwise.

1. update the kustomization leaving NRT daemonset only

I'm now inclined towards this solution, drop the Job deployment alltogether. The problem I see with Job is that all the information is dynamic, extended resources can be added/removed etc. Also, the users should be able to get capacity/allocatable by examining the node status directly. We can leave the --oneshot parameter so that users can deploy it as a job if they want (plus I think it is probably useful for testing/development/debugging, too). But, I think we probably shouldn't advertise as a recommended/supported deployment option.

@swatisehgal any thoughts?

[swatisehgal]

I am okay with removing the topology-updater job overlay and leaving the --oneshot parameter. I think it hits the sweet spot as it gives the ability to the user to deploy topologyupdater as a job (if they really want to) for inspection/testing/development/debugging and therefore naturally comes with consciousness that it is being deployed as oneshot job and should be considered static information.

[marquiz]

@zwpaper I think we have a conclusion/consensus 😊 Drop the topologyupdater-job overlay (and related bits e.g. from base)

[zwpaper]

hi @marquiz, I have check docs and other yamls, there is only those two dir containing the topology updater job, I have deleted them, is this all we need to do? it always feels like there is something more I can do.

[marquiz]

there is only those two dir containing the topology updater job, I have deleted them, is this all we need to do?

Actually, in this case, that should be all as we haven't updated documentation, yet

it always feels like there is something more I can do.

😄 I think it is that simple, this time