Standalone mode for OpAMP k8s bridge#4986
Conversation
50b5f7b to
3464209
Compare
E2E Test Results 37 files 235 suites 2h 20m 57s ⏱️ Results for commit 704ea45. ♻️ This comment has been updated with latest results. |
3259be0 to
57e3079
Compare
|
The failing VULN does not affect us. It only affect plugin installs when running docker as a daemon which we do not. We only use it indirectly as an API. more details: GHSA-pxq6-2prw-chj9 Patching is not as simple as docker has deprecated the github.com/docker/docker package and replaced it with multiple smaller packages in github.com/moby/moby/*; and we don't use the docker package directly. The call path is: So each one of those packages will need to migrate to moby to pick up the security patch. I suggest we ignore this vuln as it is essentially a false positive for us and upgrading to a fixed moby version means waiting on close to a dozen OSS packages to do it. migration details: https://github.com/moby/moby/releases/tag/docker-v29.0.0 |
2e90995 to
f2c5727
Compare
|
this is top on my review list, thank you very much for the contribution here and apologies for the delay, i was on PTO. |
9cbc35f to
054483e
Compare
jaronoff97
left a comment
There was a problem hiding this comment.
some requested changes, but overall i would like to see some better test coverage as well as some more thought around the code boundaries. definitely in favor of this, but there's a few open questions I'd like to hear more about.
|
Addressed some things. Will add more e2e tests. |
edc4894 to
fec3816
Compare
aec863c to
b95651f
Compare
jaronoff97
left a comment
There was a problem hiding this comment.
Looking much better, a few comments and questions but the shape of this is much better.
|
Thanks @jaronoff97 made the requested changes. PTAL and let me know if anything else is needed. |
jaronoff97
left a comment
There was a problem hiding this comment.
looking much much better only a couple more conventional go things.
|
Thanks @jaronoff97. Appreciate the quick review. PTAL when you can. |
jaronoff97
left a comment
There was a problem hiding this comment.
only a single minor comment, but otherwise this is good. thank you very much for enduring the long back and forth here – i'm happy with where we've ended up here. I'm going to ask for one more maintainer to review before we merge.
❌ 2 Tests Failed:
View the top 2 failed test(s) by shortest run time
To view more test analytics, go to the Test Analytics Dashboard |
|
@jaronoff97 Thanks for all the time you invested and for the thorough review. I have a few improvements/simplifications lined up that I think you'll like. |
swiatekm
left a comment
There was a problem hiding this comment.
The logic and content of this change makes sense to me. I'd like to try to give it a more narrow scope, so it's not +4k lines mixing different concerns.
- Could we move the CRD modifications out into a follow-up? It's not even clear to me if those are valuable, considering the whole point is to decouple from the operator.
- We're not running the E2E tests in CI. Either they should be run, or they should be removed from this PR and added in a follow-up.
- I'd rather move the manifests in
config/out as well. These are something like a public API in the sense that users might justkubectl -kthem, and so should require more careful review. - On a different note, I think this PR could use more docstrings for the functions it adds. It would make it easier to review, if nothing else.
Also @dmitryax, you're the author of the issue, could you have a look and see if this does what you'd envisioned?
@swiatekm They're very useful during development so I've moved them to a new |
I've removed them for now. You're right they're not very useful right now. I think we might need them in the future. I'll add them back in another PR if needed/requested. |
|
@swiatekm PTAL when you can. Thanks. |
How about moving them to cmd/operator-opamp-bridge/manifests/standalone and adding a small README.md saying that there are dev manifests not intended for production usage? |
|
@swiatekm moved to cmd and added readme |
swiatekm
left a comment
There was a problem hiding this comment.
I don't like the copious use of context.Background, but this is something the codebase unfortunately already does, so I'm not going to ask for it to be fixed. I highlighted two spots where it should be fixed in this PR, but we should do a follow-up where we thread context through all the methods that need it @jaronoff97.
|
@swiatekm updated the ctx usage. thanks. |
|
@owais I'll be happy to approve after you fix the conflict. |
Introduces a new standalone mode that allows managing collector config from a remote server without requiring Operator CRDs. Adds the standalone client, a plain collector instance type, Kubernetes RBAC and deployment manifests, and a --mode flag to select between operator (default) and standalone at startup.
Co-authored-by: Mikołaj Świątek <mail@mikolajswiatek.com>
|
@swiatekm resolved. |
|
The PR description needs to be updated. Looks like we don't support |
|
@jaronoff97 you did the majority of the review for this PR and are the opamp bridge expert, so I'm leaving it to you to merge. |
Description:
This PR implements a basic standlone mode for the OpAMP bridge that works directly on collector configmap(s) instead of operator CRDs. It does not depend on the operator. The ConfigApplier interface almost already satisfies everything we need with some minor tweaks. The change is mostly a new implementation of the ConfigApplier interface that works directly with configmaps.
It watches configmaps with a specific label and reports them to the OpAMP server. Users can then remotely manage that config from the server.
Link to tracking Issue(s):
How to review:
internal/agent&internal/operatorpackages moves things around a bit to allow the new standalone mode to implement the existing Config Applier interface. No new features or changes to existing features in these packages.internal/standalonecontains all of the new feature code. It implements a standalone client and an implementation of the ConfigApplier interface.config/standalone-bridgecontains the k8s manifests used to deploy the bridge in standlone mode.Testing: