luxolus
/
open-consul
2
0
Fork 0
Code Issues 1 Pull Requests Packages Releases Wiki Activity
open-consul/ui/packages/consul-ui/tests/acceptance/dc/services/show-routing.feature

63 lines
1.8 KiB
Gherkin
Raw Normal View History

ui: Gracefully cope with 500 errors from the disco-chain API endpoint (#7291) When connect is disabled the discovery-chain endpoint returns a 500 error status, which we previoulsy did not gracefully cope with. This commit gracefully copes with any errors from the disco-chain endpoint by supressing the error and hiding the Routing tab from the Service detail page. Acceptance test included
2020-02-14 14:46:17 +00:00
@setupApplicationTest
ui: Test Improvements (#7854) * ui: Combine all "see/don't see" steps into one step * Fix up broken tests * Add some test meta data/titles * Test out proxies in the service listing * Remove comments
2020-05-12 15:37:22 +00:00
Feature: dc / services / show-routing: Show Routing for Service
ui: Gracefully cope with 500 errors from the disco-chain API endpoint (#7291) When connect is disabled the discovery-chain endpoint returns a 500 error status, which we previoulsy did not gracefully cope with. This commit gracefully copes with any errors from the disco-chain endpoint by supressing the error and hiding the Routing tab from the Service detail page. Acceptance test included
2020-02-14 14:46:17 +00:00
Scenario: Given a service, the Routing tab should display
Given 1 datacenter model with the value "dc1"
And 1 node models
And 1 service model from yaml
---
- Service:
Name: service-0
ID: service-0-with-id
---
When I visit the service page for yaml
---
dc: dc1
service: service-0
---
And the title should be "service-0 - Consul"
And I see routing on the tabs
Scenario: Given connect is disabled, the Routing tab should not display or error
ui: Reduce discovery-chain log errors (#8065) * ui: Reduce discovery-chain log spam Currently the only way that the UI can know whether connect is enabled or not is whether we get 500 errors from certain endpoints. One of these endpoints we already use, so aswell as recovering from a 500 error, we also remember that connect is disabled for the rest of the page 'session' (so until the page is refreshed), and make no further http requests to the endpoint for that specific datacenter. This means that log spam is reduced to only 1 log per page refresh/dc instead of 1 log per service navigation. Longer term we'll need some way to dynamically discover whether connect is enabled per datacenter without relying on something that will add error logs to consul.
2020-06-10 15:07:06 +00:00
Given 2 datacenter models from yaml
---
- dc1
- dc2
---
ui: Gracefully cope with 500 errors from the disco-chain API endpoint (#7291) When connect is disabled the discovery-chain endpoint returns a 500 error status, which we previoulsy did not gracefully cope with. This commit gracefully copes with any errors from the disco-chain endpoint by supressing the error and hiding the Routing tab from the Service detail page. Acceptance test included
2020-02-14 14:46:17 +00:00
And 1 node models
ui: Reduce discovery-chain log errors (#8065) * ui: Reduce discovery-chain log spam Currently the only way that the UI can know whether connect is enabled or not is whether we get 500 errors from certain endpoints. One of these endpoints we already use, so aswell as recovering from a 500 error, we also remember that connect is disabled for the rest of the page 'session' (so until the page is refreshed), and make no further http requests to the endpoint for that specific datacenter. This means that log spam is reduced to only 1 log per page refresh/dc instead of 1 log per service navigation. Longer term we'll need some way to dynamically discover whether connect is enabled per datacenter without relying on something that will add error logs to consul.
2020-06-10 15:07:06 +00:00
And 2 service model from yaml
ui: Gracefully cope with 500 errors from the disco-chain API endpoint (#7291) When connect is disabled the discovery-chain endpoint returns a 500 error status, which we previoulsy did not gracefully cope with. This commit gracefully copes with any errors from the disco-chain endpoint by supressing the error and hiding the Routing tab from the Service detail page. Acceptance test included
2020-02-14 14:46:17 +00:00
---
- Service:
Name: service-0
ID: service-0-with-id
ui: Reduce discovery-chain log errors (#8065) * ui: Reduce discovery-chain log spam Currently the only way that the UI can know whether connect is enabled or not is whether we get 500 errors from certain endpoints. One of these endpoints we already use, so aswell as recovering from a 500 error, we also remember that connect is disabled for the rest of the page 'session' (so until the page is refreshed), and make no further http requests to the endpoint for that specific datacenter. This means that log spam is reduced to only 1 log per page refresh/dc instead of 1 log per service navigation. Longer term we'll need some way to dynamically discover whether connect is enabled per datacenter without relying on something that will add error logs to consul.
2020-06-10 15:07:06 +00:00
- Service:
Name: service-1
ID: service-1-with-id
ui: Gracefully cope with 500 errors from the disco-chain API endpoint (#7291) When connect is disabled the discovery-chain endpoint returns a 500 error status, which we previoulsy did not gracefully cope with. This commit gracefully copes with any errors from the disco-chain endpoint by supressing the error and hiding the Routing tab from the Service detail page. Acceptance test included
2020-02-14 14:46:17 +00:00
---
And the url "/v1/discovery-chain/service-0?dc=dc1&ns=@namespace" responds with from yaml
---
status: 500
body: "Connect must be enabled in order to use this endpoint"
---
When I visit the service page for yaml
---
dc: dc1
service: service-0
---
And I don't see routing on the tabs
And I don't see the "[data-test-error]" element
ui: Ensure dc selector correctly shows the currently selected dc (#11380) * ui: Ensure dc selector correctly shows the currently selected dc * ui: Restrict access to non-default partitions in non-primaries (#11420) This PR restricts access via the UI to only the default partition when in a non-primary datacenter i.e. you can only have multiple (non-default) partitions in the primary datacenter.
2021-10-26 18:26:04 +00:00
# Not entirely sure if having one dc not having connect
# and another having connect ever actually happen
And I visit the service page for yaml
---
dc: dc2
service: service-1
---
And I see routing on the tabs
And I visit the service page for yaml
---
dc: dc1
service: service-0
---
Then a GET request wasn't made to "/v1/discovery-chain/service-0?dc=dc1&ns=@namespace"
And I don't see routing on the tabs
And I don't see the "[data-test-error]" element