Re: cloud Digest, Vol 38, Issue 21
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