theforeman
Fixes #38948 - Add power state bulk action to new host overview page
- Implemented both backend and frontend parts of the bulk power state feature
- Added backend unit tests
- Implemented new endpoint for changing the power state
- Synced power state updates with the power status icon
Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all
Hi @alaypatel07 Fyi please
is it fine for the non network DRA devices as well ? if it isn't we will need both
@oshoval This PR needs to wait for this issue to be resolved: https://github.com/kubernetes/kubernetes/issues/134569
There is a PR open for it https://github.com/kubernetes/enhancements/pull/5669 awaiting reviews. Once this PR is merged, we can start using this attribute.
@oshoval This PR needs to wait for this issue to be resolved: kubernetes/kubernetes#134569
There is a PR open for it kubernetes/enhancements#5669 awaiting reviews. Once this PR is merged, we can start using this attribute.
Thanks @alaypatel07
since it is behind a FG, and will help advancing meanwhile,
maybe lets merge the current PR meanwhile, and if needed rename it to pciBusID on both Kubevirt and once needed https://github.com/k8snetworkplumbingwg/dra-driver-sriov ?
as long as it doesn't affect other DRA devices, it should be safe imho
@oshoval yeah it makes sense to iterate faster, in that case can you avoid taking a dependency on "k8s.io/dynamic-resource-allocation/deviceattribute" and hardcode the name like it was before?
@oshoval yeah it makes sense to iterate faster, in that case can you avoid taking a dependency on
"k8s.io/dynamic-resource-allocation/deviceattribute"and hardcode the name like it was before?
since we use the dependency only for the prefix resource.kubernetes.io atm
we will need it either way it seems in the future, so it is fine to keep it imho, wdyt ?
if not, you prefer to hardcode it as resource.kubernetes.io/pciAddress ?
We already doing same on dra driver, so this is another reason it is better to have official consts
if not, you prefer to hardcode it as resource.kubernetes.io/pciAddress ?
yes this would be my preference, out of abundance of safety. This is to make sure that others dont start building stuff around the official unmerged open PRs. And while you are at this, can you also change the hardcoded resource.kubernetes.io/mDevUUID to mdevUUID, ref: https://kubernetes.slack.com/archives/C0409NGC1TK/p1764687884228119?thread_ts=1764687710.269999&cid=C0409NGC1TK
if not, you prefer to hardcode it as resource.kubernetes.io/pciAddress ?
yes this would be my preference, out of abundance of safety. This is to make sure that others dont start building stuff around the official unmerged open PRs. And while you are at this, can you also change the hardcoded
resource.kubernetes.io/mDevUUIDtomdevUUID, ref: https://kubernetes.slack.com/archives/C0409NGC1TK/p1764687884228119?thread_ts=1764687710.269999&cid=C0409NGC1TK
done ptal
done https://github.com/kubevirt/kubevirt/pull/16249#discussion_r2581676112
@alaypatel07 about the mDevUUID are you sure to remove the prefix? should it contain any prefix?
/hold
seems it doesnt work with pciBusID, checking
maybe it is just because of the kubelet bug
note please that i didnt test the mDevUUID, maybe better to delegate it to a follow-up
@iholder101 / @xpivarc can you guys please bless this PR, its a small one, thanks!
@SchSeba: changing LGTM is restricted to collaborators
In response to this:
LGTM nice work :)
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.
/approve Attribute was accepted into KEP - https://github.com/kubernetes/enhancements/pull/5669
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: enp0s3
The full list of commands accepted by this bot can be found here.
The pull request process is described here
- ~~OWNERS~~ [enp0s3]
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
Required labels detected, running phase 2 presubmits: /test pull-kubevirt-e2e-k8s-1.34-windows2016 /test pull-kubevirt-e2e-kind-1.33-vgpu /test pull-kubevirt-e2e-kind-sriov /test pull-kubevirt-e2e-k8s-1.34-ipv6-sig-network /test pull-kubevirt-e2e-k8s-1.32-sig-network /test pull-kubevirt-e2e-k8s-1.32-sig-storage /test pull-kubevirt-e2e-k8s-1.32-sig-compute /test pull-kubevirt-e2e-k8s-1.32-sig-operator /test pull-kubevirt-e2e-k8s-1.33-sig-network /test pull-kubevirt-e2e-k8s-1.33-sig-storage /test pull-kubevirt-e2e-k8s-1.33-sig-compute /test pull-kubevirt-e2e-k8s-1.33-sig-operator
/retest-required
This bot automatically retries required jobs that failed/flaked on
required test lanes of PRs.
Silence the bot with an /lgtm cancel or /hold comment for consistent failures.
/retest-required
This bot automatically retries required jobs that failed/flaked on
required test lanes of PRs.
Silence the bot with an /lgtm cancel or /hold comment for consistent failures.
✋🧢
/hold
Dear @oshoval
⚠️ this pull request exceeds the number of retests that are allowed per individual commit.
🔎 Please check that the changes you committed are fine and that there are no infrastructure issues present!
- [ ] your changes compile
- [ ] your tests succeed locally, i.e. for k/kubevirt see
- [ ] no linting errors
- [ ] no recurring e2e test errors, i.e. in the
pull-kubevirt-check-tests-for-flakeslane - [ ] no infrastructure issues, i.e.
- GitHub Status,
- quay.io status at status.redhat.com or
- KubeVirt prow status
💬 How we calculate the number of retests: The number of retest comments are the number of /test or /retest comments after the latest commit only.
👌 After all issues have been resolved, you can remove the hold on this pull request by commenting /unhold on it.
🙇 Thank you, your friendly referee automation, on behalf of the @sig-buildsystem and the KubeVirt community!