Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SDK/DSL: Make 'name' argument of a PipelineVolume omittable #1402

Merged
merged 3 commits into from
Jun 14, 2019

Conversation

elikatsis
Copy link
Member

@elikatsis elikatsis commented May 30, 2019

This PR makes the creation of a PipelineVolume without specifying a name possible.
The name of the volume is an orchestration detail [1] that the user should be able to be agnostic about.

I also removed any unused imports from the _pipeline_volume module.

[1]: It is only needed for the matching of volumeMounts with the volume entries.


This change is Reviewable

Also remove unused imports from _pipeline_volume module

Signed-off-by: Ilias Katsakioris <elikatsis@arrikto.com>
init_volume = {"name": kwargs.pop("name")
if "name" in kwargs else None}
init_volume = {"name": kwargs.pop("name") if "name" in kwargs
else "pvolume-%s" % id(self)}
Copy link
Contributor

@Ark-kun Ark-kun May 30, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be better to use a stable hash (e.g. SHA256) of serialized volume structure instead of id.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The thing here is that we need to select a name in order to call super().__init__() which defines and fills the object's fields.
What does the structure contain before that? And if we do serialize the structure before the actual init(), wouldn't we get the same hash for every PipelineVolume? (since the input of the function will be the same empty structure)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand that the designs where the ID/name is part of the structure make hashing problematic.
What I did was setting an empty id/name during creation, then hashing the structure and then setting the id/name based on the hash. Do you think this is appropriate here? The advantage is that the compiled pipeline is not changing with every rebuild.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I implemented your suggestion.
First, I used a placeholder for the name.
Then, I used the to_dict() method the Kubernetes model has (I think there is no need to convert it the same way the compiler does, i.e. proper yaml representation).
Finally, I hashed the str() representation of that dictionary.

What do you think?
Also, take a look at the test. Since the name is the same, I assertEqual() with the name it should have, hard-coded. Should I leave it like this, delete the test, or perform the same actions in the test function (create a volume with the placeholder name and hash it) and then compare them?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test will sometimes fail since python dict is not ordered, thus the str(self.to_dict()) is not deterministic.

@k8s-ci-robot k8s-ci-robot added size/M and removed size/S labels Jun 3, 2019
@elikatsis elikatsis force-pushed the feat-omit-pipelinevolume-name branch from 4fe1fae to a58c304 Compare June 3, 2019 11:49
@elikatsis
Copy link
Member Author

I had made a silly mistake not maintaining the provided name.

@elikatsis
Copy link
Member Author

Hey @Ark-kun, could you go through this?

@Ark-kun
Copy link
Contributor

Ark-kun commented Jun 14, 2019

/lgtm
/approve

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Ark-kun

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:

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

@k8s-ci-robot k8s-ci-robot merged commit d4960d3 into kubeflow:master Jun 14, 2019
@Ark-kun
Copy link
Contributor

Ark-kun commented Jun 18, 2019

/test kubeflow-pipeline-sample-test

@elikatsis elikatsis deleted the feat-omit-pipelinevolume-name branch March 9, 2020 14:49
magdalenakuhn17 pushed a commit to magdalenakuhn17/pipelines that referenced this pull request Oct 22, 2023
…oller (kubeflow#1402)

* Validated that the inference service is ready otherwise throw error

* Add test casee for when inference service is not ready

* Added condition functions and condition InferenceServiceReady

* Add check for trained model condition InferenceServiceReady

* Set the condition for InferenceServiceReady

* Updated status and returned if conditions are false

* Add check for InferenceServiceReady condition in updating a trained model

* newline

* Add more ready conditions

* Update conditions status after setting conditions

* Removed trained model name as event is already on tm
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants