Open Stack

On Fri, Dec 6, 2013 at 2:43 PM, Randall Burt <randall.burt at rackspace.com>wrote:

>  I too have warmed to this idea but wonder about the actual implementation
> around it. While I like where Edmund is going with this, I wonder if it
> wouldn't be valuable in the short-to-mid-term (I/J) to just add /templates
> to Glance (/assemblies, /applications, etc) along side /images.  Initially,
> we could have separate endpoints and data structures for these different
> asset types, refactoring the easy bits along the way and leveraging the
> existing data storage and caching bits, but leaving more disruptive changes
> alone. That can get the functionality going, prove some concepts, and allow
> all of the interested parties to better plan a more general v3 api.
>

I think this trajectory makes a lot of sense as an initial plan. We should
definitely see how much overlap there is through a detailed proposal. If
there are some extremely low-hanging fruit on the side of generalization,
maybe we can revise such a proposal before we get going too far.

It also occurs to me that this is a very big shift in focus for the Glance
team, however, so perhaps it would make sense to try to discuss this at the
midcycle meetup [1]? I know some of the discussion there is going to
revolve around finding a better solution to the image sharing / image
marketplace problem.


[1]
http://lists.openstack.org/pipermail/openstack-dev/2013-November/019230.html


>
>  On Dec 6, 2013, at 4:23 PM, Edmund Troche <edmund.troche at us.ibm.com>
>  wrote:
>
>  I agree with what seems to also be the general consensus, that Glance
> can "become" Heater+Glance (the service that manages images in OS today).
> Clearly, if someone looks at the Glance DB schema, APIs and service type
> (as returned by keystone service-list), all of the terminology is about
> images, so we would need to more formally define what are the
> characteristics or "image", "template", maybe "assembly", "components" etc
> and find what is a good generalization. When looking at the attributes for
> "image" (image table), I can see where there are a few that would be
> generic enough to apply to "image", "template" etc, so those could be taken
> to be the base set of attributes, and then based on the "type" (image,
> template, etc) we could then have attributes that are type-specific (maybe
> by leveraging what is today "image_properties").
>
> As I read through the discussion, the one thing that came to mind is
> "asset management". I can see where if someone bothers to create an image,
> or a template, then it is for a good reason, and that perhaps you'd like to
> maintain it as an IT asset. Along those lines, it occurred to me that maybe
> what we need is to make Glance some sort of asset management service that
> can be leveraged by Service Catalogs, Nova, etc. Instead of storing
> "images" and "templates"  we store assets of one kind or another, with
> artifacts (like files, image content, etc), and associated metadata. There
> is some work we could borrow from, conceptually at least, from OSLC's Asset
> Management specification:
> http://open-services.net/wiki/asset-management/OSLC-Asset-Management-2.0-Specification/.
> Looking at this spec, it probably has more than we need, but there's plenty
> we could borrow from it.
>
>
> Edmund Troche
>
>
> <graycol.gif>Georgy Okrokvertskhov ---12/06/2013 01:34:13 PM---As a
> Murano team we will be happy to contribute to Glance. Our Murano metadata
> repository is a stand
>
>
> From: Georgy Okrokvertskhov <gokrokvertskhov at mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>,
> Date: 12/06/2013 01:34 PM
> Subject: Re: [openstack-dev] [heat] [glance] Heater Proposal
>
> ------------------------------
>
>
>
> As a Murano team we will be happy to contribute to Glance. Our Murano
> metadata repository is a standalone component (with its own git
> repository)which is not tightly coupled with Murano itself. We can easily
> add our functionality to Glance as a new component\subproject.
>
> Thanks
> Georgy
>
>
> On Fri, Dec 6, 2013 at 11:11 AM, Vishvananda Ishaya <
> *vishvananda at gmail.com* <vishvananda at gmail.com>> wrote:
>
>
>    On Dec 6, 2013, at 10:38 AM, Clint Byrum <*clint at fewbar.com*<clint at fewbar.com>>
>    wrote:
>
>    > Excerpts from Jay Pipes's message of 2013-12-05 21:32:54 -0800:
>    >> On 12/05/2013 04:25 PM, Clint Byrum wrote:
>    >>> Excerpts from Andrew Plunk's message of 2013-12-05 12:42:49 -0800:
>    >>>>> 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*<http://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.
>    >>>>
>    >>>> 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? 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.
>    >>>>
>    >>>
>    >>> I spoke at length via G+ with Randall and Tim about this earlier
>    today.
>    >>> I think I understand the impetus for all of this a little better
>    now.
>    >>>
>    >>> Basically what I'm suggesting is that Glance is only narrow in
>    scope
>    >>> because that was the only object that OpenStack needed a catalog
>    for
>    >>> before now.
>    >>>
>    >>> However, the overlap between a catalog of images and a catalog of
>    >>> templates is quite comprehensive. The individual fields that
>    matter to
>    >>> images are different than the ones that matter to templates, but
>    that
>    >>> is a really minor detail isn't it?
>    >>>
>    >>> I would suggest that Glance be slightly expanded in scope to be an
>    >>> object catalog. Each object type can have its own set of fields
>    that
>    >>> matter to it.
>    >>>
>    >>> This doesn't have to be a minor change to glance to still have many
>    >>> advantages over writing something from scratch and asking people to
>    >>> deploy another service that is 99% the same as Glance.
>    >>
>    >> My suggestion for long-term architecture would be to use Murano for
>    >> catalog/metadata information (for images/templates/whatever) and
>    move
>    >> the block-streaming drivers into Cinder, and get rid of the Glance
>    >> project entirely. Murano would then become the catalog/registry of
>    >> objects in the OpenStack world, Cinder would be the thing that
>    manages
>    >> and streams blocks of data or block devices, and Glance could go
>    away.
>    >> Imagine it... OpenStack actually *reducing* the number of projects
>    >> instead of expanding! :)
>    >>
>    >
>    > Have we not learned our lesson with Nova-Net/Neutron yet? Rewrites of
>    > existing functionality are painful.
>    >
>    > The Murano-concerned people have already stated they are starting
>    over
>    > on that catalog.
>    >
>    > I suggest they start over by expanding Glance's catalog. If the block
>    > streaming bits of Glance need to move somewhere else, that sounds
>    like a
>    > completely separate concern that distracts from this point.
>    >
>    > And to be clear, (I think I will just stop talking as I think I've
>    > made this point), my point is, we have a catalog, let's make it
>    better.
>
>    +1
>
>    Vish
>
>    >
>    > _______________________________________________
>    > OpenStack-dev mailing list
>    > *OpenStack-dev at lists.openstack.org*<OpenStack-dev at lists.openstack.org>
>    > *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev*<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>    _______________________________________________
>    OpenStack-dev mailing list
> *OpenStack-dev at lists.openstack.org* <OpenStack-dev at lists.openstack.org>
> *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev*<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>
> --
> Georgy Okrokvertskhov
> Technical Program Manager,
> Cloud and Infrastructure Services,
> Mirantis
> *http://www.mirantis.com* <http://www.mirantis.com/>
> Tel. +1 650 963 9828
> Mob. +1 650 996 3284_______________________________________________
> 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
>
>
>
> _______________________________________________
> 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/20131206/4336fb6a/attachment.html>