[OE-core] meta-cloud layer
Raymond Danks
ray.danks at se-eng.com
Fri Nov 30 20:17:34 UTC 2012
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 <sgw at linux.intel.com
>> <mailto:sgw at 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
> git at 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 at lists.openembedded.org
>> <mailto:Openembedded-core at lists.openembedded.org>
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core at lists.openembedded.org
>> <mailto:Openembedded-core at lists.openembedded.org>
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core at lists.openembedded.org
>> <mailto:Openembedded-core at 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"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20121130/50bed5da/attachment-0002.html>
More information about the Openembedded-core
mailing list