Re: [openstack-dev] [Glare] Application for inclusion of Glare in the list of official projects - Answers
On 17/07/17 12:34 +0300, Mikhail Fedosin wrote: 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. Hey Mike, Thanks for addressing these comments and summirizing them in this email. 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. I understand your optimism on this point and how being agile is helping you move Glare forward. I'd like to highlight, however, how important having a bigger/more diverse team is. Teams change, priorities change and I'd recommend not understimating this factor. There are many examples of projects that are interesting and important for OpenStack that are not receiving the right amount of contributions just yet. 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! I would like us to focus first in how we can get Glare in as an official project, what changes (if any) are required and whether this makes sense. Then it would be a good time for us to start discussing if/when/how we could replace Glance with Glare. I believe mixing both discussions is not helping and we cannot do any replacement if Glare is not part of the big tent first. I understand that some inclusion questions could be answering by having some of the replacement points figured out but still, I believe doing the latter before the former is just getting ahead of ourselves. 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
[openstack-dev] [Glare] Application for inclusion of Glare in the list of official projects - Answers
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
