> >Note that in the spirit of DTrace remining a community in its own right,
> >(http://thread.gmane.org/gmane.os.solaris.opensolaris.ogb/13/focus=19)
> >Zones probably could (should?) too. It certainly meets the criteria:
> >popular/vibrant, mature, and integrated.
>
> If we do that, the communities / projects sponsored by zones could include:
> * Resource Management
> * BrandZ
> * Trusted Extensions, which could be co-sponsored by the Security community
> * IP Instances / Crossbow, co-sponsored with Networking
>
> That would comprise our "Operating System Level Virtualization" community,
> leaving Xen, LDoms, and related communities and projects for the
> "Hypervisor-Like Virtualization" community.
HV-level v12n vs. OS-level v12n might be a useful distinction in terms of
implementation but since many of the problems and issues are shared, it
might just be more of a pain.
For example, Resource Management, Trusted Extensions and (particularly)
Crossbow are relevant to "hypervisor-level" virtualization too - dom0
ties a lot of Solaris platform technologies into the picture. Of course
those could just have duplicate co-sponsorship too.
I'm happy with either combined or with separate OS v12n and HV v12n
communities. One advantage of the latter is that 'v12n' is a bit of an
open-ended concept at best (should it handle virtual tape too, for example?)
(Almost as if a nested layer of community hierarchy is needed:
v12n -> os-level v12n -> zones
-> brandz
-> ip instances
-> hv-level v12n -> qemu
-> xen
-> ldoms
-> storage v12n -> ...
or, perhaps that's just overengineering something supposed to be simple.)
tim
