Write a RemoteConfig instance

[jeromy-cannon]

• design: Create design for RemoteConfig #657
• list of mutable commands: Create design for RemoteConfig #657 (comment)
• See: details about parsing to/from YAML in: Create a Local Config for storing configurations on the users machine #590
• NOTES:
  • The RemoteConfig Kubernetes ConfigMap which is namespace specific will be called solo-remote-config with a label of solo.hedera.com/type: remote-config

Feature: write a RemoteConfig instance

  The RemoteConfig instance will be written to a Kubernetes ConfigMap.  It will be stored as YAML in the Kubernetes ConfigMap.  The RemoteConfig instance will be converted to JSON that matches the associated JSON schema the JSON will then be written to YAML and stored in the `solo-remote-config` Kubernetes ConfigMap within the namespace and for each cluster contained within the RemoteConfig cluster to namespace mapping.

  Scenario: the RemoteConfig writes successfully to a single cluster deployment
    Given a valid RemoteConfig
    And connections exist for each namespace, cluster, and context
    When write is called for a single cluster deployment
    And validates successfully (stubbed if before #774)
    And the RemoteConfig will be converted to YAML
    Then written as a K8s ConfigMap named `solo-remote-config`

  Scenario: the RemoteConfig fails to validate
    Given a valid RemoteConfig
    And connections exist for each namespace, cluster, and context
    When write is called for a single cluster deployment
    And validate fails (mocked)
    And the RemoteConfig will be converted to YAML
    And fails to write to the cluster
    Then a SoloError will be thrown explaining to the user which deployment/cluster/context failed to be written and the error message to support it
    And inform the user that they will need to manually bring the clusters of the deployment into sync if there is more than one cluster

  Scenario: the RemoteConfig fails to write to the cluster
    Given a valid RemoteConfig
    And connections exist for each namespace, cluster, and context
    When write is called for a single cluster deployment
    And validates successfully (stubbed if before #774)
    And the RemoteConfig will be converted to YAML
    And fails to write to the cluster
    Then a SoloError will be thrown explaining to the user which deployment/cluster/context failed to be written and the error message to support it
    And inform the user that they will need to manually bring the clusters of the deployment into sync if there is more than one cluster

  Scenario: the RemoteConfig writes successfully to one cluster but fails to write to a second cluster
    Given a valid RemoteConfig
    And connections exist for each namespace, cluster, and context
    When write is called for a two cluster deployment
    And validates successfully (stubbed if before #774)
    And the RemoteConfig will be converted to YAML
    And writes the RemoteConfig to the first cluster successfully
    And fails to write to the second cluster
    Then a SoloError will be thrown explaining to the user which deployment/cluster/context failed to be written and the error message to support it
    And inform the user that they will need to manually bring the clusters of the deployment into sync if there is more than one cluster

  Scenario: the RemoteConfig already exists and fails on recreate (delete/create (or patch))
    Given a valid RemoteConfig
    And connections exist for each namespace, cluster, and context
    And an older copy of RemoteConfig exists on the namespace, cluster, and context
    When write is called for to update the RemoteConfig
    And validates successfully (stubbed if before #774)
    And the RemoteConfig will be converted to YAML
    And fails to write to the cluster
    Then a SoloError will be thrown explaining to the user which deployment/cluster/context failed to be written and the error message to support it
    And inform the user that they will need to manually bring the clusters of the deployment into sync if there is more than one cluster


  Scenario: the RemoteConfig already exists and is recreated (delete/create (or patch)) successfully 
    Given a valid RemoteConfig
    And connections exist for each namespace, cluster, and context
    And an older copy of RemoteConfig exists on the namespace, cluster, and context
    When write is called for to update the RemoteConfig
    And validates successfully (stubbed if before #774)
    And the RemoteConfig will be converted to YAML
    Then the RemoteConfig is successfully written to the cluster with the updated RemoteConfig

[jeromy-cannon]

closed in #862