status-im
/
consul
mirror of https://github.com/status-im/consul.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
consul/ui/packages/consul-ui/tests/acceptance/dc/services/show-routing.feature

70 lines
2.1 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
ui: chore upgrade to ember-qunit v5 (#14430) * Refactor remaining `moduleFor`-tests `moduleFor*` will be removed from ember-qunit v5 * Upgrade ember-qunit to v5 * Update how we use ember-sinon-qunit With ember-qunit v5 we need to use ember-sinon-qunit differently. * Fix submit-blank test We can't click on disabled buttons with new test-helpers. We need to adapt the test accordingly. * Make sure we await fill-in with form yaml step We need to await `fill-in`. This changes the reducer function in the step to create a proper await chain. * Fix show-routing test We need to await a tick before visiting again. * Remove redundant `wait one tick`-step * remove unneeded "next Tick" promise from form step * Increase timeout show-routing feature * Comment on pause hack for show-routing test
2022-09-01 15:37:37 +00:00
# something weird is going on with this test
# without waiting we issue a url reload that
# will make the test timeout.
# waiting will "fix" this - we should look into
# the underlying reason for this soon. This is
# only a quick-fix to land ember-qunit v5.
And pause for 1000
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
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