Hello, thanks for the quick reply! On Sun, Jan 31, 2010 at 02:02:29PM +0800, Harish Pillay wrote: Shame on me: when the cave-man were clubbing each other, I switched from slackware (floppy install back then) to debian and never moved since. I did know Fedora <version>, but my finger failed me :) That would be fantastic! The problem what we have is that we sit on top of a fairly big stack of other projects (which of course made Eucalyptus doable) which are not packaged. We did try to provide some basic packages for the one we felt we could take a stab at (in particular axis2c and rampartc) but the packages are not official from upstream, nor we did a very good job (they are packaged to ease the installation or Eucalyptus). Also we don't have expertise to package the java projects we need. As you may know we are in ubuntu and we are in the process of getting into debian: this was possible becasue ubuntu helped up in the packaging effort and in packaging the dependencies. We hopefully know a bit more about packaging, but we still need to have our dependencies packaged. What is the best course of action here? cheers graziano -- Graziano Obertelli Eucalyptus Systems, Inc. 130 Castilian St. Goleta, CA 93117 Office: 805-845-8000 www.eucalyptus.com

On Mon, 1 Feb 2010 13:45:29 -0500 Matthew Miller <mattdm(a)mattdm.org&gt; wrote: About that... Has the policy stated in Eucalyptus FAQ changed? Right now it states: Q: Can I help develop Eucalyptus? A: For the moment, we are restricting external development contributions for Eucalyptus internals to bug fixes. It is just too complicated to try and keep the code base stable with external developers when we are in this early phase of development. But we will gladly accept patches that fix bugs. [...] Maybe Ubuntu people never do any development on the packages they ship, but I am not comfortable with an upstream like that. Of course, I am not even likely to maintain the package either, and some other maintainer might be. Still, I'm curious what are the perspectives of the open development for Eucalyptus. -- Pete

On Sat, 30 Jan 2010, graziano obertelli wrote: Thanks for joining us, Graziano. Good to see you. :) I'd say there are a couple of clear places where Eucalyptus and Fedora could help each other right now. 1. Get Eucalyptus packages into the main Fedora repos. Mr. Miller, if you guys are using Eucalyptus at Hahvahd, maybe you could step right into this lurch and see if the extant Fedora packages can be cleaned up and slipped into Fedora in time for F13? If not, is there anyone else out there who wants to step up? You've got one of the founders of Eucalyptus coming to your home turf to ask for your help. Does he need to ask twice? :) 2. Build Eucalyptus drivers for Deltacloud. The goal of the Deltacloud project is to unify, as much as possible, a set of open APIs for management of all cloud providers everywhere, everyplace, FOR ALL TIME. As libvirt is to Xen + kvm + qemu + etc., so we would like dcloud to be for EC2 + dreamhost + private clouds based on Eucalyptus + etc. Which is, perhaps, a bit ambitious. :) Eucalyptus's participation in that vision would obviously be welcome. There's a separate development list for that: https://fedorahosted.org/mailman/listinfo/deltacloud-devel Now, I think that dcloud is still a few patches short of a release at this point, but soon we'll be getting dcloud into Fedora, and we're hoping to start to use dcloud to manage EC2 instances for use by various Fedora folks. In particular, once Eucalyptus packages are in Fedora proper, I think a whole lot more avenues start to open up. --g -- Educational materials should be high-quality, collaborative, and free. Visit http://opensource.com/education and join the conversation.

Question One: How attached are we to the upstream subpackage names? I'd like of like to change them to more descriptive names: eucalyptus-sc -> eucalyptus-storage-controller eucalyptus-cloud -> eucalyptus-cloud-controller eucalyptus-cc -> eucalyptus-cluster-controller eucalyptus-nc -> eucalyptus-node-controller eucalyptus-gl -> eucalyptus-gatherlog Does anyone have strong opinions on this? -- Matthew Miller <mattdm(a)mattdm.org&gt; Senior Systems Architect -- Instructional & Research Computing Services Computing & Information Technology Harvard School of Engineering & Applied Sciences

On Tue, Feb 02, 2010 at 01:05:06PM -0500, Jeremy Katz wrote: They are subpacakges: we have a single giant tarball where we build both the java components (clc, sc and walrus) and the C components (nc, cc and gl) and the spec file we have reflects that, building everything in one go but creating multiple packages. cheers graziano -- Graziano Obertelli Eucalyptus Systems, Inc. 130 Castilian St. Goleta, CA 93117 Office: 805-845-8000 www.eucalyptus.com

On Tue, Feb 02, 2010 at 12:37:11PM -0500, Matthew Miller wrote: Question Two: "Like of like"? What does that even mean? Do I need more coffee? Or less? -- Matthew Miller <mattdm(a)mattdm.org&gt; Senior Systems Architect -- Instructional & Research Computing Services Computing & Information Technology Harvard School of Engineering & Applied Sciences

On Tue, Feb 02, 2010 at 10:56:22AM -0800, David Lutterkort wrote: Indeed: in our brief testings (very brief) it looks like is working like a charm. cheers graziano -- Graziano Obertelli Eucalyptus Systems, Inc. 130 Castilian St. Goleta, CA 93117 Office: 805-845-8000 www.eucalyptus.com

On Tue, Feb 02, 2010 at 10:24:17AM -0800, graziano obertelli wrote: We're going to have to build them separately. Hopefully, that won't be a big deal. It doesn't look like it should be. My two concerns are: the axis2 version provided is slightly old, and the rampartc package has some changes from upstream. We'll have to figure out the right way to deal with both of those. -- Matthew Miller <mattdm(a)mattdm.org&gt; Senior Systems Architect -- Instructional & Research Computing Services Computing & Information Technology Harvard School of Engineering & Applied Sciences

On Mon, 2010-02-01 at 17:43 -0500, Greg DeKoenigsberg wrote: Yes, having somebody from Eucalyptus involved would be very welcome. The most basic thing that should be done there is to take dcloud's EC2 driver and point it at a Eucalyptus instance, and see how far that goes. If there are any differences between EC2 and Eucalyptus (e.g., API additions), we should figure out how to support them. And, of course, we'd love to have Eucalyptus involvement in shaping the course of the dcloud API. Short it is, but not as short as one might think: we should be able to push dcloud API into Fedora in the next few weeks; goal is to have it all sewed up by the end of the month. David