Intending to fork & update; link to fork in README?

[emmanuel]

Howdy 👋

We (Pelotech) have recently started using Nidhogg. Our use-case is to manage taints to control pod scheduling while using Multus (along with other CNI plugins). We've encountered an issue or two related to outdated APIs (resulting in noisy warnings in logs), and have found some flakiness (seems to be due to an issue with the logic used to detect DaemonSet readiness). We also have thoughts about updating the config approach (to eliminate the ConfigMap).

From the unanswered issues and time since last commit, it seems like this project is more-or-less done/complete (and/or abandoned). Our intention is to update the code to current idiomatic Golang (e.g., Go modules, etc), to update the dependencies (esp. Kubernetes client), and update the readiness check.

In addition, we plan to update the API to remove everything related to NodeSelector and DaemonSet name, and to move that functionality into annotations/labels on the relevant DaemonSet. This approach would move all scheduling logic to the monitored DaemonSet, as well as which taint is related to which DaemonSet (instead of the current fixed taint naming: nidhogg.uswitch.com/$DS_NAMESPACE.$DS_NAME). This change, in particular, will be a major breaking, API change. In our view it will increase the flexibility and generality of Nidhogg.

If in fact USwitch is not continuing development of Nidhogg, once we've released an updated version, we'd be glad if you were willing to point to the new version in the README here. There are many places that link to uswitch/nidhogg and it would be ideal to ease discovery of a new iteration.

Will you accept a PR to direct future users to an updated and actively maintained fork?

[SQUIDwarrior]

As a Nidhogg user that would like to see some changes (namely, an ARM version) I would support a forked version of this repo.

[SQUIDwarrior]

@emmanuel If you do a fork, can you post it as a comment here? I would be happy to contribute. I'm still waiting for this feature :-P #20

[giorgia-amici]

Hi @emmanuel, sorry for the late response. As you mentioned, we won't be maintaining Nidhogg going forward so we are more than happy to accept a PR to direct future users to an updated and actively maintained fork. Just ping me the link and I will happily update our README to remove the uswitch refs

[emmanuel]

@giorgia-amici awesome, thanks for confirming.

@SQUIDwarrior — no promises on timelines, but we (Pelotech) do plan to take on this fork. I'll comment here when we get things up and running (the build pipeline). I imagine adding ARM images will be pretty straightforward.

[josmo]

I just took a quick pass on starting the fork - https://github.com/pelotech/nidhogg

@SQUIDwarrior ghcr.io/pelotech/nidhogg:latest (pinned ghcr.io/pelotech/nidhogg:v0.5.0) - should have amd64 and arm64, as well as a few other updates we'd made in the last while.

@giorgia-amici Thanks a ton on confirming! - I had a quick question on if you all are using something else now for this problem space, or just didn't need it? Just wondering the history :) - also have any thoughts on if forking would be better vs transferring to keep PRs, Issues, existing forks? Either one works for us although transferring might make it cleaner.