[OE-core] meta-cloud layer

[Bruce Ashfield]

On Fri, Nov 30, 2012 at 12:15 PM, Saul Wold <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 ?

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 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<Openembedded-core at lists.openembedded.org>
>>> http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/**
>>> openembedded-core<http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core>
>>>
>>>
>>
>> ______________________________**_________________
>> Openembedded-core mailing list
>> Openembedded-core at lists.**openembedded.org<Openembedded-core at lists.openembedded.org>
>> http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/**openembedded-core<http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core>
>>
>>
>>
> ______________________________**_________________
> Openembedded-core mailing list
> Openembedded-core at lists.**openembedded.org<Openembedded-core at lists.openembedded.org>
> http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/**openembedded-core<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/23965ade/attachment-0002.html>