Shadow run: create kubernetes manifest in workspace creation step instead of reconciliation step

MR:

  1. Create a Value Object for desired_config (!192099 - merged) • Ashvin Sharma • 18.1
  2. Move desired config generator methods (!193430 - merged) • Ashvin Sharma • 18.1 reverted by this MR.
  3. Remove DesiredConfigGenerator versioned call (!194148 - merged) • Ashvin Sharma • 18.1
  4. Copy all files needed by desired config generat... (!194318 - merged) • Ashvin Sharma • 18.1
  5. Introduce create desired_config chain in the "c... (!194589 - merged) • Ashvin Sharma • 18.2
  6. Create DesiredConfigFetcher and ConfigToApplyBu... (!194727 - merged) • Ashvin Sharma • 18.2

Description

As part of Simplify freezing of Kubernetes resources for w... (&17483), before running the actual logic in the create step, we would like to test this flow in shadow mode. This means we should have a function that creates Kubernetes configuration from the devfile for us to compare it with the Kubernetes config generated by the existing logic.

In order to compare the results between the newer and the older logic, a value object must be created that will simplify the diff and compare logic. Once the output from the new function is verified we will move this logic to the create step to freeze kubernetes resources.

Implementation Plan

MR 1: Create a value object

  • Create a class called DesiredConfig that stores the desired_config.
  • This class should implement diff, == and validate.
  • Validation function in this class should also validate the desired_config against Kubernetes JSON Schema.

MR 2: Remove versioned call of DesiredConfigGenerator from response_payload_builder.rb.

MR 3: Move all files that will be referenced by the new Create::DesiredConfig::Generator class.

MR 4: Create Create::DesiredConfig::Generator class that creates the desired config.

MR 5: Make another class called Reconcile::Output::ConfigToApplyBuilder and its unit tests.

MR 6: Piece it all together for shadow run

In Output::ResponsePayloadBuilder

  • create a function that calls both old and new logic to create desired config
  • diff the output of both the functions
  • log on warn level if diff is found

Acceptance criteria

  • Create a value object for desired_config that implements equals? and diff
  • Log the difference of results between the older and the newer logic.
  • Update all the related spec files

Ensure that during reconciliation, we will filter which resources to send based on the below logic

  • When it is a partial/full reconciliation and desired state is terminated, send the core inventory configmap and the secrets inventory config map.
  • When it is a partial reconciliation and the desired state is stopped/running, send the core inventory configmap, deployment, service, service account, network policy.
  • When it is a full reconciliation and the desired state is stopped/running, send the core inventory configmap, deployment, service, service account, network policy, secrets inventory config map, resource quota, secrets(which are to be mounted as environment variables), secrets(which are to be mounted as files)

Edited by Ashvin Sharma