[OE-core] meta-cloud layer

[Bruce Ashfield]

On Fri, Nov 30, 2012 at 12:14 PM, Raymond Danks <ray.danks at se-eng.com>wrote:

> On 11/30/2012 04: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.
>>
> Yes. Agreed.
>
>
>>  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.
>>
>>  Yes.  Thanks Richard.  I was looking at some of the Yocto projects and
> the meta-ti stood out as one that might be a model for this. Would it be
> possible to configure a mailing list for meta-virtualization as well?  Once
> you've got the repo in place I'll push up what's in meta-xen.  Maybe David
> can come behind with what's in meta-cloud.  I also saw that Mihai mentioned
> having a KVM tree that might integrate.  Once we've got this setup we
> should also rename the link on the OE layers index wiki.
>
> I'm happy with a co-maintainer type setup as well.  In fact, I prefer
> that.  I've done work with the xen part of this, but kvm and openstack are
> still somewhat foreign.
>

And I've got some cross platform experience with all three, plus kernel
parts, so
as required, I'm still offering up my help if no one objects.

I'll send along my keys once a layer and home have been chosen.

Cheers,

Bruce


>
> At any rate, I'll pay closer attention to the lists as they pertain to
> this layer especially going forward.  I think this will work well to
> combine our efforts here.
>
> Ray
>
>
>>  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>
>>>
>>>
>>
>


-- 
"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/f727d4cc/attachment-0002.html>