-
Task
-
Resolution: Done
-
Critical
-
OSSM 2.1.0
-
5
-
False
-
None
-
False
-
undefined
-
Test case doc - Scope failover
https://github.com/openshift/openshift-docs/pull/34035#discussion_r682650535
failover can be configured by using importAsLocal and locality settings in ServiceImportSet and configuring a DestinationRule that configures failover for the service to the locality specified in the ServiceImportSet.
Capturing a conversation from slack 8/16
Rob Cernich - I commented on the PR. I think we need some input from @Jamie Longmuir as to whether or not we want to officially support this. I think it will come down to whether or not we think we can test this in time for the 2.1 release. The code is there to support it, as I mentioned in the comment, but whether or not we can get it documented and tested is something else.
Julie Stickler - Which is why I commented it out rather than deleted it. Easy enough to restore once we figure that out. But I didn't want to hold up merging this PR while we figure that out.
Rob Cernich - sounds good
Jamie Longmuir - I think we should support the failover feature if you feel comfortable with supporting customers on it @rcernich. If not, we'll need to find a way to make it supported fairly shortly after. I think a lot of people will be looking for it.
Rob Cernich - my biggest concern is that we'll need to do some testing around it and will need to document how to make it happen
Jamie Longmuir - Could we call it tech preview and still publish the docs?
Rob Cernich - in order to expedite the release, i was thinking maybe we treat this as a hidden feature (which isn't very concealed) and update the support matrix after the release, once we can add testing/docs
Rob Cernich -i'm okay with that, but if we go that route, we should just call it "supported" and acknowledge that it may not be fully tested
Jamie Longmuir - I just know we're going to get support cases around this if we don't provide some guidance on it... we've been saying some form of HA setup would be possible to multiple customers.
Jamie Longmuir -Wouldn't that make it tech preview though? I don't know that we have a level between tech preview and GA...
Jamie Longmuir -tech preview means we'll take feedback related support cases, but we won't provide any SLA or guarantees on support. If we called it TP, my thinking is we'd look to remove that disclaimer once we've done a bit more testing or helped a customer or two on it.
Jamie Longmuir -If decide to hide the feature, I would still want the use case addressed in the docs - even to say that it's not supported yet, as I think it's something a lot of customers are looking to get from federation...even if it wasn't the original intent. We need an HA story in the docs in the bottom line.
Jamie Longmuir -@jstickler I just want to make sure this one doesn't get lost, as I think this may be the main feature people are looking for from Federation (based on customer conservations). I'm ok if our testing isn't complete and we want to put a "Tech Preview" label beside the feature (we should only be calling it GA if we're comfortable supporting customers with an SLA on it), but I do want to make sure it gets into the docs.
From e-mail 11/17/21
Specifically, the importAsLocal setting on an ImportedServiceSet can be used to create a combined set of endpoints that includes both a local service and remote service. This could be used to create a "take over" type scenario if all of the local endpoints become unavailable.
- documents
-
OSSM-3050 Spike-Research Federation Failover for TP
-
- Closed
-
- is related to
-
OSSM-2617 OSSM Federation failover Doc Update Example yaml contents
-
- Closed
-
- relates to
-
-
- Closed
-
-
-
- Closed
-
- links to
[OSSM-2953] Federation Config - importAsLocal = true (HA/FO, etc)
tianying pan (Inactive)
added a comment - Is it because I don't have permission? I can't add comments
tianying pan (Inactive)
added a comment - Is it because I don't have permission? I can't add comments
Created an OSSM issue in https://issues.redhat.com/browse/OSSM-1211
pantianying Could you add a comment there about the openshift version in your case ?
If you can attach some yaml files about your configurations of
kind: ServiceMeshControlPlane, kind: ImportedServiceSet, and kind: ServiceMeshPeer
that will be helpful.
I will update the how to reproduce section later when I get some testing feedbacks.
Thanks.
@pantianying discussions about changing upstream code definitely don't belong on a Red Hat documentation issue. That discussion probably belongs on GitHub, where the Istio engineering community can see it. (Or Maistra engineers, since this is Federation)
tianying pan (Inactive)
added a comment - Yes. where is a better place for Discussing this problem. I can provide full replay assistance. If both the local and remote clusters have service instances, you will find that the local cluster cannot be invoked. So far I have solved this problem on a temporary basis by modifying the istiod code. https://github.com/pantianying/istio-maistra/commit/4cc12443c4f35a2ddadc4194c7e99d099bb6e717
tianying pan (Inactive)
added a comment - Yes. where is a better place for Discussing this problem. I can provide full replay assistance. If both the local and remote clusters have service instances, you will find that the local cluster cannot be invoked. So far I have solved this problem on a temporary basis by modifying the istiod code. https://github.com/pantianying/istio-maistra/commit/4cc12443c4f35a2ddadc4194c7e99d099bb6e717 According to community Istio slack openshift channel, we haven't checked there for a while. Not sure where is a better place for tracking outside issue reporting.
We may use Jira and create issue(s) under project "OpenShift Service Mesh (OSSM)" instead of this OSSMDOC. The project OSSMDOC is for doc change tasks.
as long as we have a clear reproducer (steps to reproduce an issue) in description. we can follow up and plan the work.
The description of this Jira is not clear. we don't need all those conversation tracks. Or we can attach a text file about those conversations.
The reporter tianying described some steps when set importAsLocal : ‘true’ in two separate federated mesh clusters
envoy connection [C289] TLS error: 337047686:SSL routines:tls_process_server_certificate:certificate verify failed
From our testing, we applied the following and haven't seen an error. will check enovy logs tomorrow.
kind: ImportedServiceSet apiVersion: federation.maistra.io/v1 metadata: name: red-mesh #name of mesh that exported the service namespace: green-mesh-system #mesh namespace that service is being imported into spec: importRules: # first matching rule is used # import ratings.bookinfo as ratings.bookinfo - type: NameSelector importAsLocal: true nameSelector: namespace: bookinfo name: ratings alias: # service will be imported as ratings.bookinfo.svc.red-mesh-imports.local namespace: bookinfo name: ratings #Locality within which imported services should be associated. locality: region: us-west
Flag addedAnd another word I found that the ImportServiceSet. Spec. locality can not effect on the endpoint
Because the code:
https://github.com/maistra/istio/blob/dac125513cda29f5b6d07198dcd08cd664950e4a/pilot/pkg/serviceregistry/federation/controller.go#L132
the 'defaults' are always nil, causing the 'locality' to not be merged to 'merged'
I hope it was helpful
tianying pan (Inactive)
added a comment - - edited ths jlongmui@redhat.com
And another word I found that the ImportServiceSet. Spec. locality can not effect on the endpoint
Because the code:
https://github.com/maistra/istio/blob/dac125513cda29f5b6d07198dcd08cd664950e4a/pilot/pkg/serviceregistry/federation/controller.go#L132
the 'defaults' are always nil, causing the 'locality' to not be merged to 'merged'
I hope it was helpful pantianying There is an OpenShift channel in the community Istio Slack that would probably be best to ask such questions.
Reporter (pantianying) does not have permission to create attachments in project OSSMDOC. Following attachments found in the email have been discarded: