[Sample test] Add parameterized_tfx_oss to 'normal' sample test corpus

[numerology]

Previously we maintain a precompiled .tar.gz package of the sample and test against that, which introduces several issues:

1. Compatibility b/w TFX and KFP SDK is not tested here;
2. Need a lot of special treatment in the sample test infra to skip compilation and so on;
3. The versions of SDK and image used in this sample are tricky. Users might get confused. It's better to give users the opportunities to compile it on their own.

Provided that TFX 0.15.0 has been released (and stablized) for a while. I think it's reasonable to attempt to treat this one as other sample tests.

---

This change is 

[numerology]

/cc @Bobgy I think the error you mentioned the other day is probably because, MLMD currently uses pipeline name as the unique id for each pipeline, as well as the runtime context associated with it. One implication of that is, if you make some change to the pipeline spec and submit it again under the same pipeline name, some schema checks might fail.

[numerology]

/test kubeflow-pipeline-e2e-test

[numerology]

/retest

[numerology]

/retest

[Bobgy]

/cc @Bobgy I think the error you mentioned the other day is probably because, MLMD currently uses pipeline name as the unique id for each pipeline, as well as the runtime context associated with it. One implication of that is, if you make some change to the pipeline spec and submit it again under the same pipeline name, some schema checks might fail.

Thanks! That makes sense. Sounds like this is something we should document to users too. It would be impossible to debug this issue for end users.

[numerology]

/hold fixing the tests

[Ark-kun]

if you make some change to the pipeline spec and submit it again under the same pipeline name, some schema checks might fail.

I wonder how this could happen.

MLMD has three typed objects - Context, Execution and Artifact. There is no entity that corresponds to "pipeline" (or "component").

[numerology]

if you make some change to the pipeline spec and submit it again under the same pipeline name, some schema checks might fail.

I wonder how this could happen.

MLMD has three typed objects - Context, Execution and Artifact. There is no entity that corresponds to "pipeline" (or "component").

Good question. Execution is 'somewhat' a realization of component. See here for its def. Basically the ExecutionType under the same context cannot change, and ExecutionType contains input/output types and properties. Then, virtually one cannot change component interface without changing pipeline name.

[numerology]

/hold cancel
Tests are passing.

[Ark-kun]

/lgtm

[numerology]

/approve

Thanks!

[numerology]

/assign @IronPan

[Ark-kun]

@numerology If you had any issues debugging the failures during this PR preparation, you can create issues tracking them.

[numerology]

@numerology If you had any issues debugging the failures during this PR preparation, you can create issues tracking them.

I'll say mostly it's because I'm not familiar with the logic of initialization test...However the lack of log/feedback contributes to the mess as well. Will think about how to improve this. Thanks.

[IronPan]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: IronPan, numerology

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:

• backend/OWNERS [IronPan]
• samples/OWNERS [IronPan,numerology]
• test/sample-test/OWNERS [IronPan,numerology]

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