EndpointSliceCache was using the name "endpointInfo" to refer to two
different data types (most egregiously in addEndpoints(), which had a
variable named `endpoint` of type `*endpointInfo` and a variable named
`endpointInfo` of type `Endpoint`).
Continue using "endpointInfo" in places that refer to proxy.Endpoint /
BaseEndpointInfo, since that's consistent with other code, but rename
the local "cache of the Endpoints field of an EndpointSlice" type from
"endpointInfo" to "endpointData". Likewise, rename endpointSliceInfo
to endpointSliceData, for consistency.
Put the ServiceChangeTracker and EndpointsChangeTracker definitions at
the top of the files, and put the ServicePortMap and EndpointsMap
definitions before their methods.
(No code changes.)
Move the ServicePort/BaseServicePortInfo types to serviceport.go.
Move the Endpoint/BaseEndpointInfo types to endpoint.go.
To avoid confusion with the new filenames, rename service.go to
servicechangetracker.go and endpoints.go to endpointschangetracker.go.
(No code changes; this just moves some code from types.go and
services.go to serviceport.go, and some code from types.go and
endpoints.go to endpoint.go.)
(This would become an error rather than a warning once we try to move
this code to another file.)
Also rename an "ok" variable to "exists" since that what it really
means.
ServicePortMap.merge had a giant comment explaining its return value,
but nothing ever used that return value.
ServicePort had an InternalTrafficPolicy() method, but nothing used it
(because it was redundant with InternalPolicyLocal().)
The length of `finalInterceptors` will always be a
non-zero value. In that case, the comparison will
always return a True value, making the comparison
meaningless.
Signed-off-by: fazledyn-or <ataf@openrefactory.com>
Bumping tools to include the fix for a nil pointer
deref error in go/types. See golang/go#64812
for more details.
This fix is needed for when we bump to go1.22.
Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
ServicePortMap.Update() and EndpointsMap.Update() were just a tiny
wrappers around the corresponding apply() methods, which had no other
callers. So squash them together.
(Also fix the variable naming in ServicePortMap.Update() to match
other methods.)
When users of `applyconfiguration-gen` use any of the `metav1` types in
their own types, they expect to have correct apply configurations
generated without having to explicitly pass anything to the tool. In the
same way that we used to include `metav1.ObjectMeta` and
`metav1.TypeMeta`, we now include all of the `metav1` types that have
apply-configurations generated for them in `client-go`. There's no
downside to loading these types, so there's no reason to omit any.
Signed-off-by: Steve Kuznetsov <skuznets@redhat.com>
