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

annotate a service with the pool used to provide its IP #1637

Merged
merged 1 commit into from Nov 21, 2022

Conversation

cyclinder
Copy link
Contributor

annotate a service with the pool used to provide its IP

Signed-off-by: cyclinder qifeng.guo@daocloud.io

Fixed #1448

controller/service.go Outdated Show resolved Hide resolved
@fedepaol
Copy link
Member

Neat! Can you modify one of the e2e tests to validate that the annotation is set properly? No need to create a new one I think.

@cyclinder cyclinder force-pushed the annotation_svc branch 3 times, most recently from ba24250 to 8785973 Compare October 13, 2022 06:01
@fedepaol
Copy link
Member

Also, can you change the commit message to have the subject starting with a capital letter and provide a body on why the feature is useful? Thanks!

@fedepaol
Copy link
Member

Also also, not sure you saw it but the test is failing

@cyclinder
Copy link
Contributor Author

Yes, I saw it. I will test it in my local, and then update this PR.

st, svc = svc.Status, svcRo.DeepCopy()
var annotations map[string]string
st, annotations, svc = svc.Status, svc.Annotations, svcRo.DeepCopy()
svc.Annotations = annotations
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should reflect.DeepCopy annotations here, as what you are doing is copying the reference of the map (which is owned by svcRo)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, given this is becoming a bit beefy, consider moving it in a function

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, Done.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please review the latest changes, I appreciate it if you give me some advices

@cyclinder
Copy link
Contributor Author

Hi @fedepaol Can you take a look?

@fedepaol
Copy link
Member

yep sorry, I've been stuck with other stuff. I will do a round today / tomrorrow.
Sorry about that :/

@cyclinder
Copy link
Contributor Author

@fedepaol oh No sorry and No rush. Take your time!

controller/service.go Outdated Show resolved Hide resolved
controller/service.go Outdated Show resolved Hide resolved
@cyclinder cyclinder force-pushed the annotation_svc branch 2 times, most recently from 002f255 to 1ea2ebc Compare November 14, 2022 09:02
}

if err := c.client.UpdateStatus(svc); err != nil {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You need to call this only if one of the deepequals above changed. I suggest using a flag.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry I don't notice this

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I realize only now that this might not work because metallb has writing permissions only on the status subresource https://github.com/metallb/metallb/blob/main/config/rbac/role.yaml#L19
So it might be that this requires additional permissions, and if that is the case I am not sure it's worth it. If it's needed, we can pivot to expose this information via one of the status crds we are working to expose as part of #1685

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope, I made an image with the current branch and did a test for it, and the annotaitons of the service were successfully updated.

func updateSvcStatus(svc, svcRo *v1.Service) {
var st v1.ServiceStatus
st, svc = svc.Status, svcRo.DeepCopy()
// we need be update svcRo's status
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need this? svcRo is supposed to be read only

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should update status and annotations an same time , and then call UpdateService, Update svcRo's status here, I think it's OK.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Otherwise, when updateSvcAnnotations is called, the parameter svc has been reassigned and annotations are lost

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

uhm, never easy... let me think about it, not sure I like this versin because we'll need to remember if we ever add another function that changes something else

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So (and sorry if I stress too much on this), I think we can keep the "defensive" spirit of the original code by doing this:

	if reflect.DeepEqual(svcRo, svc) {
		level.Debug(l).Log("event", "noChange", "msg", "service converged, no change")
		return successRes
	}

	toWrite := svcRo.DeepCopy()
	if !reflect.DeepEqual(toWrite.Status, svc.Status) {
		toWrite.Status = svc.Status
	}

	if !reflect.DeepEqual(toWrite.Annotations, svc.Annotations) {
		toWrite.Annotatins = svc.Annotations
	}

	if err := c.client.UpdateStatus(svc); err != nil {
		level.Error(l).Log("op", "updateServiceStatus", "error", err, "msg", "failed to update service")
		return controllers.SyncStateError
	}

In theory, the only two things convergeBalancer is supposed to change are the annotations and the status.
We can be even more cautious and call updateStatus when at least one of the two changes

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No sorry, Your suggestions make sense.

Agree with you, and do we also need a flag to decide UpdateStatus? When annotations or status changed.

when we have multiple configurations tied to the ipaddresspool, it'd be useful to see which pool was used to assign the ip to a given service. You can see it by looking service's annotation "metallb.universe.tf/ip-allocated-from-pool".

Signed-off-by: cyclinder <qifeng.guo@daocloud.io>
@fedepaol
Copy link
Member

This looks great, super clean!
LGTM!

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

Successfully merging this pull request may close these issues.

Annotate a service with the pool used to provide its IP
2 participants