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.

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

Extended support for customizing whereabouts ip-reconciler cron schedule #392

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

nicklesimba
Copy link
Collaborator

Added a configmap with "cron_schedule" key value pair. The value of cron_schedule (i.e. "30 4 * * *") will be put into a file of the same name on whereabouts ip-reconciler pods, such that when the reconciler is enabled, the file should appear on the pod.

Whereabouts will now search for the reconciler_cron_file, and if present, it will use the cron schedule from the file. If the file is not present a default value from the flatfile will be used instead.

@maiqueb
Copy link
Collaborator

maiqueb commented Nov 23, 2023

Hm I wonder if this isn't good enough for what you need: #317

IIUC, the user would edit the existing ds - configuring the cron via env variable, and kill the ds pods.

@nicklesimba
Copy link
Collaborator Author

nicklesimba commented Nov 27, 2023

Hm I wonder if this isn't good enough for what you need: #317

IIUC, the user would edit the existing ds - configuring the cron via env variable, and kill the ds pods.

This PR provides support for Openshift users to edit cron schedule via configmap. I think this is a separate feature.

See: https://github.com/k8snetworkplumbingwg/whereabouts/pull/392/files#diff-307d21cb211139c5c6d37b29f30d91ccd3d8b39ea8a338c984b560ec0769e3f1R160

Edit: I think you might be correct after all...thank you for the suggestion Miguel!

@cgoncalves
Copy link

@nicklesimba are you agreeing that #317 is sufficient? If so, this PR could be closed I think.

@nicklesimba
Copy link
Collaborator Author

After some investigation, I think this support might still be necessary. What Miguel linked allows users to change the cron schedule at install time, but these changes allow a user to update during runtime.

@maiqueb
Copy link
Collaborator

maiqueb commented Dec 11, 2023

After some investigation, I think this support might still be necessary. What Miguel linked allows users to change the cron schedule at install time, but these changes allow a user to update during runtime.

You can still react to updates by updating the config map and kill the daemonset pods; the new pods will load the "new" configuration.

I mostly wonder if that's good enough. Happy to hear feedback.

@nicklesimba
Copy link
Collaborator Author

My understanding is that the whereabouts install-cni.sh script has the following definition:

https://github.com/k8snetworkplumbingwg/whereabouts/pull/392/files#diff-c8589450558444bb4def3f2633a8eb70db55df1c2a86366d265aeb768e3e625bR16

This makes it so that when installation happens, whatever environment variable is added by the configmap (even if it's correctly updated) will get overwritten by the above line.

At least, this is the behavior I observed, and the explanation I gave is my hypothesis, but I might be misunderstanding installation order.

@@ -19,7 +19,7 @@ WHEREABOUTS_RECONCILER_CRON=${WHEREABOUTS_RECONCILER_CRON:-30 4 * * *}

mkdir -p $CNI_CONF_DIR/whereabouts.d
WHEREABOUTS_KUBECONFIG=$CNI_CONF_DIR/whereabouts.d/whereabouts.kubeconfig
WHEREABOUTS_FLATFILE=$CNI_CONF_DIR/whereabouts.d/whereabouts.conf
WHEREABOUTS_FLATFILE=$CNI_CONF_DIR/whereabouts.d/whereabouts.conf # Yuki~ Nikhil's note: imo we should remove "flatfile" from whereabouts vocabulary and call this "WHEREABOUTS_CONF_FILE" instead. Flatfile may be the format but it's confusing naming.
Copy link
Collaborator

Choose a reason for hiding this comment

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

+1 on the naming.

@maiqueb
Copy link
Collaborator

maiqueb commented Dec 13, 2023

My understanding is that the whereabouts install-cni.sh script has the following definition:

https://github.com/k8snetworkplumbingwg/whereabouts/pull/392/files#diff-c8589450558444bb4def3f2633a8eb70db55df1c2a86366d265aeb768e3e625bR16

This makes it so that when installation happens, whatever environment variable is added by the configmap (even if it's correctly updated) will get overwritten by the above line.

At least, this is the behavior I observed, and the explanation I gave is my hypothesis, but I might be misunderstanding installation order.

This line is setting a default: i.e. it will define WHEREABOUTS_RECONCILER_CRON with the value of the WHEREABOUTS_RECONCILER_CRON environment value, or with "30 4 * * *" is the env variable is not defined.

But if you're saying it does not work ... That is probably something else we need to figure out. I can't say why it does not work as expected since I don't know.

@@ -130,10 +143,16 @@ spec:
mountPath: /host/opt/cni/bin
- name: cni-net-dir
mountPath: /host/etc/cni/net.d
- name: cron-scheduler-configmap
mountPath: /cron-schedule
Copy link
Collaborator

Choose a reason for hiding this comment

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

wrong indentation. I guess this is why the daemonset does not start in e2e tests


## Reconciler Cron Expression Configuration for live clusters via configmap (optional)

Yuki~ README: this section may belong in the CNO since the steps outlined are not technically part of whereabouts. I'm not sure, and suggestions are welcome.
Copy link
Collaborator

Choose a reason for hiding this comment

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

let's remove this line.

@@ -66,7 +68,7 @@ func main() {
defer networkController.Shutdown()

s := gocron.NewScheduler(time.UTC)
schedule := cronExpressionFromFlatFile()
schedule := determineCronExpression()
Copy link
Collaborator

Choose a reason for hiding this comment

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

hm, I think you still need to react to updates to the cron expression; meaning, this will only occur when the process starts.

Either you use an higher lib - like fsnotify - or implement something like that using a goroutine that checks if the file's contents have changed, and if so, restart the scheduler.

I guess even exiting the process could be good enough (but worse than reloading the config), since the pod would restart.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants