Open Stack

Hi! Thank you for you responses! I think I should be more precise here...

On Fri, Apr 22, 2016 at 6:10 PM, Jay Pipes <jaypipes at gmail.com> wrote:

> 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.
>

There is a feature in glance_store, that it stores all data in one
container, owned by user 'glance'. In that case there is no possibility for
storage to distinguish the original owner of data. It means that we have to
support our own quota processing and calculate the allowed amount of data
before uploading it to the store.

Also it's a problem in Glance v2 that it confuses various quotas - allowed
number of tags, locations, members  and properties are checked along with
data size quoting:
https://github.com/openstack/glance/blob/master/glance/quota/__init__.py

In Glare we differentiate them, which means that allowed max number of some
artifact metadata (tags, members, etc.) are defined and checked with
oslo.versionobjects framework.
<http://www.lingvo-online.ru/ru/Search/Translate/GlossaryItemExtraInfo?text=%d1%80%d0%b0%d0%b7%d0%bb%d0%b8%d1%87%d0%b0%d1%82%d1%8c&translation=distinguish&srcLang=ru&destLang=en>

>
> 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.
>

I think that 'community' visibility is a good feature and there are real
use cases for that: too many public artifacts may confuse users. I think I
found a good solution how we can implement it right and I'll try to
formulate this and share the doc for future discussions. The whole idea is
to add conception of 'bookmarks' and allow users to bookmark only those
community artifacts that they need.

>
> 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.
>
> Flavio was right: no one wants to make it public, but having the support
of task engine may be useful.


> 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.
>
> Thanks :)


> Best,
> -jay
>
> On 04/21/2016 12:47 PM, Mikhail Fedosin wrote:
>
>> Hello!
>>
>> 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.
>> https://www.youtube.com/watch?v=XgpEdycRp9Y
>> Slides are located here:
>>
>> https://docs.google.com/presentation/d/1WQoBenlp-0vD1t7mpPgQuepDmlPUXq2LOfRYnurZx74/edit#slide=id.p
>>
>> 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.
>> https://www.youtube.com/watch?v=flrlCpqwWzI
>>
>> 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.
>> https://www.youtube.com/watch?v=ha3SLFZl_jw
>>
>> 3. Demonstration of Heat template artifact type and setting custom
>> locations for artifacts.
>> https://www.youtube.com/watch?v=EzEOJvKMUzo
>>
>> We have dedicated Glare design session on Wednesday 27th of April at
>> 2-40 PM. Will be glad if you may join us there.
>>
>> https://www.openstack.org/summit/austin-2016/summit-schedule/events/9162?goback=1
>>
>> Best regards,
>> Mikhail Fedosin
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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/20160511/c6b3aef2/attachment.html>