consul/proto
Chris S. Kim f07132dacc
Revise possible states for a peering. (#13661)
These changes are primarily for Consul's UI, where we want to be more
specific about the state a peering is in.

- The "initial" state was renamed to pending, and no longer applies to
  peerings being established from a peering token.

- Upon request to establish a peering from a peering token, peerings
  will be set as "establishing". This will help distinguish between the
  two roles: the cluster that generates the peering token and the
  cluster that establishes the peering.

- When marked for deletion, peering state will be set to "deleting".
  This way the UI determines the deletion via the state rather than the
  "DeletedAt" field.

Co-authored-by: freddygv <freddy@hashicorp.com>
2022-07-04 10:47:58 -04:00
..
pbacl Specify go_package explicitly 2022-05-24 10:22:53 -07:00
pbautoconf Specify go_package explicitly 2022-05-24 10:22:53 -07:00
pbcommon Specify go_package explicitly 2022-05-24 10:22:53 -07:00
pbconfig Specify go_package explicitly 2022-05-24 10:22:53 -07:00
pbconfigentry proxycfg: server-local intentions data source 2022-07-04 10:48:36 +01:00
pbconnect xds: mesh gateways now have their own leaf certificate when involved in a peering (#13460) 2022-06-15 14:36:18 -05:00
pbpeering Revise possible states for a peering. (#13661) 2022-07-04 10:47:58 -04:00
pbservice xds: mesh gateways now have their own leaf certificate when involved in a peering (#13460) 2022-06-15 14:36:18 -05:00
pbstatus Specify go_package explicitly 2022-05-24 10:22:53 -07:00
pbsubscribe proxycfg: server-local intentions data source 2022-07-04 10:48:36 +01:00
prototest Update public listener with SPIFFE Validator 2022-06-01 17:06:33 -06:00
buf.gen.yaml
buf.yaml