Implement solo context connect - connects to a deployment and pulls back the RemoteConfig for two cluster deployment

[jeromy-cannon]

• solo context connect --namespace solo-1

  • will attempt to connect to the cluster with the current kubectl context and look for a remote config
  • --namespace solo-1 - the namespace where the remote config is stored

• solo context connect --namespace solo-1 --cluster kind-solo --context kind-solo

  • will attempt to connect to the provided cluster with the provided context and look for a remote config
  • --namespace solo-1 - the namespace where the remote config is stored

• depends on Implement solo context connect - connects to a deployment and pulls back the RemoteConfig for single cluster deployment #755

Feature: 

  Scenario: connects to a two cluster deployment then uses the valid RemoteConfig to pull back the RemoteConfig from the second cluster both are valid and match
    Given Solo is called with `solo context connect --namespace solo-1 --context kind-solo-1 --cluster kind-solo-1`
    When a connection is made to the cluster
    And a RemoteConfig is found
    And the RemoteConfig is valid
    And the RemoteConfig has a second cluster listed in the deployment
    And the LocalConfig has a context mapping for the cluster
    And a connection is made to the 2nd cluster
    And the RemoteConfig is found
    And the RemoteConfig is valid
    And both the RemoteConfigs match
    Then the LocalConfig will be updated with the deployment and cluster/context mappings as needed

  Scenario: connects to a two cluster deployment then uses the valid RemoteConfig to pull back the RemoteConfig from the second cluster and the user will be prompted for the context for the second cluster
    Given Solo is called with `solo context connect --namespace solo-1 --context kind-solo-1 --cluster kind-solo-1`
    When a connection is made to the cluster
    And a RemoteConfig is found
    And the RemoteConfig is valid
    And the RemoteConfig has a second cluster listed in the deployment
    And the LocalConfig does not have a context mapping for the cluster
    Then the user will be prompted for a context to use for the cluster
    And a connection is made to the 2nd cluster ... (see prior scenario)

  Scenario: connects to a two cluster deployment then uses the valid RemoteConfig to pull back the RemoteConfig from the second cluster and the user will be prompted for the context for the but fails
    Given Solo is called with `solo context connect --namespace solo-1 --context kind-solo-1 --cluster kind-solo-1`
    When a connection is made to the cluster
    And a RemoteConfig is found
    And the RemoteConfig is valid
    And the RemoteConfig has a second cluster listed in the deployment
    And the LocalConfig does not have a context mapping for the cluster
    Then the user will be prompted for a context to use for the cluster
    And either the user provided context fails the connection or the user fails to provide a context
    And a SoloError is thrown informing the user to continue to connect to this deployment they will need to setup the Kubernetes context that points to the cluster/namespace and provided them with the cluster and namespace

  Scenario: connects to a two cluster deployment then uses the valid RemoteConfig to pull back the RemoteConfig from the second cluster both are valid but do not match
    Given Solo is called with `solo context connect --namespace solo-1 --context kind-solo-1 --cluster kind-solo-1`
    When a connection is made to the cluster
    And a RemoteConfig is found
    And the RemoteConfig is valid
    And the RemoteConfig has a second cluster listed in the deployment
    And the LocalConfig has a context mapping for the cluster
    And a connection is made to the 2nd cluster
    And the RemoteConfig is found
    And the RemoteConfig is valid
    And both the RemoteConfigs do not match
    Then a SoloError is thrown informing the user of the deployment details with the namespace and cluster/context mappings and telling them that the RemoteConfigs do not match and will have to be manually fixed to synchronize them

  Scenario: connects to a two cluster deployment then uses the valid RemoteConfig to pull back the RemoteConfig from the second cluster where the second is not valid
    Given Solo is called with `solo context connect --namespace solo-1 --context kind-solo-1 --cluster kind-solo-1`
    When a connection is made to the cluster
    And a RemoteConfig is found
    And the RemoteConfig is valid
    And the RemoteConfig has a second cluster listed in the deployment
    And the LocalConfig has a context mapping for the cluster
    And a connection is made to the 2nd cluster
    And the RemoteConfig is found
    And the RemoteConfig is not valid
    Then a SoloError will be thrown informing the user that the RemoteConfig was not valid
    And provide them with the context, cluster, and namespace
    And inform them that the RemoteConfig will need to be manually fixed