meta-cloud layer

Hello everyone,

I'm working on getting a minimal Yocto/oe-core based OpenStack setup running with the meta-cloud layer, with bits and pieces "borrowed" from the meta-xen layer.

Still in its infancy, and lots of stuff is still missing and/or not working properly.

Have a look if your interested, not much to see yet though.

https://github.com/nysan/meta-cloud.git

Any thoughts on floating layer ML:s, i.e. an ML for so called "out-of-tree" layers ? Or is the common thought that all new recipes should eventually go into oe-core ?

Quoted 5 lines · David Nyström

Hello everyone,

I'm working on getting a minimal Yocto/oe-core based OpenStack setup running with the meta-cloud layer, with bits and pieces "borrowed" from the meta-xen layer.

Great news!

It might be worth growing meta-xen into a meta-virtualisation layer since kvm, openstack and xen all seem to be sharing a lot of pieces. This depends on the maintainers but it would seem to be logical rather than many small interdependent layers.

Quoted 11 lines

Still in its infancy, and lots of stuff is still missing and/or not working properly.

Have a look if your interested, not much to see yet though.

https://github.com/nysan/meta-cloud.git

Any thoughts on floating layer ML:s, i.e. an ML for so called "out-of-tree" layers ? Or is the common thought that all new recipes should eventually go into oe-core ?

The Yocto Project has been using the Yocto list for that and OpenEmbedded has openembedded-devel. Its not expected for everything to end up in OE-Core, quite the opposite.

Cheers,

Richard

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 7 lines · Richard Purdie

Quoted 5 lines · David Nyström

Hello everyone,

I'm working on getting a minimal Yocto/oe-core based OpenStack setup running with the meta-cloud layer, with bits and pieces "borrowed" from the meta-xen layer.

Quoted 7 lines

Great news!

It might be worth growing meta-xen into a meta-virtualisation layer since kvm, openstack and xen all seem to be sharing a lot of pieces. This depends on the maintainers but it would seem to be logical rather than many small interdependent layers.

FWIW. I'd like to see this as well, and can contribute/help where possible. I
was considering a meta-ovs (Open Virtualization Solutions), but if there are already plans afoot for a meta-virtualization, then anything I did could be pushed down keeping any other layers small.

In particular I'm keen to drive some common kernel configuration, and work on consolidating kernel features in trees versus having a whole set of out of
tree modules with better tie in's to userspace enabling features dynamically.

So I'll keep an eye out for things as well and help where possible.

Cheers,

Bruce

Quoted 27 lines

Quoted 11 lines

Still in its infancy, and lots of stuff is still missing and/or not working properly.

Have a look if your interested, not much to see yet though.

https://github.com/nysan/meta-cloud.git

Any thoughts on floating layer ML:s, i.e. an ML for so called "out-of-tree" layers ? Or is the common thought that all new recipes should eventually go into oe-core ?

The Yocto Project has been using the Yocto list for that and OpenEmbedded has openembedded-devel. Its not expected for everything to end up in OE-Core, quite the opposite.

Cheers,

Richard

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 7 lines · Richard Purdie

Quoted 5 lines · David Nyström

Hello everyone,

I'm working on getting a minimal Yocto/oe-core based OpenStack setup running with the meta-cloud layer, with bits and pieces "borrowed" from the meta-xen layer.

Quoted 7 lines

Great news!

It might be worth growing meta-xen into a meta-virtualisation layer since kvm, openstack and xen all seem to be sharing a lot of pieces. This depends on the maintainers but it would seem to be logical rather than many small interdependent layers.

FWIW. I'd like to see this as well, and can contribute/help where possible. I
was considering a meta-ovs (Open Virtualization Solutions), but if there are already plans afoot for a meta-virtualization, then anything I did could be pushed down keeping any other layers small.

In particular I'm keen to drive some common kernel configuration, and work on consolidating kernel features in trees versus having a whole set of out of tree modules with better tie in's to userspace enabling features dynamically.

So I'll keep an eye out for things as well and help where possible.

Cheers,

Bruce

Quoted 27 lines

Quoted 11 lines

Still in its infancy, and lots of stuff is still missing and/or not working properly.

Have a look if your interested, not much to see yet though.

https://github.com/nysan/meta-cloud.git

Any thoughts on floating layer ML:s, i.e. an ML for so called "out-of-tree" layers ? Or is the common thought that all new recipes should eventually go into oe-core ?

The Yocto Project has been using the Yocto list for that and OpenEmbedded has openembedded-devel. Its not expected for everything to end up in OE-Core, quite the opposite.

Cheers,

Richard

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Adding Ray Danks to CC.

Ray, how do you want to go forward with the meta-xen layer ?

From my perspective, having the actual hypervisor technology abstracted
from the userspace virtualization stuff is preferable. So a user could pick-and-place hypervisor layer/s depending on needs. (And good for use-case benchmarks as well).

libvirt package and others are smart enough to autodetect underlying hypervisor tech capabilities, and should work out-of-the-box from that aspect.

As to where all this will finally end up, anything goes as far as I'm concerned. I'll continue working in meta-cloud for now, until consensus is reached on the final whereabouts for the virtualization specific recipes.

If anyone want to join me on github, send me an email.

Best Regards,
David

Quoted 67 lines · Bruce Ashfield

Quoted 7 lines · Richard Purdie

Quoted 5 lines · David Nyström

Hello everyone,

I'm working on getting a minimal Yocto/oe-core based OpenStack setup running with the meta-cloud layer, with bits and pieces "borrowed" from the meta-xen layer.

Quoted 7 lines

Great news!

It might be worth growing meta-xen into a meta-virtualisation layer since kvm, openstack and xen all seem to be sharing a lot of pieces. This depends on the maintainers but it would seem to be logical rather than many small interdependent layers.

FWIW. I'd like to see this as well, and can contribute/help where possible. I
was considering a meta-ovs (Open Virtualization Solutions), but if there are already plans afoot for a meta-virtualization, then anything I did could be pushed down keeping any other layers small.

In particular I'm keen to drive some common kernel configuration, and work on consolidating kernel features in trees versus having a whole set of out of
tree modules with better tie in's to userspace enabling features dynamically.

So I'll keep an eye out for things as well and help where possible.

Cheers,

Bruce

Quoted 27 lines

Quoted 11 lines

Still in its infancy, and lots of stuff is still missing and/or not working properly.

Have a look if your interested, not much to see yet though.

https://github.com/nysan/meta-cloud.git

Any thoughts on floating layer ML:s, i.e. an ML for so called "out-of-tree" layers ? Or is the common thought that all new recipes should eventually go into oe-core ?

The Yocto Project has been using the Yocto list for that and OpenEmbedded has openembedded-devel. Its not expected for everything to end up in OE-Core, quite the opposite.

Cheers,

Richard

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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.

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!

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. 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. :)

Quoted 6 lines · Raymond Danks

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.

Quoted 6 lines

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.

Quoted 8 lines

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!

Quoted 3 lines

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.

Quoted 10 lines

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.

Quoted 1 line

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.

Cheers,

Richard

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 7 lines · Richard Purdie

Quoted 6 lines · Raymond Danks

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.

Quoted 6 lines

Quoted 6 lines

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.

Quoted 9 lines

Quoted 9 lines

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 :).

Quoted 3 lines

Quoted 3 lines

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.

Quoted 10 lines

Quoted 10 lines

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.

Quoted 8 lines

Quoted 1 line

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.

Quoted 12 lines

Cheers,

Richard

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 17 lines · David Nyström

Quoted 8 lines · Richard Purdie

Quoted 6 lines · Raymond Danks

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.

Quoted 7 lines

Quoted 7 lines

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.

Quoted 3 lines

meta-virtualization sounds good, let co-op on this so we don't duplicate work.

Yes. Agreed.

Quoted 40 lines

As far as a meta-cloud layer is concerned, I'm not sure I am

Quoted 8 lines

Quoted 8 lines

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

Quoted 4 lines

Quoted 3 lines

meta-virtualization layer until it has matured to the point where abstraction is more warranted.

Agree.

Since you've already created a presence

Quoted 9 lines

Quoted 9 lines

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.

Quoted 10 lines

Quoted 2 lines

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.

Quoted 8 lines

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.

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

Quoted 14 lines

Cheers,

Quoted 12 lines

Richard

______________________________**_________________
Openembedded-core mailing list Openembedded-core@lists.**openembedded.org<[email protected]>
http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/**
openembedded-core<http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core>

Quoted 7 lines · Richard Purdie

Quoted 6 lines · Raymond Danks

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.

Quoted 6 lines

Quoted 6 lines

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.

Quoted 8 lines

Quoted 8 lines

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 :).

Quoted 3 lines

Quoted 3 lines

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.

Quoted 10 lines

Quoted 10 lines

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.

Quoted 8 lines

Quoted 1 line

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.

Quoted 11 lines

Cheers,

Richard

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 17 lines · David Nyström

Quoted 15 lines · Richard Purdie

Quoted 13 lines · Raymond Danks

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.

Quoted 4 lines

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.

Sau!

As far as a meta-cloud layer is concerned, I'm not sure I am

Quoted 61 lines

Quoted 8 lines

Quoted 8 lines

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

Quoted 4 lines

Quoted 3 lines

meta-virtualization layer until it has matured to the point where abstraction is more warranted.

Agree.

Since you've already created a presence

Quoted 9 lines

Quoted 9 lines

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.

Quoted 10 lines

Quoted 2 lines

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,

Quoted 5 lines

Richard

Quoted 7 lines

______________________________**_________________
Openembedded-core mailing list Openembedded-core@lists.**openembedded.org<[email protected]>
http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/**
openembedded-core<http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core>

Quoted 7 lines

______________________________**_________________
Openembedded-core mailing list Openembedded-core@lists.**openembedded.org<[email protected]>
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@lists.**openembedded.org<[email protected]>
http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/**openembedded-core<http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core>

On Fri, Nov 30, 2012 at 12:15 PM, Saul Wold <[email protected] <mailto:[email protected]>> 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
<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 [email protected] <mailto:[email protected]>
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

_______________________________________________
Openembedded-core mailing list [email protected] <mailto:[email protected]>
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

_______________________________________________
Openembedded-core mailing list [email protected] <mailto:[email protected]>
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Signature · 2 lines

"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Quoted 36 lines · Bruce Ashfield

On Fri, Nov 30, 2012 at 12:15 PM, Saul Wold <[email protected] <mailto:[email protected]>> 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.

Quoted 7 lines

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 [email protected]: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. "

Signature · 3 lines

-- 
Michael Halstead
Yocto Project / Sys Admin

Quoted 110 lines

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 [email protected] <mailto:[email protected]>
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

_______________________________________________
Openembedded-core mailing list [email protected] <mailto:[email protected]>
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

_______________________________________________
Openembedded-core mailing list [email protected] <mailto:[email protected]>
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Signature · 1 line

"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"

Quoted 51 lines · Michael Halstead

Quoted 37 lines · Bruce Ashfield

On Fri, Nov 30, 2012 at 12:15 PM, Saul Wold <[email protected] <mailto:[email protected]>> 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.

Quoted 8 lines

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

Quoted 7 lines

Either of you can currently add [email protected]: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.

Quoted 2 lines

Quoted 3 lines

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

Quoted 118 lines

Signature · 3 lines

-- 
Michael Halstead
Yocto Project / Sys Admin

Quoted 112 lines

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 [email protected] <mailto:[email protected]>
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

_______________________________________________
Openembedded-core mailing list [email protected] <mailto:[email protected]>
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

_______________________________________________
Openembedded-core mailing list [email protected] <mailto:[email protected]>
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Signature · 2 lines

"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

On 11/30/2012 12:17 PM, Raymond Danks wrote:

On 11/30/2012 11:03 AM, Michael Halstead wrote:

On 11/30/2012 09:26 AM, Bruce Ashfield wrote:

Quoted 21 lines · Saul Wold

Quoted 19 lines · David Nyström

Quoted 17 lines · Richard Purdie

Quoted 15 lines · Raymond Danks

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.

Quoted 6 lines

Quoted 4 lines

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 [email protected]: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."

Sounds good to me. Thank you.

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?

I can add a private list for [email protected]. Who
shall I add to membership?

--
Michael Halstead
Yocto Project / Sys Admin

Thanks again,
Ray

--
Michael Halstead
Yocto Project / Sys Admin

Cheers,

Bruce

Quoted 74 lines

Sau!

As far as a meta-cloud layer is concerned, I'm not sure I am

Quoted 62 lines

Quoted 9 lines

Quoted 9 lines

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

Quoted 4 lines

Quoted 3 lines

meta-virtualization layer until it has matured to the point where abstraction is more warranted.

Agree.

Since you've already created a presence

Quoted 10 lines

Quoted 10 lines

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.

Quoted 10 lines

Quoted 2 lines

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,

Quoted 11 lines

Richard

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 7 lines

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 5 lines

_______________________________________________
Openembedded-core mailing list
[email protected]
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"

Quoted 68 lines · Michael Halstead

On 11/30/2012 12:17 PM, Raymond Danks wrote:

On 11/30/2012 11:03 AM, Michael Halstead wrote:

On 11/30/2012 09:26 AM, Bruce Ashfield wrote:

Quoted 21 lines · Saul Wold

Quoted 19 lines · David Nyström

Quoted 17 lines · Richard Purdie

Quoted 15 lines · Raymond Danks

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.

Quoted 6 lines

Quoted 4 lines

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 [email protected]: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."

Quoted 9 lines

Sounds good to me. Thank you.

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?

I can add a private list for [email protected]. Who
shall I add to membership?

At the risk of stating the obvious, I like the idea of a separate list, and would like to be
added. But then again, i can always add myself later as well (assuming the same
interface as the rest of the lists).

Cheers,

Bruce

Quoted 105 lines

--
Michael Halstead
Yocto Project / Sys Admin

Thanks again,
Ray

--
Michael Halstead
Yocto Project / Sys Admin

Cheers,

Bruce

Quoted 74 lines

Sau!

As far as a meta-cloud layer is concerned, I'm not sure I am

Quoted 62 lines

Quoted 9 lines

Quoted 9 lines

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

Quoted 4 lines

Quoted 3 lines

meta-virtualization layer until it has matured to the point where abstraction is more warranted.

Agree.

Since you've already created a presence

Quoted 10 lines

Quoted 10 lines

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.

Quoted 10 lines

Quoted 2 lines

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,

Quoted 11 lines

Richard

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 7 lines

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 5 lines

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 9 lines

--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 64 lines · Raymond Danks

Quoted 51 lines · Michael Halstead

Quoted 37 lines · Bruce Ashfield

On Fri, Nov 30, 2012 at 12:15 PM, Saul Wold <[email protected] <mailto:[email protected]>> 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.

Quoted 8 lines

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

Quoted 7 lines

Either of you can currently add [email protected]: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.

Quoted 2 lines

Quoted 6 lines

Quoted 3 lines

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

Sounds good to me. Thank you.

Quoted 4 lines

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?

I can add a private list for [email protected]. Who shall I add to membership?

Quoted 63 lines · Raymond Danks

Quoted 50 lines · Michael Halstead

Quoted 37 lines · Bruce Ashfield

On Fri, Nov 30, 2012 at 12:15 PM, Saul Wold <[email protected] <mailto:[email protected]>> 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.

Quoted 7 lines

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

Quoted 7 lines

Either of you can currently add [email protected]: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.

Quoted 2 lines

Quoted 6 lines

Quoted 3 lines

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

Sounds good to me. Thank you.

Quoted 4 lines

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?

I can add a private list for [email protected]. Who shall I add to membership?

I would like to be added, since it seems I can't add myself at
https://lists.yoctoproject.org/listinfo

Best Regards,
David

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of David Nyström
Sent: Saturday, December 01, 2012 10:44 PM
To: Michael Halstead
Cc: oe-core layer
Subject: Re: [OE-core] meta-cloud layer

Quoted 79 lines · Michael Halstead

Quoted 63 lines · Raymond Danks

Quoted 50 lines · Michael Halstead

Quoted 37 lines · Bruce Ashfield

On Fri, Nov 30, 2012 at 12:15 PM, Saul Wold <[email protected] <mailto:[email protected]>> 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.

Quoted 7 lines

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

Quoted 7 lines

Either of you can currently add [email protected]: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.

Quoted 2 lines

Quoted 6 lines

Quoted 3 lines

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

Sounds good to me. Thank you.

Quoted 4 lines

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?

I can add a private list for [email protected]. Who shall I add to membership?

Quoted 5 lines

I would like to be added, since it seems I can't add myself at
https://lists.yoctoproject.org/listinfo

Best Regards,
David

I would like to be added as well to the private list.

Thanks,
Mihai

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 92 lines · Mihai

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of David Nyström
Sent: Saturday, December 01, 2012 10:44 PM
To: Michael Halstead
Cc: oe-core layer
Subject: Re: [OE-core] meta-cloud layer

Quoted 82 lines · Michael Halstead

Quoted 66 lines · Raymond Danks

Quoted 53 lines · Michael Halstead

Quoted 39 lines · Bruce Ashfield

On Fri, Nov 30, 2012 at 12:15 PM, Saul Wold <[email protected] <mailto:[email protected]>> 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.

Quoted 8 lines

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

Quoted 7 lines

Either of you can currently add [email protected]: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.

Quoted 2 lines

Quoted 6 lines

Quoted 3 lines

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

Sounds good to me. Thank you.

Quoted 4 lines

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?

I can add a private list for [email protected]. Who shall I add to membership?

Quoted 8 lines

Quoted 5 lines

I would like to be added, since it seems I can't add myself at
https://lists.yoctoproject.org/listinfo

Best Regards,
David

I would like to be added as well to the private list.

Just to be clear to all this is not a private list, there was some issue I think with getting it initialized, it is visiable and available to all from the https://lists.yoctoproject.org/listinfo URL, and it is getting added to the main list of Mailing lists today.

Sorry for any confusion.

Sau!

Quoted 16 lines

Thanks,
Mihai

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 105 lines · Saul Wold

Quoted 90 lines · Mihai

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of David Nyström
Sent: Saturday, December 01, 2012 10:44 PM
To: Michael Halstead
Cc: oe-core layer
Subject: Re: [OE-core] meta-cloud layer

Quoted 80 lines · Michael Halstead

Quoted 64 lines · Raymond Danks

Quoted 52 lines · Michael Halstead

Quoted 38 lines · Bruce Ashfield

On Fri, Nov 30, 2012 at 12:15 PM, Saul Wold <[email protected] <mailto:[email protected]>> 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.

Quoted 8 lines

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

Quoted 7 lines

Either of you can currently add [email protected]: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.

Quoted 1 line

Quoted 6 lines

Quoted 3 lines

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

Sounds good to me. Thank you.

Quoted 4 lines

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?

I can add a private list for [email protected]. Who shall I add to membership?

Quoted 7 lines

Quoted 5 lines

I would like to be added, since it seems I can't add myself at
https://lists.yoctoproject.org/listinfo

Best Regards,
David

I would like to be added as well to the private list.

Just to be clear to all this is not a private list, there was some issue I think with getting it initialized, it is visiable and available to all from the https://lists.yoctoproject.org/listinfo URL, and it is getting added to the main list of Mailing lists today.

Sorry for any confusion.

Quoted 2 lines

Sau!

This was a misunderstanding on my part. I thought this was a simple mail alias for the maintainers. A full list has been set up and can be seen at https://lists.yoctoproject.org/ or
https://lists.yoctoproject.org/listinfo. Anyone can subscribe. I'm also working on getting this list added to Gmane for fans for NNTP.

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core