NETOBSERV-963 revert most of cert watching #312
Conversation
Reverting most of certificate watching (NETOBSERV-684) as it generates a lot of pods restart. We did not necessarily have to do this certificate watching as CM/secrets are updated within volumes. We might however monitor carefully if new (or old) problems arise, potentially due to the kubelet sync delay for updating volumes And also make sure certificates aren't cached in our different workloads
jotak
changed the title
Codecov Report
@@ Coverage Diff @@
## main #312 +/- ##
==========================================
- Coverage 50.41% 50.39% -0.02%
==========================================
Files 43 43
Lines 5096 5072 -24
==========================================
- Hits 2569 2556 -13
+ Misses 2318 2311 -7
+ Partials 209 205 -4
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 1 file with indirect coverage changes Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
|
The solution was to: I see lots of code removed for the watcher, but were there code changes to remove caching? |
|
@stleerh if there are any remaining cached data, that wouldn't be in the operator, but in flp/plugin/ebpf. |
|
/ok-to-test |
openshift-ci
bot
added
the
ok-to-test
|
New images:
They will expire after two weeks. Catalog source: apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
name: netobserv-dev
namespace: openshift-marketplace
spec:
sourceType: grpc
image: quay.io/netobserv/network-observability-operator-catalog:v0.0.0-981c0ae
displayName: NetObserv development catalog
publisher: Me
updateStrategy:
registryPoll:
interval: 1m |
@jotak do u know of a way to force cert rotation ? |
@msherif1234 no, apart from deleting / recreating the LokiStack, which would generate a new certificate |
Actually this is wrong: while deleting + recreating LokiStack does delete and recreate the certificate CM, this is the same certificate that is inside. I didn't notice that the first time I tried. |
|
I've done four different performance tests with this image and have not hit the FLP bug once /label qe-approved |
Yes I guess we need to revisit eBPF agent kafka certificate reading that seems to be done at startup only: |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jotak The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Reverting most of certificate watching (NETOBSERV-684) as it generates a lot of pods restart. We did not necessarily have to do this certificate watching as CM/secrets are updated within volumes. We might however monitor carefully if new (or old) problems arise, potentially due to the kubelet sync delay for updating volumes And also make sure certificates aren't cached in our different workloads Signed-off-by: acmenezes <adcmenezes@gmail.com>
Reverting most of certificate watching (NETOBSERV-684) as it generates a lot of pods restart.
We did not necessarily have to do this certificate watching as CM/secrets are updated within volumes.
We might however monitor carefully if new (or old) problems arise, potentially due to the kubelet sync delay for updating volumes
And also make sure certificates aren't cached in our different workloads