hooks: deprecate v1alpha1 & v1alpha2 #10842

victortoso · 2023-12-05T20:51:47Z

This patch marks the whole hooks/v1alpha1 and hooks/v1alpha2 as deprecated. Users should prefer use:

v1alpha3: introduced in v1.2.0 (to be released) with 613f0fe "hooks: Add v1alpha3 with Shutdown method" in 2023-11-27

This patch also includes the result of make generate.

What this PR does / why we need it:
On v1.2.0 release, the hooks will have three versions:

We should avoid supporting too many versions as the code gets more complex to maintain. There are minimal changes to move from v1alpha1 to v1alpha2 and the same amount of work to move from v1alpha2 to v1alpha3.

I propose we deprecate v1alpha1 and v1alpha2 on KubeVirt v1.2.0 and remove it by KubeVirt v1.3.0.

A formal proposal to promote to Beta and GA is being added with kubevirt/community#252

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

Special notes for your reviewer:

This is just a formal deprecation.

Added a admitter hook check, that warns when v1alpha1 and v1alpha2 is used
A runtime is also logged when using sidecar with the deprecated version

Checklist

This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

Design: A design document was considered and is present (link) or not required
PR: The PR description is expressive enough and will help future contributors
Code: Write code that humans can understand and Keep it simple
Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
Upgrade: Impact of this change on upgrade flows was considered and addressed if required
Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
Community: Announcement to kubevirt-dev was considered

Release note:

Deprecate hooks v1alpha1 and v1alpha2

alicefr · 2023-12-06T09:05:20Z

I'm all in! However, please send a note on kubevirt mailing list for more visibility

victortoso · 2023-12-06T10:04:07Z

For the record, just sent an email for awareness: https://groups.google.com/g/kubevirt-dev/c/HUdW66Elfs4

alicefr · 2023-12-06T15:15:47Z

/assign

vasiliy-ul

AFAIK we do not have a deprecation policy in place, hence this will need some discussions. But I think deprecating and removing very old stuff is unavoidable if we want to keep the code maintainable.

vasiliy-ul · 2023-12-07T07:36:20Z

pkg/hooks/v1alpha1/api_v1alpha1.proto

+    rpc OnDefineDomain (OnDefineDomainParams) returns (OnDefineDomainResult) {
+        option deprecated = true;
+    };


If I understand correctly, this will produce a build-time warning if someone uses the call, right? I think it would be nice to have something at runtime as well. Perhaps the VM admission webhook can generate a warning if hooks.kubevirt.io/hookSidecars annotation is used with --version v1alpha1.

0xFelix · 2023-12-07T08:21:26Z

What do you think about going one step further and deprecating v1alpha2 as well? If KubeVirt 1.2.0 is too fast for deprecation of v1alpha2, then deprecate it in KubeVirt 1.3.0 instead?

alicefr · 2023-12-07T09:01:49Z

AFAIK we do not have a deprecation policy in place, hence this will need some discussions. But I think deprecating and removing very old stuff is unavoidable if we want to keep the code maintainable.

No. unfortunately we don't have it. @iholder101 was working on some guidelines and now there is @EdDev's proposal kubevirt/community#251

EdDev · 2023-12-07T12:39:50Z

AFAIK we do not have a deprecation policy in place, hence this will need some discussions. But I think deprecating and removing very old stuff is unavoidable if we want to keep the code maintainable.

No. unfortunately we don't have it. @iholder101 was working on some guidelines and now there is @EdDev's proposal kubevirt/community#251

As I see it, there is basically no need to deprecate anything.
This is an Alpha version, which implies experiments usage and therefore all risk is on the one who uses it.

This API does not fall under the "feature" category, therefore it falls between the cracks a bit.

Except marking the version deprecated and anouncing it, what would be the benefit to drop it now?
I would also consider raising a design proposal to graduate the hook API or drop it.
Graduation path may include braking changes, so it is an opportunity to think for the long run now.

alicefr · 2023-12-08T07:27:25Z

AFAIK we do not have a deprecation policy in place, hence this will need some discussions. But I think deprecating and removing very old stuff is unavoidable if we want to keep the code maintainable.

No. unfortunately we don't have it. @iholder101 was working on some guidelines and now there is @EdDev's proposal kubevirt/community#251

As I see it, there is basically no need to deprecate anything. This is an Alpha version, which implies experiments usage and therefore all risk is on the one who uses it.

This API does not fall under the "feature" category, therefore it falls between the cracks a bit.

Except marking the version deprecated and anouncing it, what would be the benefit to drop it now? I would also consider raising a design proposal to graduate the hook API or drop it. Graduation path may include braking changes, so it is an opportunity to think for the long run now.

@EdDev is a design proposal a bit excessive for graduating an API? I mean, this isn't a new feature, what will you describe there?
The benefit of dropping the API now is that we recently introduced the v1alpha3 API and supporting 3 API versions is a bit too much.

EdDev · 2023-12-10T03:24:59Z

@EdDev is a design proposal a bit excessive for graduating an API? I mean, this isn't a new feature, what will you describe there?

If the feature had a prev proposal, it could have been updated to reflect new suggestion changes and progress.

The idea would be to allow discussion at the design and plan level.

For example, keeping the feature and API in Alpha stage is problematic. There is no commitment for support and future extensions are considered only through the api version, which is odd.

The benefit of dropping the API now is that we recently introduced the v1alpha3 API and supporting 3 API versions is a bit too much.

Fair.
But please be aware that unless we plan a graduation path, we will start to loose trust on this hook API.

victortoso · 2023-12-11T05:52:49Z

As I see it, there is basically no need to deprecate anything.
This is an Alpha version, which implies experiments usage and therefore all risk is on the one who uses it.

Right.

I would also consider raising a design proposal to graduate the hook API or drop it.

Considering all the recent work around sidecars (passt/slirp, debugability), I'm sure we don't want to drop it.

But please be aware that unless we plan a graduation path, we will start to loose trust on this hook API.

@EdDev what would you suggest for the graduation process? Based on Feature Stages, we should move it to Beta. Should we open a design proposal to discuss it?

With regards to the hooks alpha API, it might be alpha but we are using it like it is not. (e.g: it would hurt if remove it)

So, in my opinion we can take @0xFelix suggestion, mark both v1alpha1 and v1alpha2 deprecated for KubeVirt v1.2.0. This is for awareness only. As @vasiliy-ul suggested, we can use a webhook to warn developers and users.

EdDev · 2023-12-11T18:42:04Z

@EdDev what would you suggest for the graduation process? Based on Feature Stages, we should move it to Beta. Should we open a design proposal to discuss it?

If there was a design proposal in the past, we could re-open it and change it to express the planning and new ideas.
If there was none, then IMO we should open one based on the template, as if we start from scratch.
The plan can describe what was done already and continue with what the ideas of the future are.

I am also in favor of targeting towards Beta in the next release.

With regards to the hooks alpha API, it might be alpha but we are using it like it is not. (e.g: it would hurt if remove it)

I agree. A good reason to proceed with Beta and hopefully GA.

So, in my opinion we can take @0xFelix suggestion, mark both v1alpha1 and v1alpha2 deprecated for KubeVirt v1.2.0. This is for awareness only. As @vasiliy-ul suggested, we can use a webhook to warn developers and users.

I would start with announcing the intention on the googlegroup and the community meeting, add this to the design plan and eventually post a PR for adding warnings. If we move to Beta in the same version, it will send a message that we are serious to stabilize this API.

The webhooks are handling the K8S API, not internal API/s.
If you mean the hook annotation that trigger the use of the hook API, I think this will be fine but partial.
The network binding plugin is already using the internal hook API without that annotation.

victortoso · 2023-12-12T10:39:55Z

I would start with announcing the intention on the googlegroup and the community meeting

Sadly, the community meeting conflicts with another one that I have. I'll try to attend this week. Note that I did send an email to google groups about this deprecation, it is:
https://groups.google.com/g/kubevirt-dev/c/HUdW66Elfs4

add this to the design plan and eventually post a PR for adding warnings. If we move to Beta in the same version, it will send a message that we are serious to stabilize this API.

I started to draft the proposal, an early version is here:
kubevirt/community#252

Let's make the graduation of the hooks API happen.

The webhooks are handling the K8S API, not internal API/s.
If you mean the hook annotation that trigger the use of the hook API, I think this will be fine but partial.
The network binding plugin is already using the internal hook API without that annotation.

Yes, you are right. The --version arg is not really mandatory. I think we can instead add Warnings around hook/manager, when it Collects the version of the sidecar, should warn that it is using a deprecated version. I'll try to do that next.

kubevirt-bot · 2023-12-12T20:36:16Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from alicefr. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

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

victortoso · 2023-12-12T20:54:42Z

Updated with the runtime check for deprecation. It is just a warning on virt-launcher log, @vasiliy-ul do you think that would suffice?

Just to clarify, my suggestion is to:

Deprecate both v1alpha1 and v1alpha2;
Discuss when it'll be ok to remove deprecated versions and about promoting v1alpha3 to beta in Adding a proposal for existing hooks sidecar community#252

EdDev · 2023-12-13T07:11:40Z

/cc

vasiliy-ul · 2023-12-13T07:41:29Z

Updated with the runtime check for deprecation. It is just a warning on virt-launcher log, @vasiliy-ul do you think that would suffice?

A warning in the log is for sure useful. Though, I was rather thinking about smth similar to how it's done for virtualmachinepreset in the admission webhook:

kubevirt/pkg/virt-api/webhooks/mutating-webhook/mutators/vmi-mutator.go

Lines 161 to 171 in 4ede357

    
           // If newVMI has been annotated with presets include a deprecation warning in the response 
        
           for annotation := range newVMI.Annotations { 
        
           	if strings.Contains(annotation, "virtualmachinepreset") { 
        
           		return &admissionv1.AdmissionResponse{ 
        
           			Allowed:   true, 
        
           			Patch:     patchBytes, 
        
           			PatchType: &jsonPatchType, 
        
           			Warnings:  []string{presetDeprecationWarning}, 
        
           		} 
        
           	} 
        
           }

If I understand correctly, this raises a warning when you try to run a VM with kubectl apply -f ... and that VM contains the presets annotation. Perhaps something similar would be nice to have for the hooks API.

dharmit · 2024-01-04T11:10:58Z

nit: the "Introduction" section of the current README could also be updated as a part of this PR to reflect that only one version is supported.

0xFelix · 2024-01-08T09:42:11Z

pkg/hooks/manager.go

-		hooksV1alpha2.Version,
-		hooksV1alpha1.Version,
+	supportedVersions := map[string]bool{
+		hooksV1alpha3.Version: hooksV1alpha3.Deprecated,


Doesn't this mark v1alpha3 as deprecated too?

@0xFelix Deprecated is a boolean, for v1alpha3 it is false, the other two is true

Ah! My mistake, this pattern caught me off guard. What about a list of deprecated versions that you only maintain in manager.go? You need to touch this file anyways when adding a new API version. This way you would get a direct overview of deprecated versions when looking at the code?

Sorry, I missed your comment.

What about a list of deprecated versions that you only maintain in manager.go?

I can add it, I think it would be beneficial to avoid doing:

// Check for deprecated APIs being used. hookVersions := map[string]bool{ hooksv1alpha3.Version: hooksv1alpha3.Deprecated, hooksv1alpha2.Version: hooksv1alpha2.Deprecated, hooksv1alpha1.Version: hooksv1alpha1.Deprecated, }

but I think the deprecation value should still be part of each version module, like the Version string.

https://github.com/victortoso/kubevirt/blob/deprecate-hooks-v1alphav1/pkg/hooks/manager.go#L59

victortoso · 2024-01-11T14:33:56Z

/retest

victortoso · 2024-01-11T17:53:34Z

/retest

alicefr · 2024-01-12T12:33:26Z

hi @victortoso the code looks good to me. However, we should probably merge the design proposal before this. I'll have a look to it

alicefr · 2024-01-12T12:33:45Z

/lgtm

EdDev

Thank you.
I think the promotion to Beta should be discussed in parallel to this change and the design finalized.

While working on a sidecar lately, I realized we do have a problem with its implementation which makes it hard to extend in a reasonable way.
But this fits a design or a meeting discussion, not here.

EdDev · 2024-01-14T07:46:28Z

pkg/hooks/manager.go

+var DeprecatedVersions = map[string]bool{
+	hooksV1alpha3.Version: hooksV1alpha3.Deprecated,
+	hooksV1alpha2.Version: hooksV1alpha2.Deprecated,
+	hooksV1alpha1.Version: hooksV1alpha1.Deprecated,
+}
+
+// The order matters. Newest versions first.
+var SupportedVersions = []string{
+	hooksV1alpha3.Version,
+	hooksV1alpha2.Version,
+	hooksV1alpha1.Version,
+}


It will be nicer to avoid changing these slices in the future here.
The versions could be registered by the individual package/file through an init(), leaving here only the infrastructure.

Sorry, I did not understand your suggestion. While we are alpha/beta, what is the problem with the slice of versions and map of deprecation? What is the change you would like to see here?

I meant adding this to the specific version/s:

func init() { RegisterSupportedVersion(version) RegisterDeprecatedVersion(version) }

And implement this at the manager:

func RegisterSupportedVersion(ver string) { supportedVersions = append(supportedVersions, ver) }

etc...

Ah, I see what you mean now.

One problem would be the order. We can't guarantee the order using init(), can we?

@EdDev ping on above question.

Sorry, seems I have missed the answer.

One problem would be the order. We can't guarantee the order using init(), can we?

The order of the init() calls cannot be controlled, but we can make sure items are added to the slice in an ordered manner (version names are sort-able).

I'm not that clear why we need them ordered in the first place.
Is it for picking the default/latest one when answering the client? (if that is the case, we can mark which is the "default" when registering).

The order of the init() calls cannot be controlled, but we can make sure items are added to the slice in an ordered manner (version names are sort-able).

Okay, will do that.

I'm not that clear why we need them ordered in the first place.
Is it for picking the default/latest one when answering the client?

Yes. We receive a list of implemented versions and our heuristic is to get latest one. So, some order is needed

It will be nicer to avoid changing these slices in the future here. The versions could be registered by the individual package/file through an init(), leaving here only the infrastructure.

I actually worked on this Today. We can't do it how you proposed, by implementing init() that call manager's Register function would cause a dependency cycle between each version and hook package.

As we dropped adding the warning on webhook admitter, I'm not exporting both variables anymore. I'll add this to #11215 as well.

EdDev · 2024-01-14T07:52:20Z

pkg/virt-api/webhooks/validating-webhook/admitters/vmi-create-admitter.go

 	}
 }

+func warnDeprecatedSidecars(vmi *v1.VirtualMachineInstance) []string {


I do not think we should examine annotations, it is a step too far IMO.
Warning about it in the runtime that uses it makes sense, but not at this level.

In my opinion, it can be useful and we have precedence with warning over deprecation with featureGates in the code.

The real downside to me is that it isn't 100% reliable because the args are not mandatory, nor the version argument. So, once could be using passt or slirp would trigger no warning.

The runtime on log works reliably because it happens when the hook sidecar is registering itself.

@vasiliy-ul, wdyt?

I still think it's okay to raise awareness of the users. This annotation is part of the deprecated API. Why not raising a warning if it is used? Having only a log message is a good thing, but usually nobody looks at the logs if everything works fine.

Another reason is that a user may just change/fix the annotation, and then all this is reversable.

I guess when the deprecation warning will become a strong rejection, you will not want to block changes on such settings at the webhook. As mentioned earlier, it can be fixed.

The fact that these values are not mandatory and defaults kick in, makes this check problematic IMO. I mean, even if the validation here passes, what really matters is the version of the sidecar server.

Hmm.. do I understand correctly that with this change the creation and/or change is actually rejected?
Compare to just logging, this is a breaking change, right?

We could expose the server sidecar hook version in KubeVirt CR. At least in this way, users can read the expected version. Since #11001, all authenticated users should be able to read that information.

The sidecar server runs as part of the sidecar container/image. This is not a cluster global thing.
We can even have multiple versions running in the same virt-launcher pod.
So I am not clear how this suggestion fits exactly.

I do not think webhooks should validate versions, I also do not think it is correct to parse unstructured data from annotations for such validations, especially when the value checked is not required.
I am not even convinced it is relevant to tell the server side with which version it should operate, that should be negotiated between the client and server like most protocol do when a handshake is needed.

There is an opportunity here, once all these issues have been surfaced, to improve the "protocol" and provide a more sustainable solution. I would advice to work on the improvements and prioritize that over patching hacks on the problems seen.

We could expose the server sidecar hook version in KubeVirt CR. At least in this way, users can read the expected version. Since #11001, all authenticated users should be able to read that information.

The sidecar server runs as part of the sidecar container/image. This is not a cluster global thing. We can even have multiple versions running in the same virt-launcher pod. So I am not clear how this suggestion fits exactly.

True, but we also support a single version of the virt-launcher image which is the server and it could expose which version of the protocol its support. It could be a way to expose this information in a more friendly way. Right now, the sidecar server API is embedded in virt-launcher. Or is there a way to understand the supported API versions?

The alternative is that users will realize that they need to upgrade the sidecar API version when they fail running the virt-launcher pod.

Do we need to guarantee backward compatibility when the API graduate from alpha to beta?

Folks, this is awesome discussion, truly. I'll open a new issue with a tracker of proposed changes for sidecar promotion from alpha and beta and we can probably dig deeper there. I'll just give my opinion on what was raised so far:

Right now, the sidecar server API is embedded in virt-launcher. Or is there a way to understand the supported API versions?

@alicefr the gRPC server side is actually running in the sidecar. There is a predefined path that they should run their socket and virt-launcher will iterate over all available sockets, doing capabilities query (e.g: what version it is running in that socket and what hooks are handled/exposed).

If we remove, let's say, v1alpha1, the removal will be on virt-launcher, which means that sidecar exposing that version will not be recognized and will fail to run.

We could expose the server sidecar hook version in KubeVirt CR. At least in this way, users can read the expected version. Since #11001, all authenticated users should be able to read that information.

I'm not sure what the best way forward is, we need to brainstorm, but we do need a way to query version and more.

Do we need to guarantee backward compatibility when the API graduate from alpha to beta?

In my opinion, no. From KubeVirt point of view, I'm mostly worried about not breaking the network pluggins and their 'supported' scenarios. I don't know that, but knowing we can make a plan of how many releases we need to keep a given version deprecated. That's hopefully enough for folks using custom sidecars outside KubeVirt repository and a possible incentive to move minor use cases to use sidecar-shim as, I believe, the plan is that people would only need to rebuild their sidecar with a newer sidecar-shim image as that's focusing on gRPC/api versioning.

There is an opportunity here, once all these issues have been surfaced, to improve the "protocol" and provide a more sustainable solution. I would advice to work on the improvements and prioritize that over patching hacks on the problems seen.

@EdDev, I agree. I'll update this PR Today and open the tracker issue I mentioned, and we can start discussing ideas for the Beta version.

Thank you all so much for the discussion!

Thanks @victortoso for the explication! Sounds good to me.

As promised, I opened the following issue to track improvements we want to do for Beta:
#11215

victortoso · 2024-01-15T09:24:33Z

While working on a sidecar lately, I realized we do have a problem with its implementation which makes it hard to extend in a reasonable way.
But this fits a design or a meeting discussion, not here.

Right. Please do file issues for us to discuss it, or we can perhaps discuss it in kubevirt/community#252 if you feel it is appropriate.

This patch marks the whole hooks/v1alpha1 and hooks/v1alpha2 as deprecated. Users should use: * v1alpha3: introduced in v1.2.0 (to be released) with 613f0fe "hooks: Add v1alpha3 with Shutdown method" in 2023-11-27 This patch also includes the result of `make generate`. Signed-off-by: Victor Toso <[email protected]>

We add a new boolean to easily check if a given version is deprecated or not. Signed-off-by: Victor Toso <[email protected]>

Other versions are now deprecated. Signed-off-by: Victor Toso <[email protected]>

kubevirt-bot · 2024-02-12T17:16:18Z

New changes are detected. LGTM label has been removed.

victortoso · 2024-02-12T17:18:43Z

Sorry, I've been in and out the last couple of weeks and could not work on this. We are now in the Feature Freeze so I think we can postpone this for after the release.

I'll get back to kubevirt/community#252 Tomorrow, which should be merged prior to this anyway.

kubevirt-bot · 2024-02-12T18:20:59Z

@victortoso: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-kubevirt-e2e-arm64	`b2619b9`	link	false	`/test pull-kubevirt-e2e-arm64`

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/test-infra repository. I understand the commands that are listed here.

kubevirt-bot · 2024-07-10T00:52:57Z

PR needs rebase.

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.

kubevirt-bot · 2024-10-08T00:56:32Z

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

kubevirt-bot · 2024-11-07T01:35:56Z

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle rotten

kubevirt-bot · 2024-12-07T02:18:30Z

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

kubevirt-bot · 2024-12-07T02:18:33Z

@kubevirt-bot: Closed this PR.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

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.

kubevirt-bot added release-note Denotes a PR that will be considered when it comes time to generate release notes. dco-signoff: yes Indicates the PR's author has DCO signed all their commits. size/S labels Dec 5, 2023

kubevirt-bot requested review from alicefr and maiqueb December 5, 2023 20:52

kubevirt-bot assigned alicefr Dec 6, 2023

vasiliy-ul reviewed Dec 7, 2023

View reviewed changes

victortoso mentioned this pull request Dec 12, 2023

Adding a proposal for existing hooks sidecar kubevirt/community#252

Open

victortoso force-pushed the deprecate-hooks-v1alphav1 branch from 45743ef to 69d1396 Compare December 12, 2023 20:36

kubevirt-bot added size/M and removed size/S labels Dec 12, 2023

victortoso changed the title ~~hooks: deprecate v1alpha1~~ hooks: deprecate v1alpha1 & v1alpha2 Dec 12, 2023

kubevirt-bot requested a review from EdDev December 13, 2023 07:11

0xFelix reviewed Jan 8, 2024

View reviewed changes

kubevirt-bot removed the lgtm Indicates that a PR is ready to be merged. label Jan 11, 2024

vasiliy-ul approved these changes Jan 11, 2024

View reviewed changes

kubevirt-bot added the lgtm Indicates that a PR is ready to be merged. label Jan 11, 2024

EdDev reviewed Jan 14, 2024

View reviewed changes

victortoso mentioned this pull request Feb 12, 2024

Proposal changes for hook sidecar Beta #11215

Closed

3 tasks

victortoso added 3 commits February 12, 2024 12:06

hooks: runtime warn on deprecated versions

7eba90b

We add a new boolean to easily check if a given version is deprecated or not. Signed-off-by: Victor Toso <[email protected]>

examples: sidecar: use v1alpha3

b2619b9

Other versions are now deprecated. Signed-off-by: Victor Toso <[email protected]>

victortoso force-pushed the deprecate-hooks-v1alphav1 branch from 58e151c to b2619b9 Compare February 12, 2024 17:16

kubevirt-bot removed the lgtm Indicates that a PR is ready to be merged. label Feb 12, 2024

kubevirt-bot added size/M and removed size/L labels Feb 12, 2024

kubevirt-bot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jul 10, 2024

kubevirt-bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Oct 8, 2024

kubevirt-bot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Nov 7, 2024

kubevirt-bot closed this Dec 7, 2024

hooks: deprecate v1alpha1 & v1alpha2 #10842

hooks: deprecate v1alpha1 & v1alpha2 #10842

Conversation

victortoso commented Dec 5, 2023 • edited Loading

alicefr commented Dec 6, 2023

victortoso commented Dec 6, 2023

alicefr commented Dec 6, 2023

vasiliy-ul left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

0xFelix commented Dec 7, 2023

alicefr commented Dec 7, 2023 • edited Loading

EdDev commented Dec 7, 2023 • edited Loading

alicefr commented Dec 8, 2023

EdDev commented Dec 10, 2023

victortoso commented Dec 11, 2023

EdDev commented Dec 11, 2023

victortoso commented Dec 12, 2023

kubevirt-bot commented Dec 12, 2023

victortoso commented Dec 12, 2023

EdDev commented Dec 13, 2023

vasiliy-ul commented Dec 13, 2023

dharmit commented Jan 4, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

victortoso commented Jan 11, 2024

victortoso commented Jan 11, 2024

alicefr commented Jan 12, 2024 • edited Loading

alicefr commented Jan 12, 2024

EdDev left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

EdDev Jan 25, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

victortoso commented Jan 15, 2024

kubevirt-bot commented Feb 12, 2024

victortoso commented Feb 12, 2024

kubevirt-bot commented Feb 12, 2024 • edited Loading

kubevirt-bot commented Jul 10, 2024

kubevirt-bot commented Oct 8, 2024

kubevirt-bot commented Nov 7, 2024

kubevirt-bot commented Dec 7, 2024

kubevirt-bot commented Dec 7, 2024

victortoso commented Dec 5, 2023 •

edited

Loading

alicefr commented Dec 7, 2023 •

edited

Loading

EdDev commented Dec 7, 2023 •

edited

Loading

alicefr commented Jan 12, 2024 •

edited

Loading

EdDev Jan 25, 2024 •

edited

Loading

kubevirt-bot commented Feb 12, 2024 •

edited

Loading