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

62 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: Partitions Application Layer (#11017) * Add Partition to all our models * Add partitions into our serializers/fingerprinting * Make some amends to a few adapters ready for partitions * Amend blueprints to avoid linting error * Update all our repositories to include partitions, also Remove enabled/disable nspace repo and just use a nspace with conditionals * Ensure nspace and parition parameters always return '' no matter what * Ensure data-sink finds the model properly This will later be replaced by a @dataSink decorator but we are find kicking that can down the road a little more * Add all the new partition data layer * Add a way to set the title of the page from inside the route and make it accessibile via a route announcer * Make the Consul Route the default/basic one * Tweak nspace and partition abilities not to check the length * Thread partition through all the components that need it * Some ACL tweaks * Move the entire app to use partitions * Delete all the tests we no longer need * Update some Unit tests to use partition * Fix up KV title tests * Fix up a few more acceptance tests * Fixup and temporarily ignore some acceptance tests * Stop using ember-cli-page-objects fillable as it doesn't seem to work * Fix lint error * Remove old ACL related test * Add a tick after filling out forms * Fix token warning modal * Found some more places where we need a partition var * Fixup some more acceptance tests * Tokens still needs a repo service for CRUD * Remove acceptance tests we no longer need * Fixup and "FIXME ignore" a few tests * Remove an s * Disable blocking queries for KV to revert to previous release for now * Fixup adapter tests to follow async/function resolving interface * Fixup all the serializer integration tests * Fixup service/repo integration tests * Fixup deleting acceptance test * Fixup some ent tests * Make sure nspaces passes the dc through for when thats important * ...aaaand acceptance nspaces with the extra dc param
2021-09-15 18:50:11 +00:00
# FIXME: Does 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