Support upgrade Zowe in HA by loadbalancers
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 92
- Forks
- 81
- Avg merge
- 1d 9h
- Merged PRs (30d)
- 46
Description
Is your feature request related to a problem? Please describe.
This issue is a suggestion on how to improve the current API Gateway and Spring Cloud Gateway to support the required operation during upgrading Zowe. It should guarantee the proper state of routing during the upgrade process.
The upgrade process required to create of a new filesystem with a new installation and switching the load between instances by controlling DVIPA (for more information please read the document written in PR https://github.com/zowe/docs-site/pull/3053).
All steps are required to refresh the discovery services state and spread the registry between each instance (for this case especially between GWs). It solves the HA, but it also makes it more complicated to replace old services with new ones at one moment.
In the middle of the process, there are two running instances: A - old one, B - new one. In the beginning, A is available through the DVIPA, and B is suspended. The next step is to switch DVIPA to make instance B available. Both those states have the same issue. The user is accessing a specific GW (that is correct), but the Gateway is routing between all known instances (it contains for example API catalog on both A and B).
Therefore even sysadmin control DVIPA it is not possible to ensure which version is accessible at the moment. Breaking changes could make this state very random. There is also the assumption that the UI is not working well if multiple versions are available at the same moment (see assets with random names).
Basically, the issue is that we are using two load balancers (DVIPA and GW/SCGW) and control just one of them.
Describe the solution you'd like
To fix the upgrading process is necessary to control the load balancer on each API Gateway and Spring Cloud Gateway service. There should be an available REST endpoint that allows to control load balancer. There are a couple of ways how to support it:
- to allow routing just on a specific hostname and port (service ID is not necessary), or using instanceId
- to disable routing on specific hostname and port, or using instanceId
- remove strict routing rules
- list of set routes (required to verify state before switching traffic load)
Describe alternatives you've considered
There is also possible to stop sending heartbeats by a specific service or change the list of discovery services in the configuration. Anyway, it requires some other steps to achieve a similar job.
Additional context
It is possible to override methods like com.netflix.discovery.DiscoveryClient#getInstance* in org.zowe.apiml.gateway.discovery.ApimlDiscoveryClient
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Read the upgrade and routing discussion in docs-site PR 3053, then inspect org.zowe.apiml.gateway.discovery.ApimlDiscoveryClient and the referenced Netflix DiscoveryClient methods. Define how a REST endpoint would control or list routes for a hostname, port, or instanceId, and consider how its result would verify traffic state during DVIPA switching.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, spring
- Domain
- api, backend, distributed-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100