On 24 January 2017 at 16:16, Mikhail Fedosin <mfedo...@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 <fla...@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 < >>> mrie...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev