open-consul/ui/packages/consul-ui/tests/acceptance/dc/services/show.feature

305 lines
7.6 KiB
Gherkin
Raw Normal View History

@setupApplicationTest
Feature: dc / services / show: Show Service
Scenario: Given a service with an external source, the logo is displayed
Given 1 datacenter model with the value "dc1"
And 1 node models
And 1 service model from yaml
---
- Service:
Kind: ~
Tags: ['Tag1', 'Tag2']
Meta:
external-source: consul
---
When I visit the service page for yaml
---
dc: dc1
service: service-0
---
Then I see externalSource like "consul"
And the title should be "service-0 - Consul"
Scenario: Given a service with an 'unsupported' external source, there is no logo
Given 1 datacenter model with the value "dc1"
And 1 node models
And 1 service model from yaml
---
- Service:
Kind: ~
Tags: ['Tag1', 'Tag2']
Meta:
external-source: 'not-supported'
---
When I visit the service page for yaml
---
dc: dc1
service: service-0
---
Then I don't see externalSource
Scenario: Given various services with various tags, all tags are displayed
Given 1 datacenter model with the value "dc1"
And 3 node models
And 1 service model from yaml
---
- Service:
Kind: ~
Tags: ['Tag1', 'Tag2']
- Service:
Kind: ~
Tags: ['Tag3', 'Tag1']
- Service:
Kind: ~
Tags: ['Tag2', 'Tag3']
---
When I visit the service page for yaml
---
dc: dc1
service: service-0
---
ui: Add tab navigation to the browser history/URLs (#7592) * ui: Add tab navigation to the browser history/URLs This commit changes all our tabbed UI interfaces in the catalog to use actual URL changes rather than only updating the content in the page using CSS. Originally we had decided not to add tab clicks into the browser history for a variety of reasons. As the UI has progressed these tabs are a fairly common pattern we are using and as the UI grows and stabilizes around certain UX patterns we've decided to make these tabs 'URL changing'. Pros: - Deeplinking - Potentially smaller Route files with a more concentrated scope of the contents of a tab rather than the entire page. - Tab clicks now go into your history meaning backwards and forwards buttons take you through the tabs not just the pages. - The majority of our partials are now fully fledged templates (Octane :tada:) Cons: - Tab clicks now go into your history meaning backwards and forwards buttons take you through the tabs not just the pages. (Could be good and bad from a UX perspective) - Many more Route and Controller files (yet as mentioned above each of these have a more reduced scope) - Moving around the contents of these tabs, or changing the visual names of them means updates to the URL structure, which then should potentially entail redirects, therefore what things that seem like straightforwards design reorganizations are now a little more impactful. It was getting to the point that the Pros outweight the Cons Apart from moving some files around we made a few more tiny tweaks to get this all working: - Our freetext-filter component now performs the initial search rather than this happening in the Controller (remove of the search method in the Controllers and the new didInsertElement hook in the component) - All of the <TabNav>'s were changed to use its alternative href approach. - <TabPanel>s usage was mostly removed. This is th thing I dislike the most. I think this needs removing, but I'd also like to remove the HTML it creates. You'll see that every new page is wrappe din the HTML for the old <TabPanel>, this is to continue to use the same HTML structure and id's as before to avoid making further changes to any CSS that might use this and being able to target things during testing. We could have also removed these here, but it would have meant a much larger changeset and can just as easily be done at a later date. - We made a new `tabgroup` page-object component, which is almost identical to the previous `radiogroup` one and injected that instead where needed during testing. * Make sure we pick up indexed routes when nspaces are enabled * Move session invalidation to the child (session) route * Revert back to not using didInsertElement for updating the searching This adds a way for the searchable to remember the last search result instead, which changes less and stick to the previous method of searching.
2020-04-08 09:56:36 +00:00
And I click tags on the tabs
Then I see the text "Tag1" in "[data-test-tags] span:nth-child(1)"
Then I see the text "Tag2" in "[data-test-tags] span:nth-child(2)"
Then I see the text "Tag3" in "[data-test-tags] span:nth-child(3)"
Scenario: Given various services the various nodes on their instances are displayed
Given 1 datacenter model with the value "dc1"
And 3 node models
And 1 service model from yaml
---
- Checks:
- Status: critical
Service:
Kind: ~
ID: passing-service-8080
Port: 8080
Address: 1.1.1.1
Node:
Address: 1.2.2.2
- Checks:
- Status: warning
Service:
Kind: ~
ID: service-8000
Port: 8000
Address: 2.2.2.2
Node:
Address: 2.3.3.3
- Checks:
- Status: passing
Service:
Kind: ~
ID: service-8888
Port: 8888
Address: 3.3.3.3
Node:
Address: 3.4.4.4
---
When I visit the service page for yaml
---
dc: dc1
service: service-0
---
And I click instances on the tabs
Then I see address on the instances like yaml
---
- "1.1.1.1:8080"
- "2.2.2.2:8000"
- "3.3.3.3:8888"
---
Scenario: Given a combination of sources I should see them all on the instances
Given 1 datacenter model with the value "dc1"
And 3 node models
And 1 service model from yaml
---
- Checks:
- Status: critical
Service:
Kind: ~
ID: passing-service-8080
Port: 8080
Address: 1.1.1.1
Meta:
external-source: kubernetes
Node:
Address: 1.2.2.2
Meta:
synthetic-node: false
- Checks:
- Status: passing
Service:
Kind: ~
ID: service-8000
Port: 8000
Address: 2.2.2.2
Meta:
external-source: kubernetes
Node:
Address: 2.3.3.3
Meta:
synthetic-node: false
- Checks:
- Status: passing
Service:
Kind: ~
ID: service-8888
Port: 8888
Address: 3.3.3.3
Meta:
external-source: vault
Node:
Address: 3.4.4.4
Meta:
synthetic-node: false
---
When I visit the service page for yaml
---
dc: dc1
service: service-0
---
And I click instances on the tabs
Then I see externalSource on the instances vertically like yaml
---
- "kubernetes"
- "kubernetes"
- "vault"
---
And I see nodeName on the instances like yaml
---
- "node-0"
- "node-1"
- "node-2"
---
And I see nodeChecks on the instances
Scenario: Given instances share the same external source, only show it at the top
Given 1 datacenter model with the value "dc1"
And 3 node models
And 1 service model from yaml
---
- Checks:
- Status: critical
Service:
Kind: ~
ID: passing-service-8080
Port: 8080
Address: 1.1.1.1
Meta:
external-source: kubernetes
Node:
Address: 1.2.2.2
Meta:
synthetic-node: true
- Checks:
- Status: passing
Service:
Kind: ~
ID: service-8000
Port: 8000
Address: 2.2.2.2
Meta:
external-source: kubernetes
Node:
Address: 2.3.3.3
Meta:
synthetic-node: true
- Checks:
- Status: passing
Service:
Kind: ~
ID: service-8888
Port: 8888
Address: 3.3.3.3
Meta:
external-source: kubernetes
Node:
Address: 3.4.4.4
---
When I visit the service page for yaml
---
dc: dc1
service: service-0
---
And I click instances on the tabs
Then I see externalSource like "kubernetes"
And I don't see externalSource on the instances
Scenario: Given one agentless instance, it should not show node health checks or node name
Given 1 datacenter model with the value "dc1"
And 1 node models
And 1 service model from yaml
---
- Checks:
- Status: critical
Service:
Kind: ~
ID: passing-service-8080
Port: 8080
Address: 1.1.1.1
Meta:
external-source: kubernetes
Node:
Address: 1.2.2.2
Meta:
synthetic-node: true
---
When I visit the service page for yaml
---
dc: dc1
service: service-0
---
And I click instances on the tabs
And I don't see nodeChecks on the instances
And I don't see nodeName on the instances
Scenario: Given a dashboard template has been set
Given 1 datacenter model with the value "dc1"
And ui_config from yaml
---
dashboard_url_templates:
service: https://something.com?{{Service.Name}}&{{Datacenter}}
---
When I visit the service page for yaml
---
dc: dc1
service: service-0
---
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
# The external dashboard link should use the Service.Name not the ID
And I see href on the dashboardAnchor like "https://something.com?service-0&dc1"
Scenario: With no access to service
Given 1 datacenter model with the value "dc1"
And permissions from yaml
---
service:
read: false
---
When I visit the service page for yaml
---
dc: dc1
service: service-0
---
Then I see status on the error like "403"
Scenario: When access is removed from a service
Given 1 datacenter model with the value "dc1"
And 1 node models
And 1 service model from yaml
And a network latency of 100
And permissions from yaml
---
service:
read: true
---
When I visit the service page for yaml
---
dc: dc1
service: service-0
---
And I click instances on the tabs
And I see 1 instance model
Given permissions from yaml
---
service:
read: false
---
# authorization requests are not blocking so we just wait until the next
# service blocking query responds
Then pause until I see the text "no longer have access" in "[data-notification]"
And "[data-notification]" has the "error" class
And I see status on the error like "403"