Refactor VM Configs #5823

rhrazdil · 2020-06-25T11:50:22Z

Adding VMBuilder and VMTemplateBuilder classes to instantiate VirtualMachines and VirtualMachineTemplate and the data for creating them via VM Wizard.

What's missing:

V2V configs (that's a TODO for this PR, but shouldn't block at least initial review)
VM Builders do not generate VM/VMT Manifests yet
test labelling logic and test case skipping

rhrazdil · 2020-06-26T07:13:06Z

@suomiy when you have time, could you take a look please

atiratree

Looks pretty good! Much better experience reading the tests now.

atiratree · 2020-06-26T16:37:05Z

frontend/packages/kubevirt-plugin/integration-tests/tests/models/baseVMBuilder.ts

+import { getRandStr } from '../utils/utils';
+
+export abstract class BaseVMBuilder<T extends BaseVMBuilderData> {
+  protected kind: K8sKind;


I know the naming is very confusing and it is not consistent across the codebase, but can we name it model? As we use it in few places.

Yes, I used model in the UIResource, forgot to update this one

atiratree · 2020-06-26T16:45:33Z

frontend/packages/kubevirt-plugin/integration-tests/tests/models/baseVMBuilder.ts

+  public generateName(id?: string) {
+    const finalId = id || getRandStr(5);
+    const osId = OSIDLookup[this.data.os];
+    this.data.name = [


can we defer this action until the build is called?
Some of the fields might not be initialized yet.

Yes, I added in VMBuilder/VMTemplateBuilder

public generateName(id?: string) { this.generateNameId = id; return this; }

and

build() { super.generateName(this.generateNameId); return new VirtualMachine(this.getData()); }

So the name is set even when we don't really care about it

ok, but we should still allow for simple setName

Good point... What if we add setName method and generate random name by default if not set explicitly

can we still create some variable like generateNameID and use it when generating name in build method when name is not filled?
and not run generating name logic here (just from build method) as not all info for it might not be available yet

I added

generateNameForPrefix(prefix: string) { this.data.name = `${prefix}-${getRandStr(5)}`; return this; {

And don't call generateName anywhere except the build methods

atiratree · 2020-06-26T16:52:34Z

frontend/packages/kubevirt-plugin/integration-tests/tests/models/baseVMBuilder.ts

+    return this;
+  }
+
+  public setBuilder(builder: BaseVMBuilder<T>) {


What is the use case of this method? The naming is confusing as it does not behave exactly as a setter. Meaning, only the fields which the build has will be overwritten.

I think we thought of it similarly as when we inherit existing VMBuilder when creating new one, except in this case it's for two existing VMBuilders. We're not using it anywhere.

we use it in generateBuilders. Can we at least rename it a bit or add a doc?

Oh, right, we do use it there. I'm not sure about a fitting name, so added a doc

+1 for doc
what about naming it setBuilderAttributes?

atiratree · 2020-06-26T16:52:57Z

frontend/packages/kubevirt-plugin/integration-tests/tests/models/baseVMBuilder.ts

+    Object.keys(builder.data)
+      .filter((key) => builder.data[key] !== undefined)
+      .forEach((key) => {
+        this.data[key] = builder.data[key];


even in this implementation it is better to deep copy everything

atiratree · 2020-06-26T16:54:31Z

frontend/packages/kubevirt-plugin/integration-tests/tests/models/baseVMBuilder.ts

+        this.data[key] = builder.data[key];
+      });
+    if (builder.data.networks) {
+      this.data.networks.push(...builder.data.networks);


maybe we could filter out the duplicates (same references) first and then deep copy the data.

atiratree · 2020-06-26T18:27:49Z

frontend/packages/kubevirt-plugin/integration-tests/tests/mocks/vmBuilderPresets.ts

+  return newComputedBuilders;
+};
+
+export const computedVMBuilders = deepFreeze(


and some doc here? what is the result? You can just write some small example.

are we using the generated builders somewhere?

We're not using these generated builders atm. I'm not sure how to deal with adding polarion IDs for this. We could leave it without an ID and not have a test case in polarion, or create one test case in Polarion and describe the matrix of created VMs there. I'm afraid that having test case in Polarion for each combination is impossible to maintain givan the interface Polarion provides us....

We could use them in v2v suite, which is all about importing differently configured VMs

I think having one test case with the matrix could serve this purpose quite fine. Can we use it? Or are there some issues with it?

+1 for v2v

Don't see any issue, should I include it in this PR?

IMO you can, but up to you.

atiratree · 2020-06-26T18:42:30Z

frontend/packages/kubevirt-plugin/integration-tests/tests/mocks/vmBuilderPresets.ts

+  }, {}),
+);
+
+export const basicVM = new VMBuilder()


suppose we want to use two basicVM builders in one test, then these two builders would be the same instance and would mutate themselves.

I know it is always passed to the new VMBuilder constructor so this will never occur. But somebody might want to use the basicVM without this knowledge in the future and it could cause issues

We have few options here:

make the data inside this VMBuilder immutable (frozen) - we could add freeze method on it

just use immutable VMBuilderData here instead

use a function which returns new instance of a VMBuilder

use a function which returns new instance of a VMBuilder

updated

atiratree · 2020-06-26T18:45:54Z

frontend/packages/kubevirt-plugin/integration-tests/tests/models/virtualMachine.ts

@@ -77,4 +102,51 @@ export class VirtualMachine extends BaseVirtualMachine {
      await this.deleteNodeSelector(key);
    });
  }
+
+  async start(waitForAction = true) {


+1 easier to use

atiratree · 2020-06-26T18:48:39Z

frontend/packages/kubevirt-plugin/integration-tests/tests/models/virtualMachine.ts

+import { VMBuilderData } from '../types/vm';
+import { VM_ACTION, TAB, VM_STATUS } from '../utils/constants/vm';
+import { MatchLabels } from 'public/module/k8s';
+import { Wizard } from './wizard';

 const noConfirmDialogActions: VM_ACTION[] = [VM_ACTION.Start, VM_ACTION.Clone];

 export class VirtualMachine extends BaseVirtualMachine {


does it make sense to have similar inheritance structure here as the builders have?

Do you suggest to squash the UIResource, kubevirtUIResource together?

I don't know. I mean mainly the usage of data (VMBuilderData, etc) and having a common class for that with using generics.

Yes, still TODO

updated, is this what you meant?

almost :) replied bellow

atiratree · 2020-06-26T18:49:46Z

frontend/packages/kubevirt-plugin/integration-tests/tests/models/virtualMachine.ts

+  private data: VMBuilderData;
+
+  constructor(data: VMBuilderData) {
+    super({ ...data, model: VirtualMachineModel });


can we just cherry pick the name and namespace here and not pass the whole object? It is easier to read that way IMO

gouyang

Some places are using vm.detailViewAction(VM_ACTION.Start) and some are using vm.start(), Suggest use vm.start in all places.

gouyang · 2020-06-30T03:18:36Z

frontend/packages/console-shared/src/test-utils/utils.ts

@@ -149,13 +149,19 @@ export const waitForCount = (elementArrayFinder: any, targetCount: number) => {

 export const waitForStringInElement = (elem: any, needle: string) => {
  return async () => {
+    if (!(await elem.isPresent())) {
+      return false;
+    }
    const content = await elem.getText();
    return content.includes(needle);
  };
 };

 export const waitForStringNotInElement = (elem: any, needle: string) => {


is it necessaty? can it be !waitForStringInElement instead of waitForStringNotInElement?

the if (!(await elem.isPresent())) { is good to check, because if the element doesn't happen to be present, the subsequent await elem.getText(); would throw an exception.

As to whether we could use !waitForStringInElement, yes we could use it like that, I thought it would be a bit more readable this way. If you want to change the occurences to !waitForStringInElement instead, it can be done

gouyang · 2020-06-30T03:24:13Z

frontend/packages/kubevirt-plugin/integration-tests/tests/mocks/mocks.ts

+  [ProvisionSource.URL]: {
+    method: ProvisionSource.URL,
+    source:
+      'http://cnv-qe-server.rhevdev.lab.eng.rdu2.redhat.com/files/cnv-tests/cirros-images/cirros-0.4.0-x86_64-disk.raw',


https://download.cirros-cloud.net/0.4.0/cirros-0.4.0-x86_64-disk.img is workable on 2.4, maybe we should use a public source here.

I think I saw some issues with the public one, because our clusters download this image from the same IP address, and sometimes it seems that download.cirros-cloud.net rate limits the requests. I'll change it to public one, if there are issues, we can always use the internal mirror.

gouyang · 2020-06-30T03:28:19Z

frontend/packages/kubevirt-plugin/integration-tests/tests/mocks/mocks.ts

+  },
+  [ProvisionSource.CONTAINER]: {
+    method: ProvisionSource.CONTAINER,
+    source: 'kubevirt/cirros-registry-disk-demo',


Test like cloud-init requires fedora image, l suggest putting fedora image here for all testing using provision source CONTAINER.

yep, I'll use fedora

gouyang · 2020-06-30T03:42:36Z

frontend/packages/kubevirt-plugin/integration-tests/tests/models/virtualMachine.ts

@@ -77,4 +102,51 @@ export class VirtualMachine extends BaseVirtualMachine {
      await this.deleteNodeSelector(key);
    });
  }
+
+  async start(waitForAction = true) {


Suggest adding a check whether the VM is running, doing nothing if the VM is running. Same for stop.

That's interesting point, I can add it in a followup

a small note here: logic for checking if vm is expected running or not is quite complicated: please see isVMExpectedRunning function

gouyang · 2020-06-30T03:43:00Z

frontend/packages/kubevirt-plugin/integration-tests/tests/models/virtualMachine.ts

+  }
+
+  async stop(waitForAction = true) {
+    await this.action(VM_ACTION.Restart, waitForAction);


Typo here, restart should be stop.

Nice catch!

gouyang · 2020-06-30T03:52:02Z

frontend/packages/kubevirt-plugin/integration-tests/tests/models/virtualMachine.ts

+
+  /**
+   * Performs action form list view or detail view
+   */
  async action(action: VM_ACTION, waitForAction = true, timeout?: number) {


It seems waitForAction is always true, if so, can we simplify this function by not adding waitForAction?

Not always, in non-admin we don't wait, and I'm pretty sure there are more uses.
I would prefer to keep it, it gives up option to save time where waiting for the VM to be Running is not required, for example in permission oriented tests

rhrazdil · 2020-07-03T13:47:17Z

Some places are using vm.detailViewAction(VM_ACTION.Start) and some are using vm.start(), Suggest use vm.start in all places.

@gouyang
it is intended vm.actions.scenario.ts to use specific detailViewAction/listViewAction method, where we want to test the detail dropdown and the kebap menu. Where this is not required, we can use the vm.start() (or other) to use the nearest option (nearest in terms of navigation steps, so that we don't unneccerilly navigate to the detail view for example)

rhrazdil · 2020-07-07T11:02:38Z

@suomiy Alright, I believe I addressed all the comments from the first round :)

rhrazdil · 2020-07-09T13:26:06Z

frontend/packages/kubevirt-plugin/integration-tests/tests/models/virtualMachine.ts

+    await this.action(VM_ACTION.Delete, waitForAction);
+  }
+
+  async clone(name?: string, namespace?: string): Promise<VirtualMachine> {


@suomiy wdyt?

usage is https://github.com/openshift/console/pull/5823/files#diff-b7e6e8ec3576408c2fcd89598db464cdR240

looks great and user friendly
One last touch could be a usage of builder here and using setName/setNamespace instead of plain object.

I wanted to use the VMBuilder, but it creates dependency cycle....
That's why I did it this way

ok np. Looks nice as it is

atiratree · 2020-07-09T14:46:26Z

frontend/packages/kubevirt-plugin/integration-tests/tests/models/baseVMBuilder.ts

+
+  protected data: T;
+
+  constructor(kind: K8sKind, builder?: BaseVMBuilder<T>) {


kind leftover

atiratree · 2020-07-09T15:11:33Z

frontend/packages/kubevirt-plugin/integration-tests/tests/models/baseVMBuilder.ts

+  public generateName(id?: string) {
+    const finalId = id || getRandStr(5);
+    const osId = OSIDLookup[this.data.os];
+    this.data.name = [


can we still create some variable like generateNameID and use it when generating name in build method when name is not filled?
and not run generating name logic here (just from build method) as not all info for it might not be available yet

atiratree · 2020-07-09T15:12:54Z

frontend/packages/kubevirt-plugin/integration-tests/tests/vm.wizard.scenario.ts

+        .setStartOnCreation(false)
+        .generateName()
+        .setDisks([getDiskToCloneFrom()])
+        .generateName('vm1')


called twice, plus in other cases as well.
maybe we should also remove all instances of generateName calls if we do it by default

Removed all generateName instances

atiratree · 2020-07-09T15:15:14Z

frontend/packages/kubevirt-plugin/integration-tests/tests/models/baseVMBuilder.ts

+    return this;
+  }
+
+  public setBuilder(builder: BaseVMBuilder<T>) {


+1 for doc
what about naming it setBuilderAttributes?

atiratree · 2020-07-09T15:17:50Z

frontend/packages/kubevirt-plugin/integration-tests/tests/models/baseVMBuilder.ts

+
+  public appendBuilder(builder: BaseVMBuilder<T>) {
+    const customAppendKeys = new Set(['networks', 'disks', 'storageClassAttributes']);
+    const data = _.cloneDeep(builder.getData());


I forgot what was here before and it looks fine now, but getData returns cloned data already so it should be enough.

Right, fixed

atiratree · 2020-07-09T15:25:08Z

frontend/packages/kubevirt-plugin/integration-tests/tests/models/virtualMachine.ts

+    await this.action(VM_ACTION.Delete, waitForAction);
+  }
+
+  async clone(name?: string, namespace?: string): Promise<VirtualMachine> {


looks great and user friendly
One last touch could be a usage of builder here and using setName/setNamespace instead of plain object.

atiratree · 2020-07-09T15:30:32Z

frontend/packages/kubevirt-plugin/integration-tests/tests/vm.non-admin.scenario.ts

+  const vm = new VMBuilder(getBasicVMBuilder())
+    .setProvisionSource(provisionSources.URL)
+    .setDisks([rootDisk])
+    .setFlavor(flavorConfigs.Tiny)


there are still some instances where specifying Tine is not required due to getBasicVM/VMT builders

Removed all the unneccessary ones

atiratree · 2020-07-09T15:33:29Z

frontend/packages/kubevirt-plugin/integration-tests/tests/mocks/vmBuilderPresets.ts

+import { VMTemplateBuilder } from '../models/vmtemplateBuilder';
+import { VirtualMachineTemplate } from '../models/virtualMachineTemplate';
+
+/**


atiratree · 2020-07-09T15:34:30Z

frontend/packages/kubevirt-plugin/integration-tests/tests/vm.wizard.scenario.ts

+        .setFlavor(flavorConfigs.Medium)
+        .setWorkload(Workload.DESKTOP)
+        .setDisks([hddDisk])
+        .setStartOnCreation(false)


+ in multiple places this is not necessary

atiratree · 2020-07-09T15:40:25Z

frontend/packages/kubevirt-plugin/integration-tests/tests/models/virtualMachine.ts

+import { VMBuilderData } from '../types/vm';
+import { VM_ACTION, TAB, VM_STATUS } from '../utils/constants/vm';
+import { MatchLabels } from 'public/module/k8s';
+import { Wizard } from './wizard';

 const noConfirmDialogActions: VM_ACTION[] = [VM_ACTION.Start, VM_ACTION.Clone];

 export class VirtualMachine extends BaseVirtualMachine {


atiratree · 2020-07-13T09:49:48Z

frontend/packages/kubevirt-plugin/integration-tests/tests/mocks/vmBuilderPresets.ts

+        const additionalBuilder = new VMBuilder().setData(additionalBuilderData);
+        newComputedBuilders[`config ${idx}-${additionalBuilderId}`] = new VMBuilder(builder)
+          .setBuilderAttributes(additionalBuilder)
+          .generateNameForPrefix(`${additionalBuilderId}`);


except in this case - I am not sure if we don't want to include the appropriate metadata of the configuration in the name

okay, changed back

atiratree · 2020-07-13T09:55:54Z

frontend/packages/kubevirt-plugin/integration-tests/tests/models/baseVMBuilder.ts

+    return this;
+  }
+
+  public appendBuilder(builder: BaseVMBuilder<T>) {


thanks for removing the unnecessary storageAttributes - makes it easier to read

atiratree · 2020-07-13T09:57:48Z

frontend/packages/kubevirt-plugin/integration-tests/tests/models/baseVirtualMachine.ts

+import { Disk, Network } from '../types/types';
+import { BaseVMBuilderData } from '../types/vm';
+
+export class BaseVirtualMachine<T extends BaseVMBuilderData> extends KubevirtUIResource {


+1, can we use this also for the VirtualMachineTemplate?

Yes, KubeVirtUIResource is now generic, from that we inherit BaseVirtualMachine with VMBuilderData and VirtualMachineTemplate with VMTemplateBuilderData

atiratree · 2020-07-13T09:58:12Z

frontend/packages/kubevirt-plugin/integration-tests/tests/models/baseVirtualMachine.ts

+import { BaseVMBuilderData } from '../types/vm';
+
+export class BaseVirtualMachine<T extends BaseVMBuilderData> extends KubevirtUIResource {
+  protected data: T;


can we create a constructor here and use it in children classes? and pass name/namespace/model to super?

eg

constructor(data: T, model: K8sKind) {

With regards to the comment above, I added this constructor to KubevirtUIResource

rhrazdil · 2020-07-13T19:43:42Z

/test images

atiratree

looking pretty good

atiratree · 2020-07-14T10:27:33Z

frontend/packages/kubevirt-plugin/integration-tests/tests/models/virtualMachine.ts

-    super({ ...config, model: VirtualMachineModel });
+  constructor(data: VMBuilderData) {
+    super(data, VirtualMachineModel);
+    this.data = data;


is this line needed?

Nope. Removed.

atiratree · 2020-07-14T10:27:59Z

frontend/packages/kubevirt-plugin/integration-tests/tests/models/virtualMachineTemplate.ts

+export class VirtualMachineTemplate extends KubevirtUIResource<VMTemplateBuilderData> {
+  constructor(data: VMTemplateBuilderData) {
+    super(data, VirtualMachineTemplateModel);
+    this.data = data;


atiratree · 2020-07-14T11:38:14Z

frontend/packages/kubevirt-plugin/integration-tests/tests/models/kubevirtUIResource.ts


-export class KubevirtUIResource extends UIResource {
-  async navigateToListView() {
+export class KubevirtUIResource<T extends BaseVMBuilderData> extends UIResource {


+1, nice refactoring

atiratree · 2020-07-14T11:40:01Z

frontend/packages/kubevirt-plugin/integration-tests/tests/vmtemplate.wizard.scenario.ts

-    let vmTemplate: VirtualMachineTemplate;
+    const vmTemplate = new VMTemplateBuilder(getBasicVMTBuilder())
+      .setProvisionSource(provisionSources.Container)
+      .setFlavor(flavorConfigs.Tiny)


+here, superfluous setters

atiratree · 2020-07-14T11:44:35Z

frontend/packages/kubevirt-plugin/integration-tests/tests/mocks/vmBuilderPresets.ts

+        }, {} as VMBuilderData);
+        const additionalBuilder = new VMBuilder().setData(additionalBuilderData);
+        newComputedBuilders[`config ${idx}-${additionalBuilderId}`] = new VMBuilder(builder)
+          .setBuilderAttributes(additionalBuilder)


I know I am getting annoying with this, but can we have ${idx}-${additionalBuilderId} and all the metadata in the name?
This could help with debugging when having large number of combinations.

Fixed. Added Workload to the name as well

atiratree · 2020-07-14T17:04:49Z

Good job! This is a great enhancement for kubevirt tests.

/lgtm

rhrazdil · 2020-07-14T21:31:33Z

Awesome! Thanks for your patient guidance with this.
/test e2e-gcp-console

rawagner · 2020-07-15T06:47:16Z

/approve

openshift-ci-robot · 2020-07-15T06:47:34Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: rawagner, rhrazdil, suomiy

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

~~frontend/OWNERS~~ [rawagner]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

openshift-bot · 2020-07-15T07:58:05Z

/retest

Please review the full test history for this PR and help us cut down flakes.

openshift-ci-robot requested review from jcaianirh and jelkosz June 25, 2020 11:50

openshift-ci-robot added component/kubevirt Related to kubevirt-plugin component/network-attachment-definition Related to network-attachment-definition component/shared Related to console-shared labels Jun 25, 2020

atiratree suggested changes Jun 26, 2020

View reviewed changes

gouyang reviewed Jun 30, 2020

View reviewed changes

rhrazdil force-pushed the vmbuilder branch from 0bec5d7 to d54a61f Compare July 7, 2020 10:56

rhrazdil force-pushed the vmbuilder branch from d54a61f to 4d89ffb Compare July 9, 2020 13:24

rhrazdil commented Jul 9, 2020

View reviewed changes

atiratree suggested changes Jul 9, 2020

View reviewed changes

rhrazdil force-pushed the vmbuilder branch 3 times, most recently from 2babadf to 4ea5af3 Compare July 10, 2020 10:16

atiratree reviewed Jul 13, 2020

View reviewed changes

rhrazdil force-pushed the vmbuilder branch 2 times, most recently from 6067bc6 to 552d59f Compare July 13, 2020 18:19

openshift-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jul 14, 2020

atiratree suggested changes Jul 14, 2020

View reviewed changes

Refactor VM Configs

05e6f7e

rhrazdil force-pushed the vmbuilder branch from 552d59f to 05e6f7e Compare July 14, 2020 14:48

openshift-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jul 14, 2020

openshift-ci-robot assigned atiratree Jul 14, 2020

openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Jul 14, 2020

atiratree approved these changes Jul 14, 2020

View reviewed changes

openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jul 15, 2020

openshift-merge-robot merged commit 33dde1b into openshift:master Jul 15, 2020

spadgett added this to the v4.6 milestone Jul 16, 2020


		protected data: T;

		constructor(kind: K8sKind, builder?: BaseVMBuilder<T>) {

Refactor VM Configs #5823

Refactor VM Configs #5823

Conversation

rhrazdil commented Jun 25, 2020 • edited

rhrazdil commented Jun 26, 2020

atiratree left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rhrazdil Jul 3, 2020 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gouyang left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

atiratree Jul 3, 2020 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rhrazdil commented Jul 3, 2020 • edited

rhrazdil commented Jul 7, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rhrazdil commented Jun 25, 2020 •

edited

rhrazdil Jul 3, 2020 •

edited

atiratree Jul 3, 2020 •

edited

rhrazdil commented Jul 3, 2020 •

edited