Re: meta-cloud layer

[Michael Halstead <michael@yoctoproject.org>]

[-- Attachment #1.1: Type: text/plain, Size: 6262 bytes --]

On 11/30/2012 09:26 AM, Bruce Ashfield wrote:
>
>
>
> On Fri, Nov 30, 2012 at 12:15 PM, Saul Wold <sgw@linux.intel.com
> <mailto:sgw@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@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.


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. "

-- 
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"


[-- Attachment #1.2: Type: text/html, Size: 12236 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4516 bytes --]