status-im
/
consul
mirror of https://github.com/status-im/consul.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
consul/testing/deployer/topology/default_versions.go

14 lines
418 B
Go
Raw Normal View History

testing/deployer: update deployer to use v2 catalog constructs when requested (#19046) This updates the testing/deployer (aka "topology test") framework to conditionally configure and launch catalog constructs using v2 resources. This is controlled via a Version field on the Node construct in a topology.Config. This only functions for a dataplane type and has other restrictions that match the rest of v2 (no peering, no wanfed, no mesh gateways). Like config entries, you can statically provide a set of initial resources to be synced when bringing up the cluster (beyond those that are generated for you such as workloads, services, etc). If you want to author a test that can be freely converted between v1 and v2 then that is possible. If you switch to the multi-port definition on a topology.Service (aka "workload/instance") then that makes v1 ineligible. This also adds a starter set of "on every PR" integration tests for single and multiport under test-integ/catalogv2
2023-11-02 19:25:48 +00:00
// Copyright (c) HashiCorp, Inc.
// SPDX-License-Identifier: BUSL-1.1
// Code generated by update-latest-versions.sh. DO NOT EDIT.
package topology
const (
In-Memory gRPC (#19942) * Implement In-Process gRPC for use by controller caching/indexing This replaces the pipe base listener implementation we were previously using. The new style CAN avoid cloning resources which our controller caching/indexing is taking advantage of to not duplicate resource objects in memory. To maintain safety for controllers and for them to be able to modify data they get back from the cache and the resource service, the client they are presented in their runtime will be wrapped with an autogenerated client which clones request and response messages as they pass through the client. Another sizable change in this PR is to consolidate how server specific gRPC services get registered and managed. Before this was in a bunch of different methods and it was difficult to track down how gRPC services were registered. Now its all in one place. * Fix race in tests * Ensure the resource service is registered to the multiplexed handler for forwarding from client agents * Expose peer streaming on the internal handler
2024-01-12 16:54:07 +00:00
DefaultConsulCEImage = "hashicorp/consul:1.17.0"
DefaultConsulEnterpriseImage = "hashicorp/consul-enterprise:1.17.0-ent"
DefaultEnvoyImage = "envoyproxy/envoy:v1.27.2"
DefaultDataplaneImage = "hashicorp/consul-dataplane:1.3.0"
testing/deployer: update deployer to use v2 catalog constructs when requested (#19046) This updates the testing/deployer (aka "topology test") framework to conditionally configure and launch catalog constructs using v2 resources. This is controlled via a Version field on the Node construct in a topology.Config. This only functions for a dataplane type and has other restrictions that match the rest of v2 (no peering, no wanfed, no mesh gateways). Like config entries, you can statically provide a set of initial resources to be synced when bringing up the cluster (beyond those that are generated for you such as workloads, services, etc). If you want to author a test that can be freely converted between v1 and v2 then that is possible. If you switch to the multi-port definition on a topology.Service (aka "workload/instance") then that makes v1 ineligible. This also adds a starter set of "on every PR" integration tests for single and multiport under test-integ/catalogv2
2023-11-02 19:25:48 +00:00
)