FYI: A fedora 17 cloud image

Fri Nov 16 22:06:39 UTC 2012

On Fri, Nov 16, 2012 at 03:42:52PM -0500, jvlcek wrote:
> On 11/16/2012 10:15 AM, Daniel P. Berrange wrote:
> > On Fri, Nov 16, 2012 at 04:02:10PM +0100, Dave Neary wrote:
> >> Hi,
> >>
> >> On 11/16/2012 03:51 PM, Matthew Miller wrote:
> >>> On Fri, Nov 16, 2012 at 02:31:40PM +0000, Daniel P. Berrange wrote:
> >>>> They're completely different from Oz really, except that both can
> >>>> use kickstart files for their automation.
> >>> We've got other tools along these lines too:
> >>>
> >>>> appliance-creator is basically running yum in a chroot
> >>>> and handling the kickstart config itself.
> >>> ami-creator (from Jeremy Katz and also maintained by Eucalyptus) does this
> >>> as well.
> >>>
> >>>> Oz boots KVM and runs the *real* installer in a guest,
> >>>> providing it with the kickstart.
> >>> And this is also done by the new livemedia-creator from the Anaconda team.
> >> So which one is the "best" now? In terms of community, momentum,
> >> features? What should we be using for virtual image creation for
> >> (for example) oVirt and OpenStack?
> > Oz is the only real candidate here because it is the only one that is
> > seriously targetting arbitrary guest OS distros, including Windows
> >
> >   https://github.com/clalancette/oz/wiki
> >
> > so I discount appliance-creatoe/ami-creator/livemedia-creator as
> > suitable for ovirt/OpenStack.
> >
> > That said, we have broader plans in this area which will obsolete Oz
> > to some degree. Oz does really 3 things
> >
> >  - Code to determine how to create a KVM instance for installing
> >    each OS
> >  - Kickstart file (or equivalent file for other distros)
> >  - Code to install further packages to the initial image.
> >
> > The libosinfo library is providing a database of metadata about optimal
> > hardware configuration for OS, so the hardcoded setup that Oz does should
> > really all go away long term, and be replaced by metadata driven code.
> >
> > Similarly the libosinfo library also decided that handling kickstart
> > file generation is also within its scope. So again Oz code in this
> > area should go away long term.
> >
> > That leaves the only bit of truely Oz specific code being that which
> > customizes the images post-install to add further packages. So the
> > quesiton is whether this is useful enough to apps to justify them
> > using Oz.
> >
> > I really see oVirt / OpenStack (and virt-manager, virt-install, GNOME
> > Boxes, and any other virt management app) as wanting to use libosinfo
> > directly for doing most of the work for VM provisioning and/or image
> > building. Using Oz likely won't buy them a whole lot of extra benefit.
> > I see Oz remaining as primarily a end user command line tool for building
> > images
> >
> > Regards,
> > Daniel
> 
> There is also ImageFactory, which uses OZ.
> 
> http://imgfac.org/
> 
> The web site has step by step instructions for building and
> pushing. I've had success following them to build and
> push an f17 image to EC2.
> |
> |See the "ContactUs" link at the top for where/how to get
> help using it.
> 

Yes. To be clear, while Oz is concerned with building images (or
modifying existing JEOS images), Image Factory is concerned with getting
images into the right place so you can actually use them. It understands
the various workflows around pushing to RHEV, pushing to vSphere,
pushing to OpenStack, and pushing to EC2 and has a nice ReST API for
doing so.

Steven Hardy (of the Heat team) has been looking at using Factory to
manage Heat's image-building needs so that they don't have to build
stuff over and over again as they currently do.

Dan, if you have a minute to take a look at Factory's use of Oz and
suggest ways to use libosinfo instead (as things progress), that would
be outstanding...

--Hugh

> Joe V.
> 
> 
> 
> 

> <template>
>   <name>f17jeos</name>
>   <os>
>     <rootpw>changeme</rootpw>
>     <name>Fedora</name>
>     <version>17</version>
>     <arch>x86_64</arch>
>     <install type='url'>
>       <url>http://download.fedoraproject.org/pub/fedora/linux/releases/17/Fedora/x86_64/os/</url>
>     </install>
>   </os>
>   <description>Fedora 17</description>
> </template>

> <provider_credentials>
> <ec2_credentials>
>   <account_number>Your EC2 account number</account_number>
>   <access_key>Your EC2 access key</access_key>
>   <secret_access_key>Your EC2 secret key</secret_access_key>
> <certificate>
> -----BEGIN CERTIFICATE-----
> your EC2 certificate
> -----END CERTIFICATE-----
> </certificate>
> <key>
> -----BEGIN PRIVATE KEY-----
> your EC2 key
> -----END PRIVATE KEY-----
> </key>
> </ec2_credentials>
> </provider_credentials>
> 

> _______________________________________________
> cloud mailing list
> cloud at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/cloud

-- 
== Hugh Brock, hbrock at redhat.com                                   ==
== Engineering Manager, Cloud BU                                   ==
== Aeolus Project: Manage virtual infrastructure across clouds.    ==
== http://aeolusproject.org                                        ==

"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey