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

More container fields for SuggestionConfig #2000

Conversation

fischor
Copy link
Contributor

@fischor fischor commented Nov 5, 2022

What this PR does / why we need it:

This PR adds more fields to the SuggestionConfig that is used to populate the main container of the Suggestion deployment. It adds fields command, args, envs that can be used to pass arguments to the executable. This allows the user to easily parametrize the suggestion algorithm/executable itself by passing values using these new fields.

Which issue(s) this PR fixes:
Fixes #1737 (at least partly)

Checklist:

  • Docs: the docs will need to mention the new fields

@fischor fischor force-pushed the issue-1737-more-fields-in-suggestion-config branch from 7081489 to c6f87bd Compare November 5, 2022 17:49
Copy link
Member

@andreyvelich andreyvelich left a comment

Choose a reason for hiding this comment

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

Thank you for taking this @fischor!

Args []string `json:"args,omitempty"`
WorkingDir string `json:"workingDir,omitempty"`
EnvFrom []corev1.EnvFromSource `json:"envFrom,omitempty"`
Env []corev1.EnvVar `json:"env,omitempty"`
Copy link
Member

@andreyvelich andreyvelich Nov 8, 2022

Choose a reason for hiding this comment

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

Maybe we could start adding more fields to SuggestionConfig with corev1.Container{} field, similar to PodSpec API in K8s ? I think you can use inline param to avoid modification in existing Katib config YAML:

 corev1.Container `json:",inline"`

I guess, at the end we want to give user ability to modify the whole Suggestion's Deployment spec via Katib config, but it requires much more changes.

WDYT @tenzen-y @johnugeorge @fischor ?

Copy link
Member

Choose a reason for hiding this comment

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

Maybe we could start adding more fields to SuggestionConfig with corev1.Container{} field, similar to PodSpec API in K8s ? I think you can use inline param to avoid modification in existing Katib config YAML

sgtm

I guess, at the end we want to give user ability to modify the whole Suggestion's Deployment spec via Katib config, but it requires much more changes.

I think so too. Maybe, to support customizing Tolerations, imagePullSecret and so on, we want to support customizing PodSpec for suggestion service deployment.

Copy link
Contributor Author

@fischor fischor Nov 8, 2022

Choose a reason for hiding this comment

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

Yes, inlining corev1.Container would also be an option.
Certain fields of the container will be set by the katib-Controller, like some ports, the liveness and readiness probes and possibly the "suggestion-volume". How to handle these? Overwrite or not?

I think so too. Maybe, to support customizing Tolerations, imagePullSecret and so on, we want to support customizing PodSpec for suggestion service deployment.

To support his, how about specifying a default deployment in the suggestion config (instead of just the container)?.

Copy link
Member

Choose a reason for hiding this comment

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

For namespace specific specific suggestion deployments, we can allow to have a configmap in a user namespace(where experiment is run). If suggestion spec is provided in the configmap of the user namespace, it can override the global katib config.
Ref: #1976

Copy link
Member

Choose a reason for hiding this comment

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

Certain fields of the container will be set by the katib-Controller, like some ports, the liveness and readiness probes and possibly the "suggestion-volume". How to handle these? Overwrite or not?

@fischor I think if parameters are set by the user we should use them, otherwise use the default values.

To support his, how about specifying a default deployment in the suggestion config (instead of just the container)?.

We might want to set spec.template.spec for our Suggestion config, as I mentioned here: #1737 (comment), but that requires much more changes since we need to modify manifests.

If suggestion spec is provided in the configmap of the user namespace, it can override the global katib config.

@johnugeorge That might be the next step. We need to have discussion what is the best way to give user ability to set experiment-scoped Katib Config.

Copy link
Member

Choose a reason for hiding this comment

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

Sorry for the late response.

We might want to set spec.template.spec for our Suggestion config, as I mentioned here: #1737 (comment), but that requires much more changes since we need to modify manifests.

As the first step, in this PR, we might be good to provide only the feature to be able to customize the corev1.Container{}.

For namespace specific specific suggestion deployments, we can allow to have a configmap in a user namespace(where experiment is run). If suggestion spec is provided in the configmap of the user namespace, it can override the global katib config.
Ref: #1976

This is a good idea. As mentioned @ andreyvelich, I also think we would be able to discuss about the feature on the next step.

@coveralls
Copy link

coveralls commented Nov 8, 2022

Coverage Status

Coverage: 73.247% (+0.8%) from 72.455% when pulling 6cc917e on fischor:issue-1737-more-fields-in-suggestion-config into 54b020b on kubeflow:master.

@google-oss-prow google-oss-prow bot added size/M and removed size/S labels Nov 14, 2022
@fischor fischor requested review from andreyvelich and removed request for sperlingxx and anencore94 November 14, 2022 19:40
@johnugeorge
Copy link
Member

@fischor Can you rebase and fix?

@fischor
Copy link
Contributor Author

fischor commented Dec 17, 2022

The name of the suggestion algorithm container was not defaulted. Creating the suggestion deployment failed because of a missing container name.

@johnugeorge I have rebased and fixed.

Image string `json:"image"`
ImagePullPolicy corev1.PullPolicy `json:"imagePullPolicy,omitempty"`
Resource corev1.ResourceRequirements `json:"resources,omitempty"`
corev1.Container `json:",inline"`
ServiceAccountName string `json:"serviceAccountName,omitempty"`
VolumeMountPath string `json:"volumeMountPath,omitempty"`
Copy link
Member

Choose a reason for hiding this comment

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

@fischor Do we need VolumeMountPath if that is part of Container parameters:

if s.Spec.ResumePolicy == experimentsv1beta1.FromVolume && len(suggestionContainer.VolumeMounts) == 0 {
?

Copy link
Contributor Author

@fischor fischor Dec 22, 2022

Choose a reason for hiding this comment

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

The current Katib SuggestionConfig has a JSON field volumeMountPath thats just a filepath, the corev1.Container has a json field volumeMounts thats an array of volume mounts. So volumeMountPath is not part if the container fields. I think in order to not break anything, we need it.

The referenced snippet kind of follows the logic:

... if parameters are set by the user we should use them, otherwise use the default values.

In case the volumeMounts are set we prefer that, otherwise mount the default suggestion volume under the specificed volumeMountPath.

Copy link
Member

Choose a reason for hiding this comment

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

I see, that is because we set the default value name for Suggestion Volume. Please can you leave comment that we should refactor VolumeMountPath parameter once we allow to set Deployment spec in our Suggestion config ?

Also, I think we should modify len(suggestionContainer.VolumeMounts) == 0 check.
We always should append VolumeMount if ResumePolicy is FromVolume.

if s.Spec.ResumePolicy == experimentsv1beta1.FromVolume {
volumeMount := corev1.VolumeMount{
	Name:      consts.ContainerSuggestionVolumeName,
	MountPath: suggestionConfigData.VolumeMountPath,
}
suggestionContainer.VolumeMounts = append(suggestionContainer.VolumeMounts, volumeMount)
}

WDYT @fischor ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@andreyvelich Have you seen that the consts.DefaultSuggestionPortName port is also just set if the Container specified in the suggestion has no ports set? See https://github.com/fischor/katib/blob/7f1b2842f87158c25c54f577da1b82ddc7a958e3/pkg/controller.v1beta1/suggestion/composer/composer.go#L194-L201
Would you also change that to always append the default port?

I think both ways of doing this have pros/cons. If we always append the default volume/port then the user has no option to overwrite it. If we never append the default volume/port, then the user needs to be aware that it has to specify it when setting any volumes/ports.

A third option would be to check if the default volume/port is already set in the container and only append if its not. I think I would prefer that.

Copy link
Member

@andreyvelich andreyvelich Jan 3, 2023

Choose a reason for hiding this comment

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

A third option would be to check if the default volume/port is already set in the container and only append if its not. I think I would prefer that.

I think that should work, but we need to make sure that volume and port name/number is correct (ContainerSuggestionVolumeName and DefaultSuggestionPortName/DefaultSuggestionPort ).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@andreyvelich I have added check to only append a VolumeMount for the Suggestion Volume only in case no volume mount with that default name ("suggestion-volume") exists. And a check to only append a ContainerPort for the Suggestion API in case no port with the default suggestion api port name and/or port number exists.

@google-oss-prow google-oss-prow bot added size/L and removed size/M labels Jan 15, 2023
Comment on lines 198 to 199
if !containsContainerPortWithName(suggestionContainer.Ports, consts.DefaultSuggestionPortName) &&
!containsContainerPort(suggestionConfigData.Ports, consts.DefaultSuggestionPort) {
Copy link
Member

@andreyvelich andreyvelich Jan 16, 2023

Choose a reason for hiding this comment

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

Should we verify that port name and containerPort is set together in the Katib Config ?
DefaultSuggestionPortName and DefaultSuggestionPort is always used for the Suggestion's service.
So if user set DefaultSuggestionPortName port with different address, the Suggestion service fails.

cc @tenzen-y

Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Member

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 prohibit setting containerPort in katibConfig.

Copy link
Member

Choose a reason for hiding this comment

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

We should add a validation check either ways.

Copy link
Member

@andreyvelich andreyvelich Jan 23, 2023

Choose a reason for hiding this comment

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

@fischor Do you have time to check my latest message ? We are getting closer for the Katib 0.15 release, and it would be great to include your feature in that release.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@andreyvelich I should have some spare time tomorrow. Do we do it as you suggested: verify that name and port are correct, otherwise return an error in DesiredDeployment method? Or prohibit the DefaultSuggestionPort to be set at all?

Copy link
Member

Choose a reason for hiding this comment

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

@fischor Thank you! Let's prohibit to set DefaultSuggestionPort for now as @tenzen-y suggested. So we can avoid errors from the user side.

Copy link
Member

Choose a reason for hiding this comment

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

@fischor We are planning to cut a release in a day. Do you have any update?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@johnugeorge Thanks for the reminder...you can check the latest commit now.

@andreyvelich
Copy link
Member

andreyvelich commented Jan 25, 2023

Thank you for updates @fischor.
Excited to see a new usage of Katib config!
/lgtm
/approve

@google-oss-prow
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andreyvelich, fischor

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

@tenzen-y
Copy link
Member

@fischor Great work!
Thanks for your effort!

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.

Support users to set more fields in suggetion deployment
5 participants