Open Stack

Hello! Thank you all for your answers and advises!

I will try to summarize all of the above.

The purpose of the application was to get the community's views on
including Glare in the list of official projects, and a potential
replacement of Glance in the foreseeable future. A large number of
inspirational mails were received, and there were a number of questions
that I should answer.

1. "Glare is being developed by one company and a very limited circle of
people."
    At this stage this is undoubtedly so. But I think this is more a plus
than a minus. Working out in a small team allows us to move much faster,
and do not spend months discussing simple things. Also I want to note that
three full-time engineers is enough. Obviously, this will not always be the
same. When we give the project to the community (i.e. make it an official
project), I can guarantee that the distribution by companies will increase.

2. "Glance is used everywhere, Glare will be very hard to replace him."
    Well, no one said that it would be easy. For our part, we did our best
to simplify this transition as much as possible: the data of Glance can be
migrated to Glare by a simple script, Glare API is a cleaned and improved
version of the Glance v2 API (
https://docs.google.com/document/d/18Tqad0NUPyFfHUo1KMr6bDDISpQtzacvZtEQIGhNkf4/edit?usp=sharing).
>From my experience I can say that the transition from Glance v1 to Glance
v2 was at times more painful than this.

3. "What are the pros / cons of the transition to Glare"
    I'll start with the pros:
        OpenStack will get the features that the customers wanted from us
for several years: dynamic quotas that determine how much data a particular
tenant can upload, versioning of artifacts, support for layers, which will
make a universal COW in Cinder regardless of the proposed backend, and many
others, including missing "copy-from" from Glance v1.
        Glare is much stabler by design. There are no race conditions
(artifacts are locked before updates), all the known problems of Glance
were also solved in Glare.
        Subjectively, but it seems to me that the Glare code is better and
the architecture is cleaner. This will allow people unfamiliar with the
project to adapt more quickly to it.
    Cons:
        Glance was developed long enough and it has good documentation,
also there are many tests. In other words, the project has been studied,
which can not be said about Glare. According to my feelings after the
transfer of the project, we will need a year's minimum for its adaptation
in the industry.
        It will take some effort to move from one project to another in
existing clouds. I believe that this process can be automated, but at the
same time I understand the complexity of such operations.

4. "How can a transition be made".
    I have several ideas how to organize this. But still I believe that the
decision should be taken by all together after a series of discussions. In
the basic version, I see it like this:
        1. We create an adapter in glare client that hides the minimal
differences between Glance v2 and Glare v1 APIs. For example, the image
will be activated immediately after upload.
        2. In Nova, another glare.py module will be created, which in fact
is just a copy of glance.py with cosmetic changes.
        3. Existing data migrate without loss by a simple script.
        4. ?????
        5. PROFIT!

5. "There's enough overlap between glare and glance + barbican + swift"
    I do not think there are any overlapping with Barbican and Swift. Swift
is used as one of the possible backends (as in Glance), Glare only stores
links to the data in it.
    Like in Barbican there is a potential opportunity to keep secrets in
Glare. This logic can be added with just one plugin. But in order to avoid
potential collisions, it was decided not to include this plugin in the
official repository, since it has not yet been properly tested.

6. "Is there any documentation to familiarize with the project closer"
    Yes, there is documentation, but it obviously is not enough. Here are
the main links:
        Glare repo: https://github.com/openstack/glare
        Glare client repo: https://github.com/openstack/python-glareclient

        How to deploy Glare in Docker:
https://github.com/Fedosin/docker-glare

        How to deploy Glare in Devstack:
https://github.com/openstack/glare/tree/master/devstack

        Glare API description:
https://github.com/openstack/glare/blob/master/doc/source/developer/webapi/v1.rst

        Glare architecture description:
https://github.com/openstack/glare/blob/master/doc/source/architecture.rst

        Set of glare demos (slightly outdated):
          Glare artifact lifecycle: https://asciinema.org/a/97985
          Listing of artifacts in Glare: https://asciinema.org/a/97986
          Creating a new artifact type: https://asciinema.org/a/97987
          Locations, Tags, Links and Folders: https://asciinema.org/a/99771

    Now I'm writing Get Started doc for people who want to get to know the
project more closely. It would also be nice to create a wiki page with the
most useful and up-to-date information, as well as with FAQ. Idan is
recording new demos, based on the recent changes.

In conclusion, I want to say that I agree that it is not necessary to make
Glare an official project right now. Therefore, I want to hold 1-2 sessions
at PTG in Denver to demonstrate all service possibilities, because I
believe that the picture's worth a thousand words. After the discussions,
we will be able to jointly take a weighted decision.

If you want to help the project, you can always find us in the channel
#openstack-glare, or write to my email (mfedosin at gmail.com)

Best,
Mike Fedosin

P.S. FYI I am on vacation until the 20th of July.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170717/f88f2eee/attachment.html>