Open Stack

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>wrote:

>
> On Dec 6, 2013, at 10:38 AM, Clint Byrum <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>
> >>>>>>  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
> > 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
>
>


-- 
Georgy Okrokvertskhov
Technical Program Manager,
Cloud and Infrastructure Services,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131206/0d9986ff/attachment.html>