On 11/30/2012 11:03 AM, Michael Halstead wrote:
On 11/30/2012 09:26 AM, Bruce Ashfield wrote:
On Fri, Nov 30, 2012 at 12:15 PM, Saul Wold <s...@linux.intel.com
<mailto:s...@linux.intel.com>> wrote:
On 11/30/2012 03:29 AM, David Nyström wrote:
On 11/29/2012 02:54 PM, Richard Purdie wrote:
On Thu, 2012-11-29 at 06:44 -0700, Raymond Danks wrote:
Thanks for looping me in here David. The initial goal
for the meta-xen
layer was in fact to encompass Xen Cloud Platform.
As such, the intent
was to contain both hypervisor and user-space
applications. Indeed, the
xen distribution itself includes xm/libxl; hypervisor
abstraction would
be somewhat tedious in my opinion.
The layer just received commits for expanding the
libvirt build to
support qemu. The commonalities and shared packaged
between xen, qemu,
and kvm implementations are such that I would also
agree that meta-xen
should be expanded/renamed to encompass all
virtualization types; I also
support the move to meta-virtualization.
meta-virtualization sounds good, let co-op on this so we
don't duplicate
work.
If everyone is OK with this, I will have Michael Halstead create
a repo, please send him your keys so that you will have write
access to it.
This works for me. If Michael already has our keys, do we need to
resend or can
a local copy happen ?
I already have keys for,
David Nystrom df:2d:b1:59:f3:d7:73:fc:59:36:7b:cf:85:28:a7:50
Bruce Ashfield 4f:93:90:b2:c7:a1:45:21:f2:47:31:6f:60:f9:60:02
Either of you can currently add
g...@git.yoctoproject.org:meta-virtualization as a git remote and start
the repository. Once we have initial code and the maintainers and
patch submission guidelines in the readme I can publicly list the new
repository.
I require an ssh public key for Raymond Danks.
Thanks Michael. I got your response and was able to push meta-xen to
the newly created repository on meta-virtualization. I added one commit
to tweak the README and conf/layer.conf for the new name.
We also need a short description for the listing on
git.yoctoproject.org. I could be something similar to, but better
than, "Layer enabling virtualization support. "
How about "Layer enabling hypervisor, virtualization tool stack, and
cloud support."
Also - I referenced the mail alias meta-virtualization at yoctoproject
in the README. When you publish this, can we use something like that as
well?
Thanks again,
Ray
--
Michael Halstead
Yocto Project / Sys Admin
Cheers,
Bruce
Sau!
As far as a meta-cloud layer is concerned, I'm not
sure I am
knowledgeable enough in this area to weigh in. I'm
currently
researching a filesystem implementation for OpenStack
and have stumbled
across Ceph/RBD and Gluster modules that look
promising. On top of this,
XCP is documented to include support for VastSky and
can be integrated
with DRBD. And, the storage and hypervisor are only
two pieces of the
puzzle for a cloud implementation!
Cool !
I know, the meta-"cloud" name is quite/too ambitious, it was
not meant
to be a one week effort. But why aim low :).
I think I would encourage you to also include
OpenStack in a
meta-virtualization layer until it has matured to the
point where
abstraction is more warranted.
Agree.
Since you've already created a presence
at github, would it be possible to rename your layer to
meta-virtualization and absorb the entire meta-xen
layer? I can push
any changes for Xen/XCP here, it sounds like it is a
central place for
libvirt and could also contain Bruce's kernel
modifications.
Alternatively, I can create a meta-virtualization
project. In any case,
those on the To and CC list should receive access to
this layer as a
starting point.
Just my two cents. :)
I'd like to offer to host this combined layer (whatever
we decide to
call it) on git.yoctoproject.org
<http://git.yoctoproject.org> if that would help people
and people
are interested. My only concern is in the area of
maintainership, we
need to clearly define who maintains what and what the
patch submission
process is in the README.
Thanks,
Sounds good to centralize everything, since Raymond is the
majority code
contributor, perhaps he, if willing, can maintain the
meta-virtualization layer.
If you want a co/sub-maintainer I'll be happy to help out.
Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
<mailto:Openembedded-core@lists.openembedded.org>
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
<mailto:Openembedded-core@lists.openembedded.org>
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
<mailto:Openembedded-core@lists.openembedded.org>
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
