diff --git a/docs/troubleshoot/troubleshoot-apiml-error-codes.md b/docs/troubleshoot/troubleshoot-apiml-error-codes.md index 47abe404ee..930a93154a 100644 --- a/docs/troubleshoot/troubleshoot-apiml-error-codes.md +++ b/docs/troubleshoot/troubleshoot-apiml-error-codes.md @@ -531,19 +531,19 @@ The following error message codes may appear on logs or API responses. Use the f ### ZWEAT500E - Failed to parse the client certificate forwarded from the central Gateway. Error message %s. The client certificate was %s + Failed to parse the client certificate forwarded from the Gateway. Hostname is %s. Error message is %s. The client certificate was %s **Reason:** - The string sent by the central Gateway was not recognized as a valid DER-encoded certificate in the Base64 printable form. + The string sent by the Gateway was not recognized as a valid DER-encoded certificate in the Base64 printable form. **Action:** - Ensure that forwarding of the client certificate is also enabled in the central Gateway. Check for any error messages from the central Gateway. + Ensure that forwarding of the client certificate is also enabled in the Gateway. Check for any error messages from the Gateway. ### ZWEAT501E - Failed to get trusted certificates from the central Gateway. Unexpected response from %s endpoint. Status code: %s. Response body: %s + Failed to get trusted certificates from the Gateway. Unexpected response from %s endpoint. Status code: %s. Response body: %s **Reason:** @@ -551,15 +551,15 @@ The following error message codes may appear on logs or API responses. Use the f **Action:** - Ensure that the parameter apiml.security.x509.certificatesUrls is correctly configured with the complete URL to the central Gateway certificates endpoint. Test the URL manually. + Ensure that the parameter apiml.security.x509.certificatesUrls is correctly configured with the complete URL to the Gateway certificates endpoint. Test the URL manually. ### ZWEAT502E - Invalid URL specified to get trusted certificates from the central Gateway. Error message: %s + Invalid URL specified to get trusted certificates from the Gateway. URL is %s. Error message: %s **Reason:** - The parameter apiml.security.x509.certificatesUrls is not correctly configured with the complete URL to the central Gateway certificates endpoint. + The parameter apiml.security.x509.certificatesUrls is not correctly configured with the complete URL to the Gateway certificates endpoint. **Action:** @@ -567,7 +567,7 @@ The following error message codes may appear on logs or API responses. Use the f ### ZWEAT503E - An error occurred during retrieval of trusted certificates from the central Gateway. Error message: %s + An error occurred during retrieval of trusted certificates from the Gateway. Certificate endpoint is %s. Error message: %s **Reason:** @@ -579,28 +579,16 @@ The following error message codes may appear on logs or API responses. Use the f ### ZWEAT504E - Failed to parse the trusted certificates provided by the central Gateway. Error message %s + Failed to parse the trusted certificates provided by the Gateway. Certificate endpoint is %s. Error message %s **Reason:** - The string sent by the central Gateway was not recognized as valid DER-encoded certificates in the Base64 printable form. + The string sent by the Gateway was not recognized as valid DER-encoded certificates in the Base64 printable form. **Action:** Check that the URL configured in apiml.security.x509.certificatesUrls responds with valid DER-encoded certificates in the Base64 printable form. -### ZWEAT505E - - Incoming request certificate is not one of the trusted certificates provided by the central Gateway. - - **Reason:** - - The Gateway performs an additional check of request certificates when the central Gateway forwards the incoming client certificate to the domain Gateway. This check may fail when the certificatesUrl parameter does not point to the proper central Gateway certificates endpoint. - - **Action:** - - Check that the URL configured in apiml.security.x509.certificatesUrls points to the central Gateway and it responds with valid DER-encoded certificates in the Base64 printable form. - ### ZWEAT601E z/OSMF service name not found. Set parameter apiml.security.auth.zosmf.serviceId to your service ID. diff --git a/docs/user-guide/api-mediation/api-mediation-multi-tenancy.md b/docs/user-guide/api-mediation/api-mediation-multi-tenancy.md index ca49565eae..b86b83fe66 100644 --- a/docs/user-guide/api-mediation/api-mediation-multi-tenancy.md +++ b/docs/user-guide/api-mediation/api-mediation-multi-tenancy.md @@ -2,52 +2,52 @@ Zowe supports management of multiple tenants, whereby different tenants can serve different purposes or different customers. The use case for multi-tenant support is when a service provider manages sysplexes/monoplexes for multiple customers. This configuration makes it possible to have a single access point for all customers, and properly route and authenticate across different domains. -* [Overview of Central and Domain API MLs](#overview-of-central-and-domain-api-mls) -* [Multitenancy component enablement settings](#multitenancy-component-enablement-settings) -* [Onboarding a Domain Gateway service to the Central Discovery service](#onboarding-a-domain-gateway-service-to-the-central-discovery-service) - * [Dynamic configuration via zowe.yaml](#dynamic-configuration-via-zoweyaml) - * [Dynamic configuration via Environment variables](#dynamic-configuration-via-environment-variables) - * [Validating successful configuration](#validating-successful-configuration) -* [Establishing a trust relationship between Domain API ML and Central API ML](#establishing-a-trust-relationship-between-domain-api-ml-and-central-api-ml) - * [Commands to establish trust between Domain and Central API MLs](#commands-to-establish-trust-between-domain-and-central-api-mls) -* [Using the `/registry` endpoint in the Central Gateway](#using-the-registry-endpoint-in-the-central-gateway) - * [Configuration for `/registry`](#configuration-for-registry) - * [Authentication for `/registry`](#authentication-for-registry) - * [Authorization with `/registry`](#authorization-with-registry) - * [Requests with `/registry`](#requests-with-registry) - * [Response with `/registry`](#response-with-registry) - * [Response with `/registry{apimlId}`](#response-with-registryapimlid) - * [Response with `GET /gateway/api/v1/registry/{apimlId}?apiId={apiId}&serviceId={serviceId}`](#response-with-get-gatewayapiv1registryapimlidapiidapiidserviceidserviceid) -* [Validating successful configuration with `/registry`](#validating-successful-configuration-with-registry) -* [Troubleshooting multitenancy configuration](#troubleshooting-multitenancy-configuration) - * [ZWESG100W](#zwesg100w) - * [No debug messages similar to apiml1 completed with onComplete are produced](#no-debug-messages-similar-to-apiml1-completed-with-oncomplete-are-produced) - -## Overview of Central and Domain API MLs - -The following diagram illustrates communication between the "central" API Mediation Layer and Zowe in multiple domains. Note that some API MLs may be running in a sysplex (HA), while others may be in a monoplex (non-HA). - -![Multi-domain architecture diagram](./diagrams/multi-domain_architecture_V2.svg) - -Domain-Central is where the "central" API ML is running, and may be on z/OS, or off z/OS, for example in Kubernetes. This API ML is referred to as the Central API ML. -The Central API ML serves as a single point of access to all API Mediation Layers registered in this Central API ML and, by extension, to all services registered in those secondary API MLs. - -Domain-1 to Domain-N are z/OS systems with the standard Zowe API ML running either in HA (sysplex) or non-HA (monoplex). These API MLs are referred to as Domain API MLs. +- [Multitenancy Configuration](#multitenancy-configuration) + - [Overview of API MLs](#overview-of-api-mls) + - [Multitenancy component enablement settings](#multitenancy-component-enablement-settings) + - [Onboarding a Gateway service in one domain to the Discovery service of API ML in another domain](#onboarding-a-gateway-service-in-one-domain-to-the-discovery-service-of-api-ml-in-another-domain) + - [Dynamic configuration via zowe.yaml](#dynamic-configuration-via-zoweyaml) + - [Dynamic configuration via Environment variables](#dynamic-configuration-via-environment-variables) + - [Validating successful configuration](#validating-successful-configuration) + - [Establishing a trust relationship between the API MLs](#establishing-a-trust-relationship-between-the-api-mls) + - [Commands to establish trust between the API MLs](#commands-to-establish-trust-between-the-api-mls) + - [Using the `/registry` endpoint in the Gateway](#using-the-registry-endpoint-in-the-gateway) + - [Configuration for `/registry`](#configuration-for-registry) + - [Authentication for `/registry`](#authentication-for-registry) + - [Authorization with `/registry`](#authorization-with-registry) + - [Requests with `/registry`](#requests-with-registry) + - [Response with `/registry`](#response-with-registry) + - [Response with `/registry{apimlId}`](#response-with-registryapimlid) + - [Response with `GET /gateway/api/v1/registry/{apimlId}?apiId={apiId}&serviceId={serviceId}`](#response-with-get-gatewayapiv1registryapimlidapiidapiidserviceidserviceid) + - [Validating successful configuration with `/registry`](#validating-successful-configuration-with-registry) + - [Troubleshooting multitenancy configuration](#troubleshooting-multitenancy-configuration) + - [ZWESG100W](#zwesg100w) + (#no-debug-messages-similar-to-apiml1-completed-with-oncomplete-are-produced) + +## Overview of API MLs + +The following diagram illustrates communication between the API Mediation Layers and Zowe in multiple domains. Note that some API MLs may be running in a sysplex (HA), while others may be in a monoplex (non-HA). + +![Multi-domain architecture diagram](./diagrams/multi-domain_architecture_V3.svg) + + As represented in the example diagram of Multitenacy environement where the APIMLs in Domain(2-N) are registered to APIML in Domain-1. The APIML in Domain-1 may be running on z/OS, or off z/OS, for example in Kubernetes, this API ML serves as a single point of access to all API Mediation Layers registered in this and, by extension, to all services registered in those API MLs. + +The APIMLs in Domain(2-N) are installed on z/OS systems with the standard Zowe API ML running either in HA (sysplex) or non-HA (monoplex). These API MLs are registered to APIML in Domain-1. ## Multitenancy component enablement settings -In the multitenancy environment, certain Zowe components may be enabled, while others may be disabled. The multitenancy environment expects one Central API ML that handles the discovery and registration as well as routing to the API ML installed in specific domains. +In the multitenancy environment, certain Zowe components may be enabled, while others may be disabled. The multitenancy environment expects one API ML (APIML in Domain-1 in our example diagram) that handles the discovery and registration as well as routing to the other API MLs (APIMLs in Domain(2-N) in our example diagram) installed in any other specific domains. -## Onboarding a Domain Gateway service to the Central Discovery service +## Onboarding a Gateway service in one domain to the Discovery service of API ML in another domain -The Central API ML can onboard Gateways of all domains. This service onboarding can be achieved similar to additional registrations of the Gateway. This section describes the dynamic configuration of the yaml file and environment variables, and how to validate successful configuration. +A Gateway from any domain can onboard Gateways of any domains. This service onboarding can be achieved similar to additional registrations of the Gateway. This section describes the dynamic configuration of the yaml file and environment variables, and how to validate successful configuration. - [Dynamic configuration via zowe.yaml](#dynamic-configuration-via-zoweyaml) - [Dynamic configuration via Environment variables](#dynamic-configuration-via-environment-variables) ### Dynamic configuration via zowe.yaml -1. Set the following property for the Domain Gateway to dynamically onboard to the Central Discovery service. +1. Set the following property for the Gateway of APIMLs in Domain(2-N) to dynamically onboard to the Discovery service of API ML in Domain-1. `components.gateway.apiml.service.additionalRegistration` @@ -56,8 +56,8 @@ The Central API ML can onboard Gateways of all domains. This service onboarding **Example:** ``` components.gateway.apiml.service.additionalRegistration: - # central API ML (in HA, for non-HA mode use only 1 hostname) - - discoveryServiceUrls: https://sys1: {discoveryServicePort}/eureka/,https://sys2: {discoveryServicePort}/eureka/ + # APIML in Domain-1 (in HA, for non-HA mode use only 1 hostname) + - discoveryServiceUrls: https://sys1:{discoveryServicePort}/eureka/,https://sys2:{discoveryServicePort}/eureka/ ``` :::note Notes: @@ -71,13 +71,13 @@ The Central API ML can onboard Gateways of all domains. This service onboarding ::: 2. (Optional) Configure the Gateway to forward client certificates. -Use this step to enable the domain gateway to use this client certificate for authentication. . -Set the `certificatesUrl` property to ensure that only Gateway-forwarded certificates are used for client certificate authentication. This URL returns a certificate chain from the central gateway. +Use this step to enable the domain(2-N) gateway to use this client certificate for authentication. . +Set the `certificatesUrl` property to ensure that only Gateway-forwarded certificates are used for client certificate authentication. This URL returns a certificate chain from the gateway. ``` components.gateway.apiml.security.x509: - # central gateway port - certificatesUrl: https://{centralGatewayHost}:{centralGatewayPort}/gateway/certificates + # gateway port in domain-1 + certificatesUrl: https://{gatewayHost}:{gatewayPort}/gateway/certificates ``` ### Dynamic configuration via Environment variables @@ -107,45 +107,45 @@ This Zowe configuration transforms the zowe.yaml configuration file into the env ### Validating successful configuration -The corresponding Gateway service should appear in the Eureka console of the Central Discovery service. +The corresponding Gateway service in domain(2-N) should appear in the Eureka console of the Discovery service in the domain-1 API ML. -To see details of all instances of the ‘GATEWAY’ application, perform a **GET** call on the following endpoint of the Central Discovery service: +To see details of all instances of the ‘GATEWAY’ application, perform a **GET** call on the following endpoint of the Discovery service in domain-1 API ML: ``` /eureka/apps ``` -## Establishing a trust relationship between Domain API ML and Central API ML +## Establishing a trust relationship between the API MLs -For routing to work in a multitenancy configuration, the Central API Mediation Layer must trust the Domain API Mediation Layers for successful registration into the Discovery Service component. -The Domain API Mediation Layers must trust the Central API Mediation Layer Gateway to accept routed requests. -It is necessary that the root and, if applicable, intermediate public certificates be shared between the Central API Mediation Layer and Domain API Mediation Layers. +For routing to work in a multitenancy configuration, as represented in the example diagram above where "Domain APIML 2", "Domain APIML 3" are registered to "Domain APIML 1", the "Domain APIML 1" must trust the "Domain APIML 2", "Domain APIML 3" for successful registration into it's Discovery Service component. +The "Domain APIML 2", "Domain APIML 3" must trust the "Domain APIML 1" Gateway where they are registered to, to accept routed requests. +It is necessary that the root and, if applicable, intermediate public certificates be shared between these domain API Mediation Layers. -The following diagram shows the relationship between the Central API ML and Domain API MLs. +The following diagram shows the relationship between the API MLs. ![Trust relation diagram](./diagrams/mt-trust-relations.png) -As presented in this example diagram, the Central API ML is installed on system X. Domain API MLs are installed on systems Y and Z. +As presented in this example diagram, The API MLs are installed on systems X, Y and Z. -To establish secure communications, "Domain APIML 1" and "Domain APIML 2" are using different private keys signed with different public keys. These API MLs do not trust each other. +To establish secure communications, "Domain APIML 2" and "Domain APIML 3" are using different private keys signed with different public keys. These API MLs do not trust each other. -In order for all Domain API MLs to register with the Central API ML, it is necessary that the Central API ML have all public keys from the certificate chains of all Domain API MLs: +In order for all API MLs to register with an "Domain APIML 1" in multitenancy set up, it is necessary that the "Domain APIML 1" has all public keys from the certificate chains of all registered API MLs: * DigiCert Root CA * DigiCert Root CA1 * DigiCert CA -These public keys are required for the Central API ML to establish trust with "Domain APIML 1" and "Domain APIML 2". +These public keys are required for the "Domain APIML 1" to establish trust with "Domain APIML 2" and "Domain APIML 3". -The Central API ML uses a private key which is signed by the Local CA public key for secure communication. +The "Domain APIML 1" uses a private key which is signed by the Local CA public key for secure communication. -"Domain APIML 1" and "Domain APIML 2" require a Local CA public key in order to accept the routing requests from the Central API ML, otherwise the Central API ML requests will not be trusted by the Domain API MLs. +"Domain APIML 2" and "Domain APIML 3" require a Local CA public key in order to accept the routing requests from the "Domain APIML 1", otherwise the "Domain APIML 1" requests will not be trusted by the registered API MLs. The diagram indicates all of the added certificates inside the red dashed lines. -### Commands to establish trust between Domain and Central API MLs +### Commands to establish trust between the API MLs -The following commands are examples of establishing a trust relationship between a Domain API ML and the Central API ML for both PKCS12 certificates and when using keyrings. +The following commands are examples of establishing a trust relationship between API MLs in Multitenancy Configuration for both PKCS12 certificates and when using keyrings. -1. Import the root and, if applicable, the intermediate public key certificate of Domain API MLs running on systems Y and Z into the truststore of the Central API ML running on system X. +1. Import the root and, if applicable, the intermediate public key certificate of registered "Domain APIML 2" , "Domain APIML 3" API MLs running on systems Y and Z into the truststore of the "Domain APIML 1" running on system X. - **PKCS12** @@ -162,7 +162,7 @@ The following commands are examples of establishing a trust relationship between - **Keyring** - For keyrings, use the following examples of commands specific to your ESM to add certificates from the dataset and connect these certificates to the keyring used by the Central API ML: + For keyrings, use the following examples of commands specific to your ESM to add certificates from the dataset and connect these certificates to the keyring used by the "Domain APIML 1":
Click here for command details for RACF. @@ -227,7 +227,7 @@ The following commands are examples of establishing a trust relationship between ```
-2. Import root and, if applicable, intermediate public key certificates of the Central API ML running on system X into the truststore of the Domain API MLs running on systems Y and Z. +2. Import root and, if applicable, intermediate public key certificates of the API ML running on system X into the truststore of the API MLs running on systems Y and Z. - **PKCS12** @@ -244,7 +244,7 @@ The following commands are examples of establishing a trust relationship between - **Keyring** - For keyring certificates, use the following examples of commands specific to your ESM to add certificates from the dataset, and connect these certificates to the keyrings used by Domain API MLs: + For keyring certificates, use the following examples of commands specific to your ESM to add certificates from the dataset, and connect these certificates to the keyrings used by registered API MLs:
Click here for command details for RACF. @@ -305,11 +305,11 @@ The following commands are examples of establishing a trust relationship between
-You completed certificates setup for multitenancy configuration, whereby Domain API MLs can trust the Central API ML and vice versa. +You completed certificates setup for multitenancy configuration, whereby registered API MLs can trust the API ML where they are registered and vice versa. -## Using the `/registry` endpoint in the Central Gateway +## Using the `/registry` endpoint in the Gateway -The `/registry` endpoint provides information about services onboarded to all Domain Gateways (all domains and the central one). This section describes the configuration, authentication, authorization, example of requests, and responses when using the `/registry` endpoint. +The `/registry` endpoint provides information about services onboarded to all registered Gateways. This section describes the configuration, authentication, authorization, example of requests, and responses when using the `/registry` endpoint. ### Configuration for `/registry` @@ -318,7 +318,7 @@ environment variable `APIML_GATEWAY_REGISTRY_ENABLED=TRUE` to enable this featur ### Authentication for `/registry` -The `/registry` endpoint is authenticated by the client certificate. The Central Gateway accepts certificates that are trusted. The username is obtained from the common name of the client certificate. +The `/registry` endpoint is authenticated by the client certificate. The Gateway accepts certificates that are trusted. The username is obtained from the common name of the client certificate. Unsuccessful authentication returns a 401 error code. @@ -334,16 +334,16 @@ Unsuccessful authorization returns a 403 error code. ### Requests with `/registry` -There are two endpoints that provide information about services registered to the API ML. One endpoint is for all domains, and the other endpoint is for the specific domain. Choose from the following **GET** calls: +There are two endpoints that provide information about services registered to the API ML. One endpoint is for all APIMLs, and the other endpoint is for the specific APIML. Choose from the following **GET** calls: * `GET /gateway/api/v1/registry` -This request lists services in all domains. +This request lists services in all APIMLs. * `GET /gateway/api/v1/registry/{apimlId}` -This request lists services in the apimlId domain. +This request lists services in the APIML of the specific apimlId given. * `GET /gateway/api/v1/registry/{apimlId}?apiId={apiId}&serviceId={serviceId}` - This request gets the specific service in the specific apimlId domain. + This request gets the specific service from the APIML in the specific apimlId. ### Response with `/registry` @@ -404,7 +404,7 @@ This request lists services in the apimlId domain. ### Response with `/registry{apimlId}` -This response should contain information about all services in a specific domain. +This response should contain information about all services in an APIML with the specific apimlId.
Click here for an example response with `/registry{apimlId}`. @@ -449,7 +449,7 @@ This response should contain information about all services in a specific domain ### Response with `GET /gateway/api/v1/registry/{apimlId}?apiId={apiId}&serviceId={serviceId}` -This response should contain information about a specific service in a specific domain. +This response should contain information about a specific service in an APIML with the specific apimlId.
Click here for an example of a response with `GET /gateway/api/v1/registry/{apimlId}?apiId={apiId}&serviceId={serviceId}`. @@ -483,7 +483,7 @@ This response should contain information about a specific service in a specific ## Validating successful configuration with `/registry` -Use the `/registry` endpoint to validate successful configuration. The response should contain all Domain API MLs represented by `apimlId`, and information about onboarded services. +Use the `/registry` endpoint to validate successful configuration. The response should contain all the API MLs represented by `apimlId`, and information about onboarded services. ## Troubleshooting multitenancy configuration @@ -493,15 +493,8 @@ Use the `/registry` endpoint to validate successful configuration. The response Cannot receive information about services on API Gateway with apimlId 'apiml1' because: Received fatal alert: certificate_unknown; nested exception is javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_unknown **Reason** -The trust between the domain and the central Gateway was not established. +Cannot connect to the Gateway service. **Action** -Review your certificate configuration. +Make sure that the external Gateway service is running and the truststore of the both Gateways contains the corresponding certificate. -### No debug messages similar to apiml1 completed with onComplete are produced - - **Reason** - Domain Gateway is not correctly onboarded to Discovery Service in Central API ML. - - **Action** - Review Gateway static definition. Check the Central Discovery Service dashboard if the domain Gateway is displayed. diff --git a/docs/user-guide/api-mediation/configuration-multi-tenancy-routing.md b/docs/user-guide/api-mediation/configuration-multi-tenancy-routing.md index 50e3ba55e2..d65a5418d4 100644 --- a/docs/user-guide/api-mediation/configuration-multi-tenancy-routing.md +++ b/docs/user-guide/api-mediation/configuration-multi-tenancy-routing.md @@ -1,7 +1,7 @@ # Configuring routing in a multi-tenant environment -In addition to the domain-specific Discovery Service, which is typically in the same LPAR, in a multi-sysplex environment, the API Gateway may also need to register with a Central Discovery Service which gathers information about all installed API Gateways -in isolated sysplex environments. Data from the Central Discovery Service can then be used by the Central Gateway for routing to individual API Gateways. +In addition to the domain-specific Discovery Service, which is typically in the same LPAR, in a multi-sysplex environment, where the API Gateway in APIML in one domain lets say "Domain APIML 2", may also need to register with the Discovery Service in API ML in domain any lets say "Domain APIML 1", which gathers information about all installed API Gateways +in isolated sysplex environments. Data from the Discovery Service in the API ML "Domain APIML 1" can then be used by the Gateway in the APIML "Domain APIML 2" for routing to individual API Gateways. Follow these steps to register with additional Discovery Services: @@ -11,7 +11,7 @@ Follow these steps to register with additional Discovery Services: **Example:** ``` components.gateway.apiml.service.additionalRegistration: - + - discoveryServiceUrls: https://sys1:10011/eureka/,https://sys1:10021/eureka/ - discoveryServiceUrls: https://sys2:10011/eureka/,https://sys2:10021/eureka/ diff --git a/docs/user-guide/api-mediation/diagrams/multi-domain_architecture_V3.svg b/docs/user-guide/api-mediation/diagrams/multi-domain_architecture_V3.svg new file mode 100644 index 0000000000..9f5880d49f --- /dev/null +++ b/docs/user-guide/api-mediation/diagrams/multi-domain_architecture_V3.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/whats-new/zowe-v3-frequently-asked-questions.md b/docs/whats-new/zowe-v3-frequently-asked-questions.md index 0247009e96..d7802c8fb2 100644 --- a/docs/whats-new/zowe-v3-frequently-asked-questions.md +++ b/docs/whats-new/zowe-v3-frequently-asked-questions.md @@ -94,7 +94,7 @@ 3. Can you speak about the migration from Zuul to Spring Cloud Gateway? Today there are two separate gateway services in API ML with separate configurations. - Spring Cloud Gateway is replacing Zuul as the technology to provide the API Gateway. The configuration for the API Gateway remains in the `components.gateway` namespace. If you were using Spring Cloud Gateway in V2 for the multi-tenancy scenario, you need to update the configuration for the central gateway and move this configuration from `components.cloud-gateway` to `components.gateway`. + Spring Cloud Gateway is replacing Zuul as the technology to provide the API Gateway. The configuration for the API Gateway remains in the `components.gateway` namespace. If you were using Spring Cloud Gateway in V2 for the multi-tenancy scenario, you need to update the configuration for the Central Gateway (referred as Gateway from v3 onwards) and move this configuration from `components.cloud-gateway` to `components.gateway`. 4. If I have a legacy gateway deployed, how will I migrate to the new gateway? Will the old gateway be removed? diff --git a/versioned_docs/version-v2.18.x/whats-new/zowe-v3-frequently-asked-questions.md b/versioned_docs/version-v2.18.x/whats-new/zowe-v3-frequently-asked-questions.md index 0247009e96..d7802c8fb2 100644 --- a/versioned_docs/version-v2.18.x/whats-new/zowe-v3-frequently-asked-questions.md +++ b/versioned_docs/version-v2.18.x/whats-new/zowe-v3-frequently-asked-questions.md @@ -94,7 +94,7 @@ 3. Can you speak about the migration from Zuul to Spring Cloud Gateway? Today there are two separate gateway services in API ML with separate configurations. - Spring Cloud Gateway is replacing Zuul as the technology to provide the API Gateway. The configuration for the API Gateway remains in the `components.gateway` namespace. If you were using Spring Cloud Gateway in V2 for the multi-tenancy scenario, you need to update the configuration for the central gateway and move this configuration from `components.cloud-gateway` to `components.gateway`. + Spring Cloud Gateway is replacing Zuul as the technology to provide the API Gateway. The configuration for the API Gateway remains in the `components.gateway` namespace. If you were using Spring Cloud Gateway in V2 for the multi-tenancy scenario, you need to update the configuration for the Central Gateway (referred as Gateway from v3 onwards) and move this configuration from `components.cloud-gateway` to `components.gateway`. 4. If I have a legacy gateway deployed, how will I migrate to the new gateway? Will the old gateway be removed?