ipcache: Deprecate old API #27576
ipcache: Deprecate old API #27576
Conversation
joestringer
added
the
release-note/misc
maintainer-s-little-helper
bot
added
dont-merge/needs-release-note-label
christarazi
added
kind/cleanup
There was a problem hiding this comment.
Thanks for following up on this.
Future users should both insert and delete using the
newer API. Do not mix and match the upserts and deletes from deprecated
APIs and non-deprecated APIs for the same event type / resource update
into ipcache.
Sorry, I lost track of the previous PR where we had a brief discussion around testing. 😓 But this mix and match can be easily unit tested such that future usages can be caught via tests? At a high level, just an example - Calling ReleaseCIDRIdentitiesByCIDR and UpsertLabels and so on... If you've already added such unit tests, please ignore my comment (although it doesn't hurt to link them in the PR description. :)).
FWIW, there seems to be a Go convention to deprecate an API - https://github.com/golang/go/wiki/Deprecated. The deprecated APIs need to have a line with "Deprecated: ...", as opposed to DEPRECATED.
joestringer
force-pushed
the
pr/joe/deprecate-old-ipcache-apis
branch
from
37af3ed
to
070efaf
Compare
The following commits have introduced a new API for interacting with the ipcache, which is now preferred for all future interactions: - Commit e637814 ("ipcache: Introduce new asynchronous API") - Commit b6cef92 ("ipcache: Add new {Upsert,Remove}Prefixes() APIs") - Commit f9173b7 ("ipcache: Add ability to override identity via UpsertIdentity") Mark the older APIs as deprecated in order to help to slowly phase out future usage of those APIs. For more details, see GitHub issue #21142 ("Rework ipcache to handle metadata from multiple sources via a dedicated worker goroutine"). Note that there are still various paths using the older APIs to insert ipcache entries. If an entry is inserted using the older API, then the corresponding delete event should likewise use the same older API to delete the entry. Future users should both insert and delete using the newer API. Do not mix and match the upserts and deletes from deprecated APIs and non-deprecated APIs for the same event type / resource update into ipcache. Suggested-by: Aditi Ghag <aditi@cilium.io> Signed-off-by: Joe Stringer <joe@cilium.io>
joestringer
force-pushed
the
pr/joe/deprecate-old-ipcache-apis
branch
from
070efaf
to
e218707
Compare
|
/test |
The following commits have introduced a new API for interacting with the
ipcache, which is now preferred for all future interactions:
Mark the older APIs as deprecated in order to help to slowly phase out
future usage of those APIs. For more details, see GitHub issue #21142.
Note that there are still various paths using the older APIs to insert
ipcache entries. If an entry is inserted using the older API, then the
corresponding delete event should likewise use the same older API to
delete the entry. Future users should both insert and delete using the
newer API. Do not mix and match the upserts and deletes from deprecated
APIs and non-deprecated APIs for the same event type / resource update
into ipcache.
PR #27327 recently fixed bugs in
the case of fixed APIs and added unit tests for those cases, but still
it's better for all future users to focus on using the newer APIs for
better internal feature compatibility rather than mixing and matching.
Suggested-by: Aditi Ghag aditi@cilium.io
Signed-off-by: Joe Stringer joe@cilium.io