Open Stack

Hey, Flavio :) Thanks for your questions!

As you said currently only Nokia's adopting Glare for its own platform, but
if we talk about OpenStack, that I believe Mistral will start to use it
soon.
In my opinion Glare's adoption is low due to the fact that the project is
not included under Big Tent. I think it will be changed soon, because now
I'm finishing Glare v1 API proposal, and when it's done we will apply under
BT.

About Glance v2 API - as I said they are +- the same with several cosmetic
differences (in Glance status is called 'queued', in Glare we renamed it to
'drafted', and so on). For this reason I'm going to implement a middleware,
that will provide a full Image API v2 for Glare (even with unnecessary
'/v2' prefix) and glance clients will be able to communicate with it as
with Glance. It's definitely doable and we can discuss it more detailed
during the PTG.

Best,
Mike

On Mon, Jan 23, 2017 at 11:51 AM, Flavio Percoco <flavio at redhat.com> wrote:

> On 19/01/17 12:48 +0300, Mikhail Fedosin wrote:
>
>> Hi Matt!
>>
>> This should be discussed, for sure, but there is a lot of potential. In
>> general, it depends on how far we are willing to go. In the minimum
>> approximation we can seamlessly replace Glance with Glare and operators
>> simply get additional features for versioning, validation (and conversion,
>> if necessary) of their uploaded images on the fly, as well as support for
>> storing files in different stores.
>>
>> If we dig a little deeper, then Glare allows you to store multiple files
>> in
>> a single artifact, so we can create a new type (ec2_image) and define
>> three
>> blobs inside: ami, ari, aki, and upload all three as a single object. This
>> will get rid of a large amount of legacy code and simplify the
>> architecture
>> of Nova. Plus Glare will control the integrity of such artifact.
>>
>
> Hey Mike,
>
> Thanks for bringing this up. While I think there's potential in Glare
> given it's
> being created during a more mature age of OpenStack and based on matured
> principles and standards, I believe you may be promoting Glare using the
> wrong
> arguments.
>
> As you mentioned in your first email on this thread, Glare has a set of
> functionalities that are already useful to a set of existing projects.
> This is
> great and I'd probably start from there.
>
> * How much have these projects adopted Glare?
> * Is Glare being deployed already?
> * What projects are the main consumers of Glare?
>
> Unfortunately, replacing Glance is not as simple as dropping Glare in
> because
> it's not only being used by Nova. Glance is also a public API (at least
> v2) and
> there are integrations that have been built by either cloud providers or
> cloud
> consumers on top of the existing Glance API.
>
> If Glare ships a Glance compatible API (as a way to make a drop-in
> replacement
> possible), it'll have to support it and live with it for a long time. In
> addition to this, Glare will have to keep up with the changes that may
> happen in
> Glance's API during that time.
>
> The next step could be full support for OVF and other formats that require
>> a large number of files. Here we can use artifact folders and put all the
>> files there.
>> "OpenStack Compute does not currently have support for OVF packages, so
>> you
>> will need to extract the image file(s) from an OVF package if you wish to
>> use it with OpenStack."
>> http://docs.openstack.org/image-guide/introduction.html
>>
>> Finally, I notice that there are a few nasty bugs in Glance (you know what
>> I mean), which make it extremely inconvenient for a number of deployments.
>>
>
> Not everyone is familiar with the issues of Glance's API. I believe I know
> what
> you're referring to but I'd recommend to expand here for the sake of
> discussion.
>
> That being said, I'd also like to point out that the flaws of Glance's API
> could
> be fixed so I'd rather focus the discussion on the benefits Glare would
> bring
> rather than how Glance's API may or may not be terrible. That's the kind of
> competition I'd prefer to see in this discussion.
>
> Cheers,
> Flavio
>
>
> On Wed, Jan 18, 2017 at 8:26 PM, Matt Riedemann <
>> mriedem at linux.vnet.ibm.com>
>> wrote:
>>
>> On 1/18/2017 10:54 AM, Mikhail Fedosin wrote:
>>>
>>> Hello!
>>>>
>>>> In this letter I want to tell you the current status of Glare project
>>>> and discuss its future development within the entire OpenStack
>>>> community.
>>>>
>>>> In the beginning I have to say a few words about myself - my name is
>>>> Mike and I am the PTL of Glare. Currently I work as a consultant at
>>>> Nokia, where we're developing the service as a universal catalog of
>>>> binary data. As I understand it right, Nokia has big plans for this
>>>> service, Moshe Elisha can tell you more about them.
>>>>
>>>> And here I want to ask the community - how exactly Glare may be useful
>>>> in OpenStack? Glare was developed as a repository for all possible data
>>>> types, and it has many possible applications. For example, it's a
>>>> storage of vm images for Nova. Currently Glance is used for this, but
>>>> Glare has much more features and this transition is easy to implement.
>>>> Then it's a storage of Tosca templates. We were discussing integration
>>>> with Heat and storing templates and environments in Glare, also it may
>>>> be interesting for TripleO project. Mistral will store its workflows in
>>>> Glare, it has already been decided. I'm not sure if Murano project is
>>>> still alive, but they already use Glare 0.1 from Glance repo and it will
>>>> be removed soon (in Pike afaik), so they have no other options except to
>>>> start using Glare v1. Finally there were rumors about storing torrent
>>>> files from Ironic.
>>>>
>>>> Now let me briefly describe Glare features:
>>>>
>>>>  * Versioning of artifacts - each artifact has a version in SemVer
>>>> format and you can sort and filter by this field.
>>>>  * Multiblob support - there can be several files and folders per one
>>>> artifact.
>>>>  * The ease of creating new artifact types with oslo_versionedobjects
>>>> framework.
>>>>  * Fair immutability - no one can change artifact when it's active.
>>>>  * Multistore support - each artifact type data may be stored in
>>>> different storages: images may go to Swift; heat templates may be stored
>>>> directly in sql-database; for Docker Contatiners you can use Ceph, if
>>>> you want.
>>>>  * Advanced sorting and filtering with various operators.
>>>>  * Uploaded data validation and conversion with hooks - for example,
>>>> Glare may check if uploaded file was a valid Tosca template and return
>>>> Bad Request if it's not.
>>>>
>>>> If you're interested, I recorded several demos in asciinema, that
>>>> describe how Glare works and present the most useful features. Another
>>>> demo about uploading hooks will be recorded and published this week.
>>>>
>>>> So, please tell me what you think and recommend in what direction we
>>>> should develop the project. Thanks in advance!
>>>>
>>>> Best,
>>>> Mike
>>>>
>>>> Useful links:
>>>> [1] Api documentation in rst format:
>>>> https://etherpad.openstack.org/p/glare-api
>>>> [2] Basic artifact workflow on devstack: https://asciinema.org/a/97985
>>>> [3] Listing of artifacts: https://asciinema.org/a/97986
>>>> [4] Creating your own artifact type with oslo_vo:
>>>> https://asciinema.org/a/97987
>>>> [5] Locations, Tags, Links and Folders in Glare:
>>>> https://asciinema.org/a/99771
>>>>
>>>>
>>>> ____________________________________________________________
>>>> ______________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: OpenStack-dev-request at lists.op
>>>> enstack.org?subject:unsubscrib
>>>> e
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>> What use cases does Glare make available to Nova that Nova doesn't
>>> already
>>> get from Glance? In other words, what problems/missing features are there
>>> in Nova that can't be solved by Glance but can by Glare?
>>>
>>> --
>>>
>>> Thanks,
>>>
>>> Matt Riedemann
>>>
>>>
>>> ____________________________________________________________
>>> ______________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.op
>>> enstack.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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> --
> @flaper87
> Flavio Percoco
>
> __________________________________________________________________________
> 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/20170124/e1bf38b1/attachment.html>