Skip to content
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

Open
chdxD1 opened this issue May 23, 2024 · 4 comments
Open

Split network-operator into operator and agent #121

chdxD1 opened this issue May 23, 2024 · 4 comments
Labels
enhancement New feature or request

Comments

@chdxD1
Copy link
Member

chdxD1 commented May 23, 2024

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

image

@chdxD1 chdxD1 added the enhancement New feature or request label May 23, 2024
@p-strusiewiczsurmacki-mobica
Copy link
Contributor

p-strusiewiczsurmacki-mobica commented May 24, 2024

#110 introduces new pod network-operator-configurator. With this change network-operator watches CRDs vrfrouteconfigurations, layer2networkconfigurations and routingtables and creates per node configuration NodeConfig. network-operator-configurator watches NodeConfigs and configures the networking. Do I understand correctly that we would like to add third element (a pod for now?) that will get config from the network-operator-configurator (through gRPC) and will perform networking configuration?

@chdxD1
Copy link
Member Author

chdxD1 commented May 24, 2024

#110 introduces new pod network-operator-configurator. With this change network-operator watches CRDs vrfrouteconfigurations, layer2networkconfigurations and routingtables and creates per node configuration NodeConfig. network-operator-configurator watches NodeConfigs and configures the networking. Do I understand correctly that we would like to add third element (a pod for now?) that will get config from the network-operator-configurator (through gRPC) and will perform networking configuration?

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

@chdxD1
Copy link
Member Author

chdxD1 commented May 24, 2024

@p-strusiewiczsurmacki-mobica one small addition: The operator-configurator will run the connectivity / post checks, just the configuration part will move to the agent.

@p-strusiewiczsurmacki-mobica
Copy link
Contributor

I've just created draft PR for this: #124
I've used the simpliest gRPC implementation, that just serializes the NodeConfig and pass those to the Agent.

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants