-
Notifications
You must be signed in to change notification settings - Fork 274
(feat/statefulsets): MeshService API changes for Headless Services #4704
(feat/statefulsets): MeshService API changes for Headless Services #4704
Conversation
b13c1a9
to
9be15b3
Compare
161cb93
to
0099ad1
Compare
1ac81e4
to
cb6a880
Compare
e513dc8
to
20e538b
Compare
Codecov Report
@@ Coverage Diff @@
## main #4704 +/- ##
==========================================
+ Coverage 68.55% 69.13% +0.57%
==========================================
Files 228 227 -1
Lines 16289 16316 +27
==========================================
+ Hits 11167 11280 +113
+ Misses 5070 4984 -86
Partials 52 52
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
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.
Thanks for this change. The overall idea looks good, left some comments to enable the reuse of code and readability.
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.
Can we add an E2E test in this PR as well?
582b40c
to
6ea3490
Compare
@steeling An E2E test for all statefulset functionality will be added in subsequent PRs. This PR is only for the MeshService API changes and their downstream effects |
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.
Instead of all the init/partial stuff, if the issue is unexported fields, it's likely a code smell that we're using the wrong data structure, ie: instead of a hashset let's just use a map
As a stepping stone for statefulset support (openservicemesh#3477), introduce a new interface describing the ability to map an entity back to a provider service (e.g. a Kubernetes service). This decouples the MeshService name from being a foreign key between the provider's collection of services and the MeshCatalog's set of services Signed-off-by: Keith Mattix II <keithmattix2@gmail.com>
Signed-off-by: Keith Mattix II <keithmattix2@gmail.com>
Signed-off-by: Keith Mattix II <keithmattix2@gmail.com>
Signed-off-by: Keith Mattix II <keithmattix2@gmail.com>
When retrieving MeshServices in order to create local clusters for a pod, exclude MeshServices whose subdomains don't match the pod's name Signed-off-by: Keith Mattix II <keithmattix2@gmail.com>
Tracking the unexported MeshService fields is difficult, and there are several hidden bugs that can occur depending on what fields are accessed. So, we create the NewMeshService and NewPartialMeshService functions to aid in correct usage Signed-off-by: Keith Mattix II <keithmattix2@gmail.com>
Signed-off-by: Keith Mattix II <keithmattix2@gmail.com>
Signed-off-by: Keith Mattix II <keithmattix2@gmail.com>
Signed-off-by: Keith Mattix II <keithmattix2@gmail.com>
Signed-off-by: Keith Mattix II <keithmattix2@gmail.com>
Signed-off-by: Keith Mattix II <keithmattix2@gmail.com>
Signed-off-by: Keith Mattix II <keithmattix2@gmail.com>
20a60a6
to
c7a568e
Compare
Signed-off-by: Keith Mattix II <keithmattix2@gmail.com>
Signed-off-by: Keith Mattix II <keithmattix2@gmail.com>
Signed-off-by: Keith Mattix II <keithmattix2@gmail.com>
pkg/envoy/registry/services_test.go
Outdated
{ | ||
Addresses: []v1.EndpointAddress{ | ||
{ | ||
IP: "8.8.8.9", |
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 the IPs here aren't relevant to the test, I'd remove them.
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.
The IPs are also used down the callstack in ServiceToMeshServices
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.
More info: #4704 (comment)
Namespace: namespace, | ||
Name: service1Name, | ||
}, | ||
Subsets: []v1.EndpointSubset{ |
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.
Like above, if these aren't headless services, then it seems like Subsets
doesn't matter here.
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.
Ah, I see what you mean now; yes they technically aren't needed. I don't know how I feel about using unrealistic resources in tests though....feels like as soon as that thing needs to be used, things break
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.
My personal rule of thumb is "if I can comment it out and the test still passes, remove it." I find trying to make things as realistic as possible in unit tests is more work than it's worth and makes the tests harder to reason about later. If Subsets
does come into play later for non-headless services, then the tests will almost certainly need to be updated to account for that anyway.
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 get where you're coming from, and I certainly think there's a middle ground there. Spending a ton of time making tests hyper-realistic is wasteful, but at the same time, stripping test resources too far down can lead to unexpected behavior. Personally, I find unrealistic objects harder to reason about (e.g. "what does it mean for an Endpoints resource to have a nil subset"). I actually ran into this quite a bit while developing this feature: headless services are essentially a special case, but because a lot of our test objects don't have ClusterIPs, I had to go update unrelated tests when I built out headless service support. This is the primary reason why I started to add ClusterIPs to most of my test service objects. Basically, I'm just trying to say there's a balance. For this test in particular, I think need to add a headless service anyway for the test, but I did want to chat about the general point for posterity's sake 😄
Signed-off-by: Keith Mattix II <keithmattix2@gmail.com>
Signed-off-by: Keith Mattix II <keithmattix2@gmail.com>
Signed-off-by: Keith Mattix II <keithmattix2@gmail.com>
Signed-off-by: Keith Mattix II <keithmattix2@gmail.com>
Signed-off-by: Keith Mattix II <keithmattix2@gmail.com>
Description:
In order to provide statefulset support, introduce 2 new public
functions to the MeshService type to accomplish the following:
ProviderKey
function describes the mapping from a MeshService back to a providerservice (e.g. a Kubernetes service). This decouples the MeshService name
from being a foreign key between the provider's collection of services
and the MeshCatalog's set of services.
Subdomain
function returns the subdomain for a particular mesh service (e.g. the pod name for a particular pod within a headless service). This allows for proper matching of endpoints when building EDS and CDS responses.Both of these functions rely on a new convention around MeshService.Name in that the name shall be formatted as (
[subdomain.]providerKey
). The values returned by these functions are calculated once and then memoized via unexported fields. TheMeshService.Equals()
function has been updated to account for these unexported fields.Because of the semantics of statefulsets and headless services in Kubernetes, it is important to highlight the following guidance re: headless services:
Signed-off-by: Keith Mattix II keithmattix2@gmail.com
Testing done:
Affected area:
Please answer the following questions with yes/no.
Does this change contain code from or inspired by another project?
Is this a breaking change?
Has documentation corresponding to this change been updated in the osm-docs repo (if applicable)?