Mailing List Archive: RFC: new 'virtualization' project or herd

RFC: new 'virtualization' project or herd

Jun 17, 2008, 1:29 AM

Post #1 of 5 (156 views)

Hi everyone

What do you think of creating a new 'virtualization' project or herd/team?

My initial motivation for this idea was that while libvirt is being
maintained by 'xen', it is not xen-specific anymore but also supports kvm,
qemu, lxc and openvz.

It would also make sense for other parts like the network setup (which is
pretty equal for xen, kvm, qemu and virtualbox: tun/tap combined with a
bridge or with routing & masquerading).

The idea is to collect the following package-"families":
- xen
- kvm
- virtualbox
- vmware
- qemu
- libvirt

and eventually also the following:
- vserver
- openvz

From my perspective it'd make sense to create a project in which we can also
provide documentation (currently maintained by the docs project), a
roadmap, comparison charts, etc.

So, what do you think?

Cheers,
Tiziano

ps It has been suggested to post this on -dev since it's about herds and
therefore about maintaining ebuilds.

--
gentoo-dev@lists.gentoo.org mailing list

Re: RFC: new 'virtualization' project or herd [ In reply to ]

ikelos at gentoo

May 10, 2008, 7:09 AM

Post #2 of 5 (161 views)

Permalink

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tiziano Müller wrote:
| Hi everyone
|
| What do you think of creating a new 'virtualization' project or herd/team?

Sounds like a good idea, there seem to be enough packages to warrant it.
~ Especially if you're finding shared packages and space for integration
of components.

| So, what do you think?

As one of the primary vmware devs, I'm not sure that vmware easily fits
into this group based on it's closed-source nature, and the complex (but
just about workable) module system we've put in place. I also wouldn't
want to muddy the virtualization email address with all the random
vmware module bugs... 5:)

I'm pretty happy for the vmware group to go under the virtualization
herd, but I'd very much like to maintain the vmware email
alias/assignment for bugs, and I'm not sure how much we'd be able to
integrate with the larger group. Do you think it's worthwhile vmware
joining the umbrella or should we just stay separate?

Mike 5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkglrH8ACgkQu7rWomwgFXo4EgCfRl05jk1I3jbfIXFdNtnaRRFB
Up4AoKPc4t2OsIjI/4E+DCy2mRp4x8+b
=uOzA
-----END PGP SIGNATURE-----
--
gentoo-dev@lists.gentoo.org mailing list

Re: Re: RFC: new 'virtualization' project or herd [ In reply to ]

ikelos at gentoo

May 16, 2008, 8:38 PM

Post #3 of 5 (156 views)

Permalink

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tiziano Müller wrote:
| That's true. How about having a virtualization project which takes care of
| the common part, the docs and the coordination (if any) and have separate
| herds for larger "subprojects"?

Sounds ideal. 5:)

Mike 5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkguUzwACgkQu7rWomwgFXrO0ACeIx8aTebKqkMKQe81bh/dm8mq
wXMAnRUHPhfQJsaVy1shWRsdNUd1IP4w
=bOB4
-----END PGP SIGNATURE-----
--
gentoo-dev@lists.gentoo.org mailing list

Re: Re: RFC: new 'virtualization' project or herd [ In reply to ]

rbu at gentoo

May 18, 2008, 9:23 AM

Post #4 of 5 (156 views)

Permalink

On Friday, 16. May 2008, Tiziano Müller wrote:
> Mike Auty wrote:
> > As one of the primary vmware devs, I'm not sure that vmware easily
> > fits into this group based on it's closed-source nature, and the
> > complex (but just about workable) module system we've put in place. I
> > also wouldn't want to muddy the virtualization email address with all
> > the random vmware module bugs... 5:)
> >
> > I'm pretty happy for the vmware group to go under the virtualization
> > herd, but I'd very much like to maintain the vmware email
> > alias/assignment for bugs, and I'm not sure how much we'd be able to
> > integrate with the larger group. Do you think it's worthwhile vmware
> > joining the umbrella or should we just stay separate?
>
> That's true. How about having a virtualization project which takes care
> of the common part, the docs and the coordination (if any) and have
> separate herds for larger "subprojects"?

I have to agree here for the Xen part. One big alias for all packages will
only jam up everybody's mailbox.
So we keep the existing herds (vmware, xen) and maintain common packages
such as libvirt under a super-herd. Question is what happens with the
packages that are not part of any herd yet (such as virtualbox, qemu)?

Robert

Re: RFC: new 'virtualization' project or herd [ In reply to ]

dev-zero at gentoo

Jun 17, 2008, 1:29 AM

Post #5 of 5 (158 views)

Permalink

Sorry that it took so long to answer, but I was quiet busy with real life.

Mike Auty wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Tiziano Müller wrote:
> | Hi everyone
> |
> | What do you think of creating a new 'virtualization' project or
> | herd/team?
>
> Sounds like a good idea, there seem to be enough packages to warrant it.
> ~ Especially if you're finding shared packages and space for integration
> of components.
Good :-)

>
> | So, what do you think?
>
> As one of the primary vmware devs, I'm not sure that vmware easily fits
> into this group based on it's closed-source nature, and the complex (but
> just about workable) module system we've put in place. I also wouldn't
> want to muddy the virtualization email address with all the random
> vmware module bugs... 5:)
>
> I'm pretty happy for the vmware group to go under the virtualization
> herd, but I'd very much like to maintain the vmware email
> alias/assignment for bugs, and I'm not sure how much we'd be able to
> integrate with the larger group. Do you think it's worthwhile vmware
> joining the umbrella or should we just stay separate?

That's true. How about having a virtualization project which takes care of
the common part, the docs and the coordination (if any) and have separate
herds for larger "subprojects"?

Cheers,
Tiziano

--
gentoo-dev@lists.gentoo.org mailing list

Mailing List Archive

Mailing List Archive

Attached Files: