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
l2: exclude common virtual interfaces for announce services #1767
Conversation
caad5bf
to
7d8a004
Compare
the idea seems good but maybe having it as a configmap is better |
So, let's move this forward but let's have the list overrideable and not hardcoded. A configmap read upon start is good enough imo, no need to handle the live reload. |
Wdyt @cyclinder ? |
I think both are ok, but I prefer hardcoded :) First of all, it shouldn't be related to the current interface-selector, it's more of a |
right, it must be independent and always applied, more or less as your current logic is but loading that list from a configmap when the process starts instead of having it hardcoded. This will help us to avoid releases when users hit a corner case we didn't think about |
@fedepaol got it. I try to working on this. |
d3a0c93
to
bcbdcde
Compare
Hi @fedepaol , Could you mind having a review? Thanks. It seems this CI failing isn't related to this changes. |
yup, will do soon-ish (and I have an outstanding pr to fix the ci) |
25db649
to
c37394a
Compare
I made some testing base on these changes on my local, It works well, as speaker log shown below:
Could you mind taking a look? Thanks :) @fedepaol |
e069613
to
caaea9a
Compare
speaker/main.go
Outdated
@@ -51,6 +52,8 @@ var announcing = prometheus.NewGaugeVec(prometheus.GaugeOpts{ | |||
"ip", | |||
}) | |||
|
|||
var defaultConfigPath = "/etc/metallb/conf.yaml" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: this doesn't have to be a var, could be a const. Also, I'd use the presence of the file instead of the boolean to understand if we need to enable the mechanism. Maybe that's where we want to override the path? But I think it's fair to have it hardcoded.
Also also, I'd do all the parsing in one shot and have the parse function return the regexp, so we have all the logic in one place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be better if we provide a flag to override the path, It's good for helm install
:
when the value is empty in values.yaml: We don't create configMap, and we don't mount the file...
When the value is not empty and the file exists, we enable this mechanism, Is it ok?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition , I think all the configurations here(
Line 205 in 6a5ad67
type controllerConfig struct { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still don't see the value in setting passing the name as a parameter. It can be a convention.
If we don't want the file, we don't create the volume and the configmap, the load of the file will fail and we won't override.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition , I think all the configurations here(
Line 205 in 6a5ad67
type controllerConfig struct { ), should be declared in one place(in a configMap) so that it is easy to configure and update, how about this?
I don't like this approach, having flags give a better understanding of what's being passed to the process and that's what people expect. Configmaps for knobs are fine if they are tweaks that are not normally expected to be used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like this approach, having flags give a better understanding of what's being passed to the process and that's what people expect. Configmaps for knobs are fine if they are tweaks that are not normally expected to be used.
OK, Thanks for the reply. I just had a whim, please ignore my thoughts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we don't want the file, we don't create the volume and the configmap, the load of the file will fail and we won't override.
I currently read the env to determine if this mechanism is enabled and if the value is not empty and the file exists then it is enabled. The -set .speaker.excludeInterfaces.configPath
flag is used when the helm install
. The default configPath is '/etc/metallb/conf.yaml', if it is empty, it is not enabled.
Do you mean we don't need to expose env to enable this mechanism?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still don't see the value in setting passing the name as a parameter.
The benefit of this is that we can decide whether to enable this mechanism when helm install
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can still decide, we set a parameter in helm that drives the creation of the volume and the related configmap (and by default I'd create them). If those are not created, the go code will land in the notexists error and will not parse the map. Or I am missing something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, That's what the PR does. The difference is that now this parameter is a string, indicating the config path to the file. Or should this be a boolean type? Then we hardcode the config file path in go code.
sorry for the delay, left one last comment (I hope). I think the boolean parameter is not necessary as we are using a fixed path by convention, so we can rely on the presence or the absence of the file to drive the parsing |
185bfea
to
98eebdd
Compare
Did one last minute change about naming directly on your branch. |
80df3af
to
fe297f5
Compare
In arp mode, Some common virtual interfaces should not be used to announce services, such as kube-ipvs0, docker0, etc. This PR will dispatch these common virtual interfaces. Signed-off-by: cyclinder <qifeng.guo@daocloud.io>
There was a nit |
Thanks, Does CI Failling is related to these changes? |
nope, it's related to the operator not being updated to the latest frr yet (this PR: metallb/metallb-operator#328) We can ignore the failure for now. |
In arp mode, Some common virtual interfaces should not be used to announce services, such as kube-ipvs0, docker0, etc. This PR will dispatch these common virtual interfaces.
Signed-off-by: cyclinder qifeng.guo@daocloud.io
#1727
l2: exclude common virtual interfaces for announce services.