-
Notifications
You must be signed in to change notification settings - Fork 2
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
Split network-operator into operator and agent #121
Comments
#110 introduces new pod |
yes exactly, this is to split the Kubernetes to "some API" (gRPC in this case, NETCONF in another) part from the agent that performs the configuration |
@p-strusiewiczsurmacki-mobica one small addition: The operator-configurator will run the connectivity / post checks, just the configuration part will move to the agent. |
I've just created draft PR for this: #124 I have one more question - should BPF setup (https://github.com/telekom/das-schiff-network-operator/blob/main/cmd/manager/main.go#L183) be part of agent as well? |
This should be based off #112 & #110.
We would like to split the network-operator into two separate components. One is the operator, which watches the node configuration object and another one being the agent which takes the node configuration through an API (like gRPC or other means) and configures FRR and netlink.
This agent API will be the first pluggable interfaces of network-operator. The API (for this specific implementation) should be very easy and just send over the intended configuration. Difference check with the config on FRR / netlink layer will be part of the agent, no GET API will be introduced for now
The text was updated successfully, but these errors were encountered: