[openstack-dev] [Glance] Glare and future of artifacts in OpenStack.
jaypipes at gmail.com
Fri Apr 22 15:10:03 UTC 2016
Mike, thanks for the update. Very helpful. I did have a couple concerns,
though, from the slides...
1) On Slide 8, you have a bullet point:
"Quoting. We want to implement powerful nested quota support, rather
than have one global quota config."
I do not believe that Glare should have anything to do with quota
support. The reason is because Glare doesn't actually own the process of
consuming resources in the system. Glare simply describes some artifacts
that are used in resource-consuming operations (like spawning an
instance or spinning up a Heat stack).
I don't believe it's necessary to place artificial limits on the number
of metadata items that a particular artifact can have stored against it.
Remember that rate-limiting != quota limits. Limiting the number of HTTP
requests a user can make in a given time period to create metadata items
on an artifact is something that should be handled by open source or
commercial HTTP rate limiting solutions, not a quota handling solution.
2) Also on Slide 8, you have:
"Artifact sharing support. Should we implement 'community' visibility
for artifacts or not? (will be discussed on the summit)."
I won't be able to attend the summit session but I think the existing
Glance visibility model (public, private and shared) is a good one and
Glare should try to keep this model if they can.
3) On Slide 9, you have this in "future work (in Newton)":
"Tasks (asynchronous workflows) support."
Please, please, please NO.
There is absolutely no reason to couple a service that operates on
artifacts in an asynchronous fashion with a service that provides
metadata about those artifacts.
It was a mistake to do this in Glance and it would be a mistake to do
this in Glare. If you really want some async task processing function,
create a totally separate service that does that. Don't put it in Glare.
4) On Slide 3 "Why Can't We Use Glance for This?", you list:
"Complicated architecture, called Domain Model, that particularly prone
to race conditions."
Just want to say YES, you are spot on that the Domain proxy stuff made
the code virtually unreadable and introduced too great a surface area
for bugs. Great to see a move away from it.
On 04/21/2016 12:47 PM, Mikhail Fedosin wrote:
> Today I'm happy to present you a demo of a new service called Glare
> (means GLance Artifact REpository)which will be used as a unified
> catalog of artifacts in OpenStack. This service appeared in Mitaka in
> February and it succeeded Glance v3 API, that has become the
> experimental version of Glare v0.1 API.
> Currently we're working on stable v1 implementation and I believe it
> will be available in Newton. Here I present a demo of stable Glare v1
> and its features that are already implemented.
> The first video is a description of Glare service, its purposes, current
> status and future development.
> Slides are located here:
> Then it comes the demo. I have 3 videos that cover all basic features we
> have at the moment:
> 1. Interaction with Glance and existing images. It may be useful for
> App-Catalog when you import new image from it with Glare and use it
> through Glance.
> 2. Sorting and filtering with Glare. Since Glare supports artifact
> versioning in SemVer I present how user can sort and filter his images
> by version with special range operators.
> 3. Demonstration of Heat template artifact type and setting custom
> locations for artifacts.
> We have dedicated Glare design session on Wednesday 27th of April at
> 2-40 PM. Will be glad if you may join us there.
> Best regards,
> Mikhail Fedosin
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev