hi Steve, On 02/27/2013 05:29 PM, Steve Loranz wrote: > Imagefactory is more than a REST interface to oz. Oz creates a JEOS image. The customization that oz performs is limited to installing additional packages or running commands within a VM started with the JEOS image. Oz does not have knowledge of what needs to be added or how an image needs to be translated for a specific virtualization platform or cloud target. This is what imgfac brings to the party. > > I really wish we could get past the notion that imagefactory is just a REST interface to oz. What are we doing wrong on imgfac.org that leads people to see imagefactory this way? Maybe I should be happy about this, because it means we're doing a good job of hiding what is needed to go from base image to provider image for cloud targets like EC2 and vSphere. I think you're right when saying that this is a good sign, it means you managed to hide the complexity to a level where people don't necessarily notice what is going on behind the scenes. A good achievement. Still, this is a rather skilled platea so I think most people is aware of what is the difference between building an image from a kickstart and customize the image after it has been created. imgfac also provides the feature to push provider images over to the actual provider so it definitely isn't only a REST interface around Oz nor that is what I suggested; I've only said I had some decent understanding of its REST interface. My point was that for the simple task of creating a cloud image, maybe we could just stick to Oz but it was just my opinion, Matthew suggests we should instead use it and also add some wanted feature (the ability to pass a customized kickstart). By using imgfac we could probably build both openstack as also ec2 (and hopefully more) provider images via the same process. -- Giulio Fidente IRC: giulivo _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud
