Open Stack

On 24 January 2017 at 16:16, Mikhail Fedosin <mfedosin at gmail.com> wrote:

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

Has there been some discussion surrounding Mistral and Glare? I'd be
interested in reading more about those plans and ideas.



> 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.op
>>> enstack.org?subject:unsubscribe
>>> 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:unsubscrib
>> e
>> 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/20170126/a1b0540d/attachment.html>