Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

New way of showing kata nodes in kataconfig status #329

Merged
merged 6 commits into from Jul 4, 2023
Merged

New way of showing kata nodes in kataconfig status #329

merged 6 commits into from Jul 4, 2023

Conversation

pmores
Copy link
Contributor

@pmores pmores commented Jun 30, 2023

This PR adds a new section to KataConfig.status called kataNodes which lists cluster nodes grouped by the status of kata installation on them which can be one of installed, installing, waiting to install, failed to install, not installed, uninstalling, waiting to uninstall and failed to uninstall.

By way of example, when applying a KataConfig that selects both nodes of a two-worker cluster, the newly added section might show

  kataNodes:
    waitingToInstall:
    - worker-0
    - worker-1

for a brief period of time, then something like

  kataNodes:
    installing:
    - worker-1
    waitingToInstall:
    - worker-0

Once worker-1 is installed the other worker starts installing

  kataNodes:
    installed:
    - worker-1
    installing:
    - worker-0

and finally

  kataNodes:
    installed:
    - worker-0
    - worker-1

The new addition runs alongside the existing status reporting for now.

@pmores
add predicate functions to determine kata installation status on node
ea8e9ff 
All predicates take the same arguments describing a node and figure out
if kata on the node is Installed, Installing, WaitingToInstall,
FailedToInstall, NotInstalled, Uninstalling, WaitingToUninstall or
FailedToUninstall.

Signed-off-by: Pavel Mores <pmores@redhat.com>
@pmores
factor getting kata coreos extension name out to a function
d290a8e 
This is a preparation for the next commit where this functionality will
be needed.

Signed-off-by: Pavel Mores <pmores@redhat.com>
@openshift-ci openshift-ci bot requested review from bpradipt and gkurz June 30, 2023 09:34
@pmores pmores force-pushed the new-way-of-showing-kata-nodes-in-kataconfig-status branch from 597ab70 to e393a19 Compare June 30, 2023 14:05
gkurz
gkurz approved these changes Jul 3, 2023
View reviewed changes
Copy link
Member

@gkurz gkurz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice improvement. Thanks @pmores !

@pmores
add function to take Node and determine its kata status
45634c3 
The first part computes inputs for the kata status predicates, the rest
runs the predicates.  For now, the result of classification is just logged.

Signed-off-by: Pavel Mores <pmores@redhat.com>
@pmores
add node lists by kata installation status to KataConfig.status
8e57e9d 
A list of nodes is added to KataConfig.status for each of Installed,
Installing, WaitingToInstall, FailedToInstall, Uninstalling,
WaitingToInstall and FailedToInstall kata installation statuses.  There's
no list for NotInstalled as that's left implicit (the NotInstalled status
is still logged though).

putNodeOnStatusList() is also changed to actually fill the lists.

Signed-off-by: Pavel Mores <pmores@redhat.com>
@pmores
add function to clear node kata installation status lists
580e343 
This is basically a counterpart of putNodeOnStatusList(), to be called
before the lists can start being populated by putNodeOnStatusList().

Signed-off-by: Pavel Mores <pmores@redhat.com>
@pmores
plug the new functionality in to updateStatus()
e52e051 
The new functionality runs alongside of the existing status reporting
for the time being.

Signed-off-by: Pavel Mores <pmores@redhat.com>
@pmores pmores force-pushed the new-way-of-showing-kata-nodes-in-kataconfig-status branch from e393a19 to e52e051 Compare July 4, 2023 09:26
@pmores pmores merged commit 93c5d1a into openshift:devel Jul 4, 2023
This was referenced Jul 4, 2023
Merged
Merged
gkurz added a commit to gkurz/sandboxed-containers-operator that referenced this pull request Dec 7, 2023
@gkurz
Always regenerate KataConfigStatus::KataNodes
2d4ce96 
The list of nodes where kata is deployed is part of the status of
the KataConfig. It is expected that the controller ensures this
list is up-to-date during all reconcile runs. Changes to this
list usually happen during installation/deinstallation of kata
on some nodes. But it is also possible that reconcile is called
and the status is lacking the list of nodes for some reason, e.g.
KataConfig was edited externally or KataConfig predates PR openshift#329.

Stop restricting the regeneration of this list to only happen when
kata is being deployed or removed. This might result in some more
trafic between the client and server but idempotency should prevail.

Signed-off-by: Greg Kurz <groug@kaod.org>
@pmores pmores mentioned this pull request Dec 8, 2023
Merged
3 tasks
beraldoleal pushed a commit to beraldoleal/sandboxed-containers-operator that referenced this pull request Jan 4, 2024
@gkurz @beraldoleal
Always regenerate KataConfigStatus::KataNodes
1916f22 
The list of nodes where kata is deployed is part of the status of
the KataConfig. It is expected that the controller ensures this
list is up-to-date during all reconcile runs. Changes to this
list usually happen during installation/deinstallation of kata
on some nodes. But it is also possible that reconcile is called
and the status is lacking the list of nodes for some reason, e.g.
KataConfig was edited externally or KataConfig predates PR openshift#329.

Stop restricting the regeneration of this list to only happen when
kata is being deployed or removed. This might result in some more
trafic between the client and server but idempotency should prevail.

Signed-off-by: Greg Kurz <groug@kaod.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@gkurz gkurz gkurz approved these changes

@bpradipt bpradipt Awaiting requested review from bpradipt

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
2 participants
@pmores @gkurz