[kubevirt-dev] new repository under kubevirt org for bulk migration controller

[Alex Kalenyuk]

Hi everyone,

In the last few months we've been working on a project that allows bulk storage migration operations, which is highly inspired by an existing project (https://github.com/migtools/mig-controller) that is getting sunset.
In addition, the existing variation is somewhat coupled to specific environments and is highly overloaded with non kubevirt related features.

Due to both, we've been trying to extract the relevant kubevirt bits and put them in a project under the kubevirt umbrella, initially starting under my personal org:
https://github.com/akalenyu/kubevirt-migration-operator/
https://github.com/akalenyu/kubevirt-migration-controller/

Please let us know if this would be possible to create those repositories and assign myself as a maintainer.

[Alexander Wels]

+1 from me, this will make storage migrations (and decentralized live migrations in the future) much better.

--
You received this message because you are subscribed to the Google Groups "kubevirt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubevirt-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/kubevirt-dev/CAHahevfOK%2B33OYMfyJTjXgUobBiE7-kOX%3DV-Rq79HPfGzVdr4Q%40mail.gmail.com.

[Daniel Hiller]

Hi Alex and Alexander,

in general the process for creating new repositories is initiated from a VEP that declares which repositories need to be created and what purpose each of them has. Technically the repos and their GitHub teams are being created by merging a pull request against orgs.yaml in project-infra that adds their declarations. Examples can be found in the community docs [1] .

[1]: https://github.com/kubevirt/community/blob/main/docs/automating-github-org-management.md#new-repositories

To view this discussion visit https://groups.google.com/d/msgid/kubevirt-dev/CAKDnqXYf73KV81drkYKoba0yKx5pE4Cti3qSruJOpOXBbAeJ6g%40mail.gmail.com.

--

-- 

Best,

Daniel

[Alex Kalenyuk]

in general the process for creating new repositories is initiated from a VEP

Hey Daniel, would you be open to an exception about this? it looks like the change that requires this was only made recently [0]
Since VEPs are tied to kubevirt releases - this means we would not introduce the new repo until the next cycle

[0] https://github.com/kubevirt/community/pull/421

[Michael Henriksen]

On Thu, Oct 23, 2025 at 10:58 AM 'Alex Kalenyuk' via kubevirt-dev <kubevi...@googlegroups.com> wrote:

in general the process for creating new repositories is initiated from a VEP

Hey Daniel, would you be open to an exception about this? it looks like the change that requires this was only made recently [0]
Since VEPs are tied to kubevirt releases - this means we would not introduce the new repo until the next cycle

I totally agree that a VEP should be required to add a new repo to the KubeVirt org. But if what Alex is proposing here does not require any changes in kubevirt/kubevirt or is not bound to any future KubeVirt release, I see no reason to wait for the next kubevirt/kubevirt VEP review cycle to get a VEP merged and the repo created

To view this discussion visit https://groups.google.com/d/msgid/kubevirt-dev/CAHahevfSW_NS5WJmbmWyQ0au2KMAJwFFGtS%2Bn8Tr%2BxVXu%3Dbp1A%40mail.gmail.com.

[Daniel Hiller]

Michael,

good point - sounds reasonable. I'll try to capture this in a change against the above doc.

Alex, IMHO and since there seems to be no opposition, let's move forward by creating a PR for repo and team creation then.

Note: the presubmit check will fail since we have an open issue in adjusting it for the above use-case.

Alex, LMK if you need further information or support.

--

-- 

Best,

Daniel

[Daniel Hiller]

On Fri, Oct 24, 2025 at 9:16 AM Daniel Hiller <dhi...@redhat.com> wrote:

Michael,

good point - sounds reasonable. I'll try to capture this in a change against the above doc.

Alex, IMHO and since there seems to be no opposition, let's move forward by creating a PR for repo and team creation then.

Note: the presubmit check will fail since we have an open issue in adjusting it for the above use-case.

Alex, LMK if you need further information or support.

On Thu, Oct 23, 2025 at 8:17 PM Michael Henriksen <mhen...@redhat.com> wrote:

On Thu, Oct 23, 2025 at 10:58 AM 'Alex Kalenyuk' via kubevirt-dev <kubevi...@googlegroups.com> wrote:

in general the process for creating new repositories is initiated from a VEP

Hey Daniel, would you be open to an exception about this? it looks like the change that requires this was only made recently [0]
Since VEPs are tied to kubevirt releases - this means we would not introduce the new repo until the next cycle

I totally agree that a VEP should be required to add a new repo to the KubeVirt org. But if what Alex is proposing here does not require any changes in kubevirt/kubevirt or is not bound to any future KubeVirt release, I see no reason to wait for the next kubevirt/kubevirt VEP review cycle to get a VEP merged and the repo created

Alex, fFrom what I understand the code that is hosted inside the new repositories might possibly get removed in the long term, right?

--

-- 

Best,

Daniel

[Daniel Hiller]

On Fri, Oct 24, 2025 at 10:12 AM Daniel Hiller <dhi...@redhat.com> wrote:

On Fri, Oct 24, 2025 at 9:16 AM Daniel Hiller <dhi...@redhat.com> wrote:

Michael,

good point - sounds reasonable. I'll try to capture this in a change against the above doc.

Alex, IMHO and since there seems to be no opposition, let's move forward by creating a PR for repo and team creation then.

Note: the presubmit check will fail since we have an open issue in adjusting it for the above use-case.

Alex, LMK if you need further information or support.

On Thu, Oct 23, 2025 at 8:17 PM Michael Henriksen <mhen...@redhat.com> wrote:

On Thu, Oct 23, 2025 at 10:58 AM 'Alex Kalenyuk' via kubevirt-dev <kubevi...@googlegroups.com> wrote:

in general the process for creating new repositories is initiated from a VEP

Hey Daniel, would you be open to an exception about this? it looks like the change that requires this was only made recently [0]
Since VEPs are tied to kubevirt releases - this means we would not introduce the new repo until the next cycle

I totally agree that a VEP should be required to add a new repo to the KubeVirt org. But if what Alex is proposing here does not require any changes in kubevirt/kubevirt or is not bound to any future KubeVirt release, I see no reason to wait for the next kubevirt/kubevirt VEP review cycle to get a VEP merged and the repo created

Alex, fFrom what I understand the code that is hosted inside the new repositories might possibly get removed in the long term, right?

nevermind, I misunderstood the whole thing :)

--

-- 

Best,

Daniel