-
Notifications
You must be signed in to change notification settings - Fork 237
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
Edit VM instead of VMI when exposing service objects #698
Comments
To be even more specific: It seems like one must specify the label on the VM and on the VMI object (inside the template section of the VM resource). When specifying the VM as follows, I was able to expose VM ports via NodePort service objects:
|
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with /lifecycle stale |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with /lifecycle rotten |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with /lifecycle stale |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with /lifecycle rotten |
/remove-lifecycle rotten |
Hi! I was wondering if this method of exposing the VM ports has been confirmed. If so, should this VM specification @drssdinblck commented be added to the doc? |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with /lifecycle stale |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with /lifecycle rotten |
Rotten issues close after 30d of inactivity. /close |
@kubevirt-bot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
/remove-lifecycle rotten |
/assign |
@aburdenthehand please take a look. |
The service objects doc currently specify users edit the VMI object, however it seems as though this should be done on the VM (and restart if running).
This was raised on this thread: https://kubernetes.slack.com/archives/C8ED7RKFE/p1688475040764709
If this is the case, we should update this doc:
https://github.com/kubevirt/user-guide/blame/main/docs/virtual_machines/service_objects.md
The text was updated successfully, but these errors were encountered: