Open Stack

On Thu, Dec 5, 2013 at 1:05 PM, Vishvananda Ishaya <vishvananda at gmail.com>wrote:

>
> On Dec 5, 2013, at 12:42 PM, Andrew Plunk <andrew.plunk at RACKSPACE.COM>
> wrote:
>
> >> Excerpts from Randall Burt's message of 2013-12-05 09:05:44 -0800:
> >>> On Dec 5, 2013, at 10:10 AM, Clint Byrum <clint at fewbar.com>
> >>> wrote:
> >>>
> >>>> Excerpts from Monty Taylor's message of 2013-12-04 17:54:45 -0800:
> >>>>> Why not just use glance?
> >>>>>
> >>>>
> >>>> I've asked that question a few times, and I think I can collate the
> >>>> responses I've received below. I think enhancing glance to do these
> >>>> things is on the table:
> >>>>
> >>>> 1. Glance is for big blobs of data not tiny templates.
> >>>> 2. Versioning of a single resource is desired.
> >>>> 3. Tagging/classifying/listing/sorting
> >>>> 4. Glance is designed to expose the uploaded blobs to nova, not users
> >>>>
> >>>> My responses:
> >>>>
> >>>> 1: Irrelevant. Smaller things will fit in it just fine.
> >>>
> >>> Fitting is one thing, optimizations around particular assumptions
> about the size of data and the frequency of reads/writes might be an issue,
> but I admit to ignorance about those details in Glance.
> >>>
> >>
> >> Optimizations can be improved for various use cases. The design,
> however,
> >> has no assumptions that I know about that would invalidate storing blobs
> >> of yaml/json vs. blobs of kernel/qcow2/raw image.
> >
> > I think we are getting out into the weeds a little bit here. It is
> important to think about these apis in terms of what they actually do,
> before the decision of combining them or not can be made.
> >
> > I think of HeatR as a template storage service, it provides extra data
> and operations on templates. HeatR should not care about how those
> templates are stored.
> > Glance is an image storage service, it provides extra data and
> operations on images (not blobs), and it happens to use swift as a backend.
>
> This is not completely correct. Glance already supports something akin to
> templates. You can create an "image" with metadata properties that
> specifies a complex block device mapping which would allow for multiple
> volumes and images to connected to the vm at boot time. This is
> functionally a template for a single vm.
>
> Glance is pretty useless if is just an "image storage" service, we already
> have other places that can store bits (swift, cinder). It is much more
> valuable as a searchable repository of bootable templates. I don't see any
> reason why this idea couldn't be extended to include more complex templates
> that could include more than one vm.
>

FWIW I agree with all of this. I think Glance's real role in OpenStack is
as a helper and optionally as a gatekeeper for the category of "stuff Nova
can boot". So any parameter that affects what Nova is going to boot should
in my view be something Glance can be aware of. This list of parameters
*could* grow to include multiple device images, attached volumes, and other
things that currently live in the realm of flavors such as extra hardware
requirements and networking aspects.

Just so things don't go too crazy, I'll add that since Nova is generally
focused on provisioning individual VMs, anything above the level of an
individual VM should be out of scope for Glance.

I think Glance should alter its approach to be less generally agnostic
about the contents of the objects it hosts. Right now, we are just starting
to do this with images, as we slowly advance on offering server side format
conversion. We could find similar use cases for single vm templates.

It would be fantastic if we could figure out how to turn this idea into
some actionable work in late I/early J. It could be a fun thing to work on
at the midcycle meetup.


>
> We have discussed the future of glance a number of times, and if it is
> really just there to serve up blobs of data + metadata about images, it
> should go away. Glance should offer something more like the AWS image
> search console. And this could clearly support more than just images, you
> should be able to search for and launch more complicated templates as well.
>
> >
> > If HeatR and Glance were combined, it would result in taking two very
> different types of data (template metadata vs image metadata) and mashing
> them into one service. How would adding the complexity of HeatR benefit
> Glance, when they are dealing with conceptually two very different types of
> data? For instance, should a template ever care about the field "minRam"
> that is stored with an image?
>
>
> I don't see these as significantly different types of metadata. Metadata
> for heat templates might be a bit more broad (minFlavor?) I would think
> that a template would care about constraints like this, especially when you
> consider that a user might want to give a command to launch a template but
> then override certain characteristics.
>
> Vish
>
> > Combining them adds a huge development complexity with a very small
> operations payoff, and so Openstack is already so operationally complex
> that HeatR as a separate service would be knowledgeable. Only clients of
> Heat will ever care about data and operations on templates, so I move that
> HeatR becomes it's own service, or becomes part of Heat.
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131205/8939bcd4/attachment.html>