Add memory validations in the VM wizard #3839

irosenzw · 2019-12-30T20:16:09Z

Fixes: CNV-2913

Add common-templates validation type
Consume memory validations from common-templates
and use them in the VM wizard
VMSettingsValidationConfig's validator
can have more than one validator function for a single key

Signed-off-by: Ido Rosenzwig irosenzw@redhat.com

irosenzw · 2019-12-30T20:16:43Z

yaacov · 2019-12-31T05:16:17Z

...evirt-plugin/src/components/create-vm-wizard/redux/validations/vm-settings-tab-validation.ts

  },
  [VMSettingsField.CPU]: {
    detectValueChanges: [VMSettingsField.CPU],
-    validator: asVMSettingsFieldValidator(validatePositiveInteger),
+    validators: [asVMSettingsFieldValidator(validatePositiveInteger)],


do we need a cpu validation ?

both validations for CPU and memory that check for a positive integer value seems unnecessary, as you cannot type anything that isn't a positive integer.
But I'm not sure what happens when you use a template that has an invalid value.
haven't tried it though, but I think we can address this question in another PR.
@yaacov What do you think ?

if the template has a vlidation:

{ "name": "core-limits", "path": "jsonpath::.spec.domain.cpu.cores", "message": "cpu cores must be limited", "rule": "integer", "min": 100, "max": 800 }

and user enter 5 cpus, who checks that 5 is not valid value, what am I missing here ?

@irosenzw we let the user enter any cpu numer they want, I think we should check for cpu outside the range ... is it problematic ?

For example: a "big-cpu-template" have a rule that min cpu is 18, and user entered 6, this is an invalid cpu number, do we check it ?

First of all, the PR is for memory validation only at this point. In the future we will cover all the fields in the VM wizard.

Regarding your question, if this is the only validation, it will fail.
but it there is another template that has a validation of :

{ "name": "core-limits", "path": "jsonpath::.spec.domain.cpu.cores", "message": "cpu cores must be limited", "rule": "integer", "min": 2 }

it will pass.

yaacov · 2019-12-31T05:24:50Z

...eate-vm-wizard/redux/validations/common-template-validations/common-templates-validations.ts

+  let relevantTemplates;
+  // Get templates based on OS and WorkloadProfile
+  if (os && workloadProfile) {
+    relevantTemplates = (commonTemplates || []).filter(


can you try to make "getRelevantTemplates" method and use it here instead to doing it inline, i think it will look nicer ?

const relevantTemplates = (os && workloadProfile) ? getRelevantTemplates(templates, os, profile, flavor) | []

yaacov · 2019-12-31T05:34:01Z

...eate-vm-wizard/redux/validations/common-template-validations/common-templates-validations.ts

+    );
+
+    // Get the exact template when a flavor is chosen
+    if (flavor && flavor !== 'Custom') {


can you try to add this check to the filter in line 40 ?

... && ( (flavor === 'Custom' || iGetIn(t, ['metadata', 'labels', `${TEMPLATE_FLAVOR_LABEL}/${flavor}`]) ), ...

yaacov · 2019-12-31T05:43:50Z

...eate-vm-wizard/redux/validations/common-template-validations/common-templates-validations.ts

+
+    // Get all relevant validations for the specific fieldId
+    const relevantFieldValidations: CommonTemplatesValidation[] = [];
+    myValidations.forEach((validationArray: CommonTemplatesValidation[]) => {


can you make a "getValidation" method ( similar to comment about getRelevantTemplates ) ?

may even be in the selector file and not here ?

yaacov · 2019-12-31T06:26:10Z

...eate-vm-wizard/redux/validations/common-template-validations/common-templates-validations.ts

+    relevantTemplates = (commonTemplates || []).filter(
+      (template) =>
+        iGetIn(template, ['metadata', 'labels', TEMPLATE_TYPE_LABEL]) === 'base' &&
+        iGetIn(template, ['metadata', 'labels', `${TEMPLATE_OS_LABEL}/${os}`]) &&


ca you try this pattern in the tests:

( !os || iGetIn(template, ['metadata', 'labels', `${TEMPLATE_OS_LABEL}/${os}`]) )

it makes this metyhod more general, and will handle cases where we want to search only by flavor or onlt by os ...

...evirt-plugin/src/components/create-vm-wizard/redux/validations/vm-settings-tab-validation.ts

yaacov · 2019-12-31T09:03:33Z

...evirt-plugin/src/components/create-vm-wizard/redux/validations/vm-settings-tab-validation.ts

+  const memValueBytes = memValueGB * 1024 ** 3;
+
+  // filter all the 'min' validation rules
+  const minValidations = validations.filter((v) => 'min' in v);


I like better running each check individually and looking for first success, then finding the min of all validations and then checking once. because it create a pattern of checking rules we can apply for all checks, e.g. on regex:

validations.once( ... // do one min validation at a time )

validations.once( ... // do one regex validation at a time )

yaacov · 2019-12-31T09:05:30Z

...eate-vm-wizard/redux/validations/common-template-validations/common-templates-validations.ts

+        iGetIn(t, ['metadata', 'labels', `${TEMPLATE_FLAVOR_LABEL}/${flavor}`]),
+      );
+    }
+    const myValidations: CommonTemplatesValidation[][] = [];


my prefix :-)

yaacov · 2020-01-02T12:55:22Z

...eate-vm-wizard/redux/validations/common-template-validations/common-templates-validations.ts

+  const commonTemplates = iGetLoadedCommonData(state, id, VMWizardProps.commonTemplates);
+
+  // Get templates based on OS and WorkloadProfile
+  if (os && workloadProfile) {


we have this check in getRelevantTemplates , it will return an empty array [], and then if getFieldValidations return empty array, you will not need this "if" and not the if in line 50

yaacov · 2020-01-02T16:03:00Z

...evirt-plugin/src/components/create-vm-wizard/redux/validations/vm-settings-tab-validation.ts

+      case IntegerValidtionType.max:
+        return validateMaxRule(ivo, memValueBytes);
+      default:
+        return true;


true, are you sure, i'm missing somthing ?

Right. It should be false.

yaacov · 2020-01-02T16:19:00Z

...n/src/components/create-vm-wizard/redux/validations/common-template-validations/selectors.ts

+  );
+};
+
+export const getValidationsFromTemplates = (templates): CommonTemplatesValidation[][] => {


I think I'm missing something here - why we do not flatten the rules ?

for example, if you have two templates:
template1:

[ { "name": "core-limits", "path": "jsonpath::.spec.domain.cpu.cores", "message": "cpu cores must be limited", "min": 1, "max": 8 } ]

template2:

[ { "name": "validation-rule-01", "valid": "jsonpath::.some.json.path", "path”: "jsonpath::.some.json.path[*].leaf", "rule”: "integer", "message”: ".some.json.path[*].leaf must exists", "min”: 1, "justWarning": true }, { "name": "validation-rule-02", "valid": "jsonpath::.another.json.path", "path": "jsonpath::.another.json.path.item", "rule": "integer", "message": "jsonpath::./another.json.path.item must be below a threshold", "max": "jsonpath::.yet.another.json.path.defines.the.limit" } ]

we should end up with a flat 3 rules and not with 2 sets one having 1 rule and the other 2.

Multiple templates can occur when for example the workload profile is not selected right? Only one template will be selected at the end.
I think we should pick the most relaxed validation (meaning allowing everything if one template is missing the validation. Or combining min max of the other ones to get the largest interval span).

We should also probably use the validation from the user template if one is selected.

First of all, the user must pick the OS and the workload profile in order to get the relevant templates from common templates. Only the flavor can be selected as Custom.

Second, when a user pick a flavor, we don't do any validations to the memory - since it is hard-coded in the template. when the user chooses Custom we are getting multiple templates, hence multiple validations from each template.
The idea here is to PASS if at least one of the validations had passed, and FAIL if none had.

user template isn't in the scope of this feature and will/should be addressed in another PR.

user template isn't in the scope of this feature and will/should be addressed in another PR.

are you sure ? IFAIU it's the simplest test, where you have one template and do not need to look for any other ...

getRelevantTemplates = customTemplate ? [ customTemplate ] | ....

I've Added support for user template validations

yaacov · 2020-01-02T16:26:26Z

...eate-vm-wizard/redux/validations/common-template-validations/common-templates-validations.ts

+    }
+    if (validationAttrs.includes('min')) {
+      if (integerValidationObj.type === IntegerValidtionType.max) {
+        // change the type to 'between' because we have two seperate validations of min and max


hmm, when calling this method we should have only one rule - see comment https://github.com/openshift/console/pull/3839/files#r362532470

not necessarily.
Most of the times we will have just one, it will be one of the three:

{min:1},{cpu:2},....

{max:10},{cpu:2},...

{min:1,max:10},{cpu:2},....
but we have here an edge case when a between validation can be written as a 2 separated validations in a single template:

{min:1},{max:10},{cpu:2},....

this method should be called with one rule at a time, you should check why it is called with an array ...

yaacov · 2020-01-02T16:52:50Z

...eate-vm-wizard/redux/validations/common-template-validations/common-templates-validations.ts

+  // eslint-disable-next-line consistent-return
+  validations.forEach((validation) => {
+    const validationAttrs = getValidationAttributes(validation);
+    if (validationAttrs.includes('min') && validationAttrs.includes('max')) {


can we check the object directly without getting the validationAttrs ?
e.g. is their a way to ask if validation itself has an attribute without first getting all the attributes into a list ... ?

getValidationAttributes looks like something that we should get for free from the language ...

Right. I'll remove the method

yaacov · 2020-01-02T16:55:31Z

...eate-vm-wizard/redux/validations/common-template-validations/common-templates-validations.ts

+  return getFieldValidations(validations, IDToJsonPath[fieldId]);
+};
+
+export const getIntegerValidationType = (


this method should get one CommonTemplatesValidation and return an enum, we are doing something wrong here ...
I think it's because we didn't flatten the rules in https://github.com/openshift/console/pull/3839/files#r362532470

yaacov · 2020-01-02T17:02:14Z

...evirt-plugin/src/components/create-vm-wizard/redux/validations/vm-settings-tab-validation.ts

+    errorMsg = ivo.message;
+    switch (ivo.type) {
+      case IntegerValidtionType.between:
+        return validateBetweenRule(ivo, memValueBytes);


sinse we know that the current rule vArr ( should be one not an array ) is a "between" rule, then vArr must have a min and max properties, we should be able to write: memValueBytes >= vArr.min && vArr.max <= memValueBytes, what am I missing ?

commented above. it should be an array.

atiratree · 2020-01-03T11:01:52Z

...evirt-plugin/src/components/create-vm-wizard/redux/validations/vm-settings-tab-validation.ts

@@ -119,24 +178,28 @@ const validationConfig: VMSettingsValidationConfig = {
          ]
        : [VMWizardProps.activeNamespace, VMWizardProps.virtualMachines];
    },
-    validator: validateVm,
+    validators: [validateVm],


let's not complicate it with an array of validators. Semantically one fields needs only one validation call. The validation can branch inside the call depending on the use case.

I think it's better to have multiple validators like this. It is clearer that a field has multiple validators rather than a validator that may or may not branch into multiple validators inside it.

Why is it better?
It is unclear what the execution of the validators should be e.g. the order and the validation message.

IMO the interface should be expressive enough for future changes (possible cross validation).

atiratree · 2020-01-03T11:06:50Z

frontend/packages/kubevirt-plugin/src/components/create-vm-wizard/redux/validations/utils.ts

+          updateAcc[validationFieldKey] = { validation };
+        }
+
+        // break when one validation is invalid


we can keep the old code here if we use one validator and decide the validation priority inside the validator.

atiratree · 2020-01-03T12:00:11Z

...n/src/components/create-vm-wizard/redux/validations/common-template-validations/selectors.ts

+  return { type: IntegerValidtionType.between, value, message };
+};
+
+export const validateMinRule = (ivo: IntegerValidationObj, value: number): boolean => {


I don't think we need all of these wrappers.
I think we could rather do one loop and a set two variables according to the min/max/between

let min = 0; let max = Number.POSITIVE_INFINITY; loop over attributes and set accordingly

hey, my 2 cents are that we do not need this set of methods at all, instead of calling them, we shoud do:

rule.min >= value

all this checks are already valid after we check getType(rule) becase if type is minType rule must have a rule.min attribute ...

atiratree · 2020-01-03T12:18:08Z

...n/src/components/create-vm-wizard/redux/validations/common-template-validations/selectors.ts

+  IntegerBetween,
+} from './validation-types';
+
+export const getRelevantTemplates = (commonTemplates, os, workloadProfile, flavor) => {


can we move this to vm-template selectors?

we can. no problem.

atiratree · 2020-01-03T12:28:13Z

...n/src/components/create-vm-wizard/redux/validations/common-template-validations/selectors.ts

+  );
+};
+
+export const getValidationsFromTemplates = (templates): CommonTemplatesValidation[][] => {


Multiple templates can occur when for example the workload profile is not selected right? Only one template will be selected at the end.
I think we should pick the most relaxed validation (meaning allowing everything if one template is missing the validation. Or combining min max of the other ones to get the largest interval span).

We should also probably use the validation from the user template if one is selected.

atiratree · 2020-01-03T12:30:57Z

...eate-vm-wizard/redux/validations/common-template-validations/common-templates-validations.ts

+  // eslint-disable-next-line consistent-return
+  validations.forEach((validation) => {
+    const validationAttrs = getValidationAttributes(validation);
+    if (validationAttrs.includes('min') && validationAttrs.includes('max')) {


yaacov · 2020-01-05T16:27:57Z

...eate-vm-wizard/redux/validations/common-template-validations/common-templates-validations.ts

+};
+
+export const runValidation = (validation: CommonTemplatesValidation, value: number): boolean => {
+  if ('integerBetween' in validation && validation.integerBetween === true) {


can we do

if (('min' in validation) && ('max' in validation))

instead ?

yaacov · 2020-01-05T16:34:58Z

...n/src/components/create-vm-wizard/redux/validations/common-template-validations/selectors.ts

+import { CommonTemplatesValidation } from './validation-types';
+
+export const getValidationsFromTemplates = (templates): CommonTemplatesValidation[][] => {
+  return templates.map((relevantTemplate) =>


can we do ?

return templates.map((relevantTemplate) => JSON.parse(iGetIn(relevantTemplate, ['metadata', 'annotations', 'validations'])), ).flat();

yaacov · 2020-01-05T16:35:45Z

...omponents/create-vm-wizard/redux/validations/common-template-validations/validation-types.ts

+  message: string; // User-friendly string message describing the failure, should the rule not be satisfied
+  min?: number; // For 'integer' rule
+  max?: number; // For 'integer' rule
+  integerBetween?: boolean; // For 'integer' rule


see https://github.com/openshift/console/pull/3839/files#r363103332

yaacov · 2020-01-05T16:36:47Z

...omponents/create-vm-wizard/redux/validations/common-template-validations/validation-types.ts

+  integerBetween?: boolean; // For 'integer' rule
+  minLength?: number; // For 'string' rule
+  maxLength?: number; // For 'string' rule
+  stringBetween?: boolean; // For 'string' rule


see https://github.com/openshift/console/pull/3839/files#r363103332

yaacov · 2020-01-05T16:39:37Z

...n/src/components/create-vm-wizard/redux/validations/common-template-validations/selectors.ts

+): CommonTemplatesValidation[] => {
+  const allTemplateValidations: CommonTemplatesValidation[] = [];
+  validations.forEach((validationArray: CommonTemplatesValidation[]) => {
+    validationArray.forEach((validation: CommonTemplatesValidation) => {


this hould be one level: https://github.com/openshift/console/pull/3839/files#r363103746

yaacov · 2020-01-05T16:40:20Z

...n/src/components/create-vm-wizard/redux/validations/common-template-validations/selectors.ts

+};
+
+export const getFieldValidations = (
+  validations: CommonTemplatesValidation[][],


validations should be flat ... validations: CommonTemplatesValidation[]

yaacov · 2020-01-05T16:55:08Z

...eate-vm-wizard/redux/validations/common-template-validations/common-templates-validations.ts

+  return fieldValidations;
+};
+
+export const runValidation = (validation: CommonTemplatesValidation, value: number): boolean => {


can we do ?

export const runValidations = (validations: CommonTemplatesValidation[], value: number): (valid: boolean, mesage: string) => { let message = null const valid = validations.some((validation) => { message = validation.message ... if ('max' in validation) { return value <= validation.max; } return false } ... return { valid, messge} });

sorry the signiture should be like in:
see: https://github.com/openshift/console/pull/3839/files#r362222830

const runVlidations = (validations, value: any) => ...

because this method can accept any type of falue number of string and run the appropriate validation rules.

yaacov · 2020-01-05T16:56:48Z

...evirt-plugin/src/components/create-vm-wizard/redux/validations/vm-settings-tab-validation.ts

+    There is no value that would satisfy both validations.
+  */
+  let errorMsg;
+  const isValid = validations.some((validation) => {


can we do ?

const ( isValid, message } = runValidations(validations, memValueBytes);

see https://github.com/openshift/console/pull/3839/files#r363104852

Or we could create a Validation class which would encapsulate all of it - validation data (on initialization) and the logic

Fixes: CNV-2913 - Add common-templates validation type - Consume memory validations from the user template if chosen or from common templates based on OS, workload Profile and flavor fields and use them in the VM wizard. Signed-off-by: Ido Rosenzwig <irosenzw@redhat.com>

yaacov · 2020-01-06T16:26:23Z

frontend/packages/kubevirt-plugin/src/selectors/vm-template/selectors.ts

+  workloadProfile: string,
+  flavor: string,
+) => {
+  if (!commonTemplates || commonTemplates.length === 0 || !os || !workloadProfile) {


Nitpick: I think it's nice to allow the logic of "if os is not defined => allow all possible os"
so in my view we should do:

if (!commonTemplates || commonTemplates.length === 0) {

and let the checks in L150 and L151 implement the above logic.

yaacov · 2020-01-06T16:37:26Z

...n/src/components/create-vm-wizard/redux/validations/common-template-validations/selectors.ts

+    .map((relevantTemplate) =>
+      JSON.parse(iGetIn(relevantTemplate, ['metadata', 'annotations', 'validations'])),
+    )
+    .valueSeq()


question: what does .valueSeq().toArray() adds here ? does it work if we remove them ?

it gets the validations as an array from the immutable object. Thus cannot be removed.

yaacov · 2020-01-06T16:38:33Z

...eate-vm-wizard/redux/validations/common-template-validations/common-templates-validations.ts

+  // Get userTemplate if it was chosen
+  const userTemplateName = iGetVmSettingValue(state, id, VMSettingsField.USER_TEMPLATE);
+  const iUserTemplates = iGetLoadedCommonData(state, id, VMWizardProps.userTemplates);
+  const iUserTemplate =


Nitpick: if we have iUserTemplate we do not need to fetch os, flavor, workloadProfile and commonTemplates

so if we move lines 41...46 above line 32, we can do:

if (iUserTemplate) { validations = getValidationsFromTemplates([iUserTemplate]); return getFieldValidations(validations, IDToJsonPath[fieldId]); } // Get OS, workload-profile and flavor attributes const os = iGetVmSettingAttribute(s...

yaacov · 2020-01-06T16:48:22Z

/lgtm
have some nitpicks ...

openshift-ci-robot · 2020-01-06T16:48:44Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: irosenzw, yaacov

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/packages/kubevirt-plugin/OWNERS~~ [yaacov]

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-01-06T17:02:09Z

/retest

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

openshift-bot · 2020-01-06T17:09:13Z

/retest

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

Nitpicks from #3839

openshift-ci-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Dec 30, 2019

openshift-ci-robot requested review from rhrazdil and atiratree December 30, 2019 20:16

openshift-ci-robot added the component/kubevirt Related to kubevirt-plugin label Dec 30, 2019

yaacov reviewed Dec 31, 2019

View reviewed changes

...evirt-plugin/src/components/create-vm-wizard/redux/validations/vm-settings-tab-validation.ts Outdated Show resolved Hide resolved

yaacov reviewed Dec 31, 2019

View reviewed changes

irosenzw force-pushed the add-validation-feature branch 3 times, most recently from 6a7ffc9 to 6397059 Compare January 2, 2020 12:43

yaacov reviewed Jan 2, 2020

View reviewed changes

irosenzw force-pushed the add-validation-feature branch from 6397059 to e634b24 Compare January 2, 2020 14:58

yaacov reviewed Jan 2, 2020

View reviewed changes

atiratree suggested changes Jan 3, 2020

View reviewed changes

irosenzw force-pushed the add-validation-feature branch from e634b24 to 41051ac Compare January 5, 2020 16:15

yaacov reviewed Jan 5, 2020

View reviewed changes

irosenzw force-pushed the add-validation-feature branch from 41051ac to 01326b7 Compare January 6, 2020 14:53

irosenzw force-pushed the add-validation-feature branch from 01326b7 to 9d7481f Compare January 6, 2020 16:19

yaacov reviewed Jan 6, 2020

View reviewed changes

openshift-ci-robot assigned yaacov Jan 6, 2020

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

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

openshift-merge-robot merged commit 4ac553e into openshift:master Jan 6, 2020

yaacov added a commit to yaacov/console that referenced this pull request Jan 7, 2020

nitpicks from openshift#3839

4f3e112

yaacov added a commit to yaacov/console that referenced this pull request Jan 7, 2020

nitpicks from openshift#3839

46ac9c9

yaacov added a commit to yaacov/console that referenced this pull request Jan 7, 2020

nitpicks from openshift#3839

cef6398

yaacov mentioned this pull request Jan 7, 2020

Nitpicks from #3839 #3879

Merged

yaacov added a commit to yaacov/console that referenced this pull request Jan 8, 2020

nitpicks from openshift#3839

0847488

yaacov added a commit to yaacov/console that referenced this pull request Jan 8, 2020

nitpicks from openshift#3839

325b4ef

yaacov added a commit to yaacov/console that referenced this pull request Jan 8, 2020

nitpicks from openshift#3839

e14d085

openshift-merge-robot added a commit that referenced this pull request Jan 9, 2020

Merge pull request #3879 from yaacov/kubevirt-memeory-cleanups

cab16cd

Nitpicks from #3839

spadgett added this to the v4.4 milestone Jan 14, 2020

a2batic pushed a commit to a2batic/console that referenced this pull request Jan 16, 2020

nitpicks from openshift#3839

c288d43

rebeccaalpert pushed a commit to rebeccaalpert/console that referenced this pull request Jan 20, 2020

nitpicks from openshift#3839

b7deb6e

Add memory validations in the VM wizard #3839

Add memory validations in the VM wizard #3839

Conversation

irosenzw commented Dec 30, 2019

irosenzw commented Dec 30, 2019

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

yaacov Dec 31, 2019 • edited

Choose a reason for hiding this comment

yaacov Dec 31, 2019 • edited

Choose a reason for hiding this comment

yaacov Dec 31, 2019 • 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

atiratree Jan 3, 2020 • edited

Choose a reason for hiding this comment

irosenzw Jan 5, 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

irosenzw Jan 5, 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

atiratree Jan 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

yaacov commented Jan 6, 2020

openshift-ci-robot commented Jan 6, 2020

openshift-bot commented Jan 6, 2020

openshift-bot commented Jan 6, 2020

yaacov Dec 31, 2019 •

edited

yaacov Dec 31, 2019 •

edited

yaacov Dec 31, 2019 •

edited

atiratree Jan 3, 2020 •

edited

irosenzw Jan 5, 2020 •

edited

irosenzw Jan 5, 2020 •

edited

atiratree Jan 3, 2020 •

edited